idnits 2.17.1 draft-ietf-sipcore-info-events-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2976, but the abstract doesn't seem to directly say this. It does mention RFC2976 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 705 has weird spacing: '...3xx-6xx o...' == Line 754 has weird spacing: '... 2xx o ...' == Line 755 has weird spacing: '... 1xx o ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 5, 2009) is 5409 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1051, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-28) exists of draft-ietf-speechsc-mrcpv2-19 == Outdated reference: A later version (-09) exists of draft-saleem-msml-08 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE E. Burger 3 Internet-Draft NeuStar, Inc. 4 Obsoletes: RFC 2976 H. Kaplan 5 (if approved) Acme Packet 6 Intended status: Standards Track C. Holmberg 7 Expires: January 6, 2010 Ericsson 8 July 5, 2009 10 Session Initiation Protocol (SIP) INFO Method and Package Framework 11 draft-ietf-sipcore-info-events-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 6, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document provides new semantics for the SIP INFO method of RFC 50 2976. These new semantics defined here are fully backwards 51 compatible with the old semantics. Core to the new semantics is a 52 mechanism for defining, negotiating and exchanging Info Packages that 53 use the INFO method. Applications that need to exchange session- 54 related information within a SIP INVITE-created session, also known 55 as application level information, use these INFO requests. This 56 draft addresses issues and open items from RFC 2976 and replaces it. 58 Conventions Used in this Document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 The terminology in this document conforms to the Internet Security 64 Glossary [RFC4949]. 66 Be aware this document strictly follows RFC 3261 [RFC3261] for the 67 definition of the terms User Agent Server (UAS) and User Agent Client 68 (UAC). Specifically, the UAC issues a SIP request and the UAS 69 responds. This terminology may be confusing when one combines the 70 INFO case with the INVITE case. For an INVITE, the initiator of the 71 session is the UAC and the target of the session is the UAS. 72 However, it is possible for the target UA of the session, the UAS of 73 the INVITE transaction, to send an INFO to the initiating UA of the 74 session, the UAC of the INVITE transaction. From the perspective of 75 the INFO, the target UA of the session (INVITE UAS) is, in fact, the 76 UAC (sender) of the INFO request. Likewise, from the perspective of 77 the INFO, the initiating UA of the session (INVITE UAC) is the UAS 78 (recipient) of the INFO request. Since this document strictly 79 follows RFC 3261, we refer to the UA that issues the INVITE as the 80 "initiating UA" and the UA that responds to the INVITE as the "target 81 UA" to remove any confusion. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 87 3. Info Package Behavior . . . . . . . . . . . . . . . . . . . . 7 88 3.1. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 89 3.2. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 90 3.3. Package Versions . . . . . . . . . . . . . . . . . . . . . 9 91 3.4. Advertisement Example . . . . . . . . . . . . . . . . . . 10 92 4. The INFO Method Request . . . . . . . . . . . . . . . . . . . 11 93 4.1. INFO Requests . . . . . . . . . . . . . . . . . . . . . . 11 94 4.2. INFO Request Body . . . . . . . . . . . . . . . . . . . . 12 95 4.3. Responses to the INFO Request Method . . . . . . . . . . . 13 96 4.4. Routing Behavior . . . . . . . . . . . . . . . . . . . . . 14 97 4.5. Behavior of Registrars . . . . . . . . . . . . . . . . . . 14 98 4.6. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . 14 99 4.7. Order of Delivery . . . . . . . . . . . . . . . . . . . . 15 100 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 15 101 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 15 102 5.2. INFO Headers . . . . . . . . . . . . . . . . . . . . . . . 17 103 5.2.1. Info-Package header . . . . . . . . . . . . . . . . . 17 104 5.2.2. Recv-Info header . . . . . . . . . . . . . . . . . . . 18 105 6. Legacy Uses of INFO . . . . . . . . . . . . . . . . . . . . . 18 106 7. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 107 7.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 19 108 7.2. Info Package Name . . . . . . . . . . . . . . . . . . . . 19 109 7.3. Info Package Parameters . . . . . . . . . . . . . . . . . 19 110 7.4. Info Package Tags . . . . . . . . . . . . . . . . . . . . 19 111 7.5. INFO Bodies . . . . . . . . . . . . . . . . . . . . . . . 20 112 7.6. UAC generation of INFO requests . . . . . . . . . . . . . 20 113 7.7. UAS processing of INFO requests . . . . . . . . . . . . . 20 114 7.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 21 115 7.9. IANA Registrations . . . . . . . . . . . . . . . . . . . . 21 116 7.10. Security Considerations . . . . . . . . . . . . . . . . . 21 117 7.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 21 118 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 119 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 120 9.1. Update to Registration of SIP INFO Method . . . . . . . . 22 121 9.2. Registration of the Info-Package Header Field . . . . . . 22 122 9.3. Registration of the Recv-Info Header Field . . . . . . . . 23 123 9.4. Creation of the Info Packages Registry . . . . . . . . . . 23 124 9.5. Registration of the Info-Package Content-Disposition . . . 24 125 9.6. SIP Response Code 469 Registration . . . . . . . . . . . . 24 126 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 127 10.1. Simple Info Package . . . . . . . . . . . . . . . . . . . 24 128 10.2. Multipart INFO Example . . . . . . . . . . . . . . . . . . 24 129 11. Modifications to SIP Change Process . . . . . . . . . . . . . 25 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 131 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 132 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 133 13.2. Informative References . . . . . . . . . . . . . . . . . . 27 134 Appendix A. Info Package Considerations . . . . . . . . . . . . . 29 135 A.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 29 136 A.2. Dialog Fate-Sharing . . . . . . . . . . . . . . . . . . . 30 137 A.3. Messaging Rates and Volume . . . . . . . . . . . . . . . . 30 138 A.4. Is there a better alternative? . . . . . . . . . . . . . . 30 139 A.5. Alternatives for Common INFO Use . . . . . . . . . . . . . 32 140 A.5.1. State Updates . . . . . . . . . . . . . . . . . . . . 32 141 A.5.2. User Stimulus: Touch Tones and Others . . . . . . . . 32 142 A.5.3. Direct Signaling Channel . . . . . . . . . . . . . . . 33 143 A.5.4. Proxy-Aware Signaling . . . . . . . . . . . . . . . . 33 144 A.5.5. Dialog Probe . . . . . . . . . . . . . . . . . . . . . 33 145 A.5.6. Malicious Indicator . . . . . . . . . . . . . . . . . 34 146 Appendix B. Legacy INFO Usages . . . . . . . . . . . . . . . . . 34 147 B.1. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 148 B.2. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 149 B.3. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 35 150 B.4. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 151 B.5. Video Fast Update . . . . . . . . . . . . . . . . . . . . 35 152 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 35 153 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 36 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 156 1. Introduction 158 The SIP protocol [RFC3261] defines session control messages used to 159 setup and tear down a SIP controlled session. In addition, a SIP 160 User Agent (UA) can use the re-INVITE and UPDATE methods during a 161 session to change the characteristics of the session. Most often, 162 this is to change the properties of media flows related to the 163 session or to update the SIP session timer [RFC4028]. The purpose of 164 the INFO message [RFC2976] is to carry application level information 165 along the SIP signaling path. Note the INFO method does not change 166 the SIP session state. It may, however, change application state for 167 applications using the SIP session. 169 While INFO has been widely adopted for specific application use 170 cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither 171 defined a negotiation mechanism nor a means by which to explicitly 172 indicate the type of application information contained in the INFO 173 message. This led to problems associated with static configuration. 174 In addition, the industry realized there was a potential for 175 interoperability problems due to undefined content syntax and 176 semantics. This draft addresses these deficiencies and provides a 177 framework for explicit negotiation of capabilities and content 178 context using "Info Packages". 180 The INFO method as defined by RFC 2976 did not provide any context 181 for the information the request carried. While it may sometimes be 182 clear what the content is based on the Content-Type, this is only 183 true where there is only one contextual usage of the content-type. 184 For example, if the Content-Type is "image/jpeg", the MIME-attached 185 content is a JPEG image. However, there are many useful ways a UAS 186 can render an image. Said differently, there are different contexts 187 for an image in SIP. The image could be a caller-id picture, a 188 contact icon, a photo for sharing, and so on. The sender does not 189 know which image to send to the receiver if the receiver supports an 190 image content type. Likewise, the receiver does not know the context 191 of an image the client is sending if the receiver supports receiving 192 more than one image content type. Thus, we need a well defined and 193 documented statement of what the information sent is for. This 194 situation is identical to the context issue in Internet Mail 195 [RFC3458]. RFC 3458 goes into this and other issues in detail. 197 Event Packages [RFC3265] perform the role of disambiguating the 198 context of a message for subscription-based events. This document 199 provides a similar framework for INVITE-based application level 200 information exchange. However, while the mechanism described here is 201 similar to subscription-based events, there is no formal relationship 202 between this mechanism and the subscription mechanism. In 203 particular, when a UAC issues a SUBSCRIBE, it creates a dialog usage. 205 The mechanism defined here creates neither a separate subscription 206 dialog nor a subscription usage within an existing session. Instead, 207 it uses the INVITE method and its responses to indicate supported 208 Info Packages and the INFO method to convey the Info Packages. 210 Each UA enumerates which Info Packages it can receive. If a first UA 211 indicates it can receive a package and a second UA can send the 212 package, the second UA can send INFO methods containing the payload 213 for that package. The Recv-Info header indicates which packages a UA 214 is willing to receive. The Info-Package header indicates which 215 package a particular INFO method request belongs to. There is a 216 reserved Info Package, "nil", which indicates the UA conforms to this 217 document, but does not wish to receive Info Packages. This enables 218 other UAs that conform to this document to detect legacy UAs. A 219 legacy UA will not include a Recv-Info header in their SIP session 220 establishment or modification requests. Conversely, a UA that 221 supports Info Packages will have a Recv-Info header. Section 3 222 describes Info Package advertisement in detail. 224 This document does not describe any specific Info Package type 225 extensions. One must extend this protocol by other documents, herein 226 referred to as "Info Packages". Section 7 describes guidelines for 227 creating these extensions. 229 The INFO method does not change the state of SIP calls or the 230 parameters of the sessions SIP initiates. It merely sends optional 231 application layer information, generally related to the session. 233 Applications need to be aware that application level information 234 transported by the INFO method constitutes mid-session signaling. 235 These messages traverse the post-session-setup SIP signaling path. 236 This is the path taken by SIP re-INVITEs, BYEs, and other SIP 237 requests within an individual session. SIP proxy servers will 238 receive, and potentially act on, mid-session signaling information. 239 Application designers need to understand this can be a feature, as 240 when the User Agents are exchanging information that elements in the 241 SIP signaling path need to be aware of. Conversely, this can be a 242 problem, as messages these network elements have no interest in can 243 also put a significant burden on those element's ability to process 244 other traffic. Moreover, such network elements may not be able to 245 read end-to-end encrypted INFO bodies. 247 2. Applicability 249 This document replaces the SIP INFO method document [RFC2976] to 250 include explicit negotiation of supported Info Packages in the INVITE 251 transaction and indication of the Info Package to use by using a new 252 header field in the INFO request. As described in Section 4.1, the 253 mechanism described here is backwards compatible with legacy, RFC 254 2976 INFO mechanisms. 256 3. Info Package Behavior 258 As stated in the Conventions section, the term UAC refers to the UAC 259 (sender) of the INFO method and UAS refers to the recipient of the 260 INFO method. "Initiating UA" refers to the sender of an initial 261 INVITE to establish a session and "target UA" refers to the recipient 262 of that INVITE request. 264 3.1. UAS Behavior 266 A UAS supporting this document MUST advertise the set of Info 267 Packages it is willing to receive in Recv-Info header(s) in dialog 268 usage requests and responses for session establishment or target 269 refresh. This includes INVITE, UPDATE, PRACK, ACK, and their non- 270 failure responses (101-199 and 2xx only). 272 Once a UAS indicates support for an Info Package by sending a Recv- 273 Info header with one or more package names, the UAS MUST be prepared 274 to receive an INFO containing that package. Note this may occur 275 before dialog negotiation completes. 277 Recall the UAC of an INVITE may choose to receive (be a UAS for) INFO 278 methods. This UA may chose not to offer any packages in the initial 279 INVITE and subsequently advertise packages from the target UA's 280 subsequent responses, in order to support third-party call control 281 [RFC3725]. 283 A UAS lists multiple packages by enumerating the package name(s), 284 separated by commas, as values for the Recv-Info header in the 285 session establishment exchange. A UAS may also list multiple 286 packages by including multiple Recv-Info headers. The UAS may also 287 combine multiple Recv-Info headers with one or more packages in each 288 header value. If the UAS prefers to receive one package over 289 another, the UAS MUST list the preferred Info Package lexically 290 earlier in the message. That is, by listing it earlier in a list 291 within a given Recv-Info header or listing it in a previous Recv-Info 292 header in a given message. The UAS MUST NOT list a package more than 293 once. This order is only a hint to the UAC, as there is no 294 meaningful way of enforcing the use of a preferred package at the 295 UAC. 297 There is an important issue to consider when the UAS advertises 298 support for multiple packages that one might interpret to be similar 299 or equivalent. The UAC has no method of knowing whether the UAS 300 would like the UAC to send a single INFO request with the preferred 301 package or for the UAC to send multiple INFO requests with the same 302 or similar information. The behavior is entirely up to the UAC and 303 the rules specified by the package definitions. 305 If a UAS does not wish to receive any Info Packages, the UAS MUST 306 indicate this by including one and only one Recv-Info header with the 307 value 'nil'. This enables the UAC to discern the difference between 308 a UAS that understands Info Packages but does not wish to receive any 309 from a legacy UAS that does not understand Info Packages. A UAC 310 conforming to this document can always send or receive legacy INFO 311 usages without packages. 313 Info Package capability advertisement occurs within the context of a 314 session negotiation exchange. The Info Package capability set 315 received by the UAC within the last exchange is the one the UAC will 316 use to chose Info Packages from. Also note that due to glare, an 317 INFO request may be in flight prior to the UAC receiving an updated 318 capability set removing a given Info Package. Thus, the UAS MUST be 319 prepared to handle an INFO request with an Info Package payload with 320 a newly delisted Info Package. Proper handling does include 321 rejecting the request with a 469. See Section 4.3 for more on this 322 topic. 324 3.2. UAC Behavior 326 A UAC MUST NOT send INFO requests for a given INFO package until the 327 UAC receives an "INVITE dialog usage" request or response (for 328 session establishment or target refresh) with a Recv-Info header 329 listing the given Info Package. 331 At any time during an "INVITE dialog usage" request or response, if a 332 UAS sends one or more Recv-Info headers, the UAC MUST replace the old 333 set of supported Info Packages with the collection of Info Packages 334 enumerated by the current message. 336 If the UAS does not send any Recv-Info headers in a message, then the 337 list of supported Info Packages does not change. 339 A UAC MUST cease sending INFO requests for a given INFO package when 340 the UAC receives an "INVITE dialog usage" request or response (for 341 session establishment or target refresh) that does not contain a 342 Recv-Info header listing the given Info Package. Note the UAC MUST 343 be prepared to receive a 469 response (Section 4.3) at any time, even 344 if the UAS advertised it could receive the Info Package. This 345 situation can occur if the UAC sends the INFO request at the same 346 time the UAS advertises it no longer supports the Info Package in 347 question. 349 If the UAC receives a Recv-Info header with the value 'nil', the UAC 350 MUST NOT send any INFO methods that contain Info Packages. 352 The UAS may advertise support for multiple Info Packages. If some of 353 these packages have similar or equivalent functionality and the UAC 354 supports multiple such packages, the UAC SHOULD chose to send Info 355 Package payload(s) from the Info Package listed lexically earlier in 356 the last Recv-Info advertisement the UAC received from the UAS. This 357 document cannot make this protocol action a must strength, as the 358 concept of "similar or equivalent" is highly Info Package specific. 360 INFO itself does not necessitate the use of Require or Proxy-Require 361 headers. There is no token defined for "Supported" headers. If 362 necessary, clients may probe for the support of this version of INFO 363 using the OPTIONS request defined in SIP [RFC3261]. One could 364 envision a particular Info Package implementation that relied on 365 either of these headers. See Section 7 for more on this issue. 367 The presence of the Recv-Info header in a message is sufficient to 368 indicate support for this version of INFO. The "methods" parameter 369 for Contact [RFC3841] is not sufficient to determine if the endpoints 370 support Info Packages, as the INFO method supported might be the 371 obsolete RFC 2976 [RFC2976] version. 373 For Info Packages, this draft does not provide a means of requiring 374 support for a specific Info Package. If the UAS does not indicate 375 support for an Info Package that the UAC requires, and the UAC 376 requires the use of that package, the UAC can use any supported 377 RFC3261 [RFC3261] method to terminate the session. 379 A UAC MAY send a legacy INFO [RFC2976] method at any time. 381 3.3. Package Versions 383 The protocol mechanism described herein does not provide for a 384 package versioning mechanism. This is for two reasons. The first is 385 that if an Info Package has a capability for forward and backward 386 compatibility in the Info Package payload, then that compatibility 387 comes from the application level semantics of the information. This 388 means it is the responsibility of the application to handle such 389 compatibility and not the INFO framework. For example, one could use 390 XML versioning techniques in the payload to indicate versions of the 391 Info Package. 393 The second reason we do not have a package versioning system is not 394 all payloads have sufficient capability to carry payload versions. 396 In this situation, it is highly unlikely payloads will be backwards 397 compatible. That is, what one really is defining is a new Info 398 Package. This is more especially so when one considers User Agents 399 can advertise package support but cannot advertise package version 400 support. Even if we did allow for package versioning, as a parameter 401 to the Recv-Info header value, for example, it is lexically 402 equivalent to having a new Info Package. 404 UACs MUST NOT depend on any lexical parsing of the Info Package name 405 for versioning, such as "fooV1" and "fooV2" or "foo.1" and "foo.2". 407 3.4. Advertisement Example 409 Here is an INVITE. The initiating UA advertises the following. 411 INVITE sip:bob@example.com SIP/2.0 412 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 413 Max-Forwards: 70 414 To: Bob 415 From: Alice ;tag=1928301774 416 Call-ID: a84b4c76e66710@pc33.example.com 417 CSeq: 314159 INVITE 418 Recv-Info: P, R 419 Contact: 420 Content-Type: application/sdp 421 Content-Length: ... 423 ... 425 This means the initiating UA is willing to receive from Info Packages 426 P and R. 428 In this next message, the target UA responds with a 200 OK: 429 SIP/2.0 200 OK 430 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 431 To: Bob ;tag=a6c85cf 432 From: Alice ;tag=1928301774 433 Call-ID: a84b4c76e66710@pc33.example.com 434 CSeq: 314159 INVITE 435 Contact: 436 Recv-Info: R, T 437 Content-Type: application/sdp 438 Content-Length: ... 440 ... 442 This indicates the target UA is willing to receive from Info Packages 443 R and T. 445 The initiating UA then confirms in an ACK, as shown. 447 ACK sip:ngw1@a.example.com SIP/2.0 448 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 449 To: Bob ;tag=a6c85cf 450 From: Alice ;tag=1928301774 451 Call-ID: a84b4c76e66710@pc33.example.com 452 CSeq: 314163 ACK 453 Recv-Info: R 454 Content-Length: 0 456 The target UA can now send from package R to the initiating UA. 457 Moreover, in this example, the target UA may not send from package P, 458 as P no longer is in the initiating UA's Info Package set. 460 4. The INFO Method Request 462 4.1. INFO Requests 464 The INFO method provides additional, application level information 465 that can further enhance a SIP application. It is important to note 466 there are some types of application information for which using INFO 467 messages are inappropriate. See Appendix A for a discussion of this. 469 The UAC MUST include the Info-Package header field when it sends an 470 INFO request carrying an Info Package. The Info-Package header field 471 value in an INFO request MUST contain a single Info Package token. 472 That Info Package token MUST match one of the Info Packages the UAS 473 indicated support for during the negotiation described in Section 3. 475 The UAC MAY send an INFO in a legacy usage context. See Appendix B 476 for examples of legacy usages. In general, a legacy usage is where 477 there is no Info-Package header. In this case, if the UAS has never 478 offered a Recv-Info header or never offered a Recv-Info header with a 479 package of a similar function to the legacy INFO usage, the UAC MAY 480 send an INFO without an Info-Package header field and a body 481 appropriate to the said legacy usage. 483 A UAC MUST NOT use the INFO method outside an INVITE dialog usage. 484 The INFO method has no lifetime or usage of its own, as it is 485 inexorably linked to that of the INVITE. When the INVITE-created 486 session terminates, that signals the termination of the negotiated 487 Info Packages. A UAS that receives an INFO message after the INVITE 488 dialog usage terminates MUST respond with a 481 Call Does Not Exist. 490 The session identifiers defined in RFC 3261 [RFC3261] must match 491 those of the provisional or final responses to the INVITE. As a 492 result, INFO requests cannot fork. The UAC may send INFO requests 493 once the UAS has sent the Recv-Info header field value, indicating 494 what the UAS supports. 496 The converse is not true during initial session establishment. The 497 initiating UA of the first INVITE MUST be prepared to receive 498 multiple INFO requests, as the first INVITE may fork. Since session 499 negotiation has not completed, and we allow early INFO requests, 500 multiple target UAs may respond. This initial session establishment 501 phase is the only time the UAS need be prepared to receive multiple 502 INFO requests, as one would expect there may be messages from non- 503 authoritative forked dialogs prior to their termination. 505 The construction of the INFO request is the same as any other request 506 within an existing INVITE-initiated session. A UAC MAY send an INFO 507 request on both an early and confirmed session. 509 The INFO request MUST NOT carry a Recv-Info header. The UAC can only 510 negotiate Info Packages using the procedures of Section 3. 512 The signaling path for the INFO method is the signaling path 513 established as a result of the session setup. This can be direct 514 signaling between the calling and called user agents or a signaling 515 path involving SIP proxy servers that were involved in the call setup 516 and added themselves to the Record-Route header on the initial INVITE 517 message. 519 4.2. INFO Request Body 521 The purpose of the INFO request is to carry application level 522 information between SIP user agents. The INFO message body SHOULD 523 carry this information, unless the message headers carry the 524 information of interest. Note this is not an invitation to invent 525 SIP headers for the purposes of application level information 526 exchange. Rather, one could envision circumstances where existing 527 SIP headers already convey the information the application has 528 interest in. 530 If the Info Package defines a payload, and the package specification 531 indicates it is appropriate to include a payload with the request, 532 the UAC MUST include the payload with the MIME type specified by the 533 Info Package. 535 If the Info Package definition directs the UAC to send a request 536 without a payload, the UAC MUST send the INFO request without a body. 538 Some SIP extensions, which are orthogonal to INFO, may insert body 539 parts unrelated to the INFO payload. User Agents MUST conform to RFC 540 3261 as updated by body-handling [I-D.ietf-sip-body-handling] to 541 support multipart MIME handling. If there are bodies unrelated to 542 the Info Package, and the Info Package also has a payload, the UAC 543 MUST bundle these elements into a multipart MIME body. In this case, 544 the UAS needs a means to unambiguously identify the body part 545 belonging to the Info Package. To do this, the UAC MUST identify the 546 Info Package payload MIME body part with a Content-Disposition of 547 'Info-Package'. 549 If the payload of an Info Package is already a multipart MIME body, 550 the UAC MUST identify the payload with a Content-Disposition of 551 'Info-Package' in the headers for the appropriate MIME body part. 553 If there is no payload in the INFO request unrelated to the Info 554 Package and the payload of the Info Package is not a multipart MIME, 555 the UAC MUST identify the message, at the SIP header level, with a 556 Content-Disposition of 'Info-Package'. 558 If there is no payload for the Info Package, they UAC MAY omit the 559 Content-Disposition header. 561 NOTE: We could be lazy and even save 33 octets by allowing the UAC 562 to construct a non-multipart MIME payload without a Content- 563 Disposition header. However, mandating the presence makes parsing 564 considerably easier, and it is easier to have it required now than 565 run into a problem later. 567 NOTE: One could offer that the Info-Package header is redundant, 568 as we could have the Info Package name be a parameter for Content- 569 Disposition. However, there could be corner cases with legacy 570 INFO usage that makes this a poor choice. 572 4.3. Responses to the INFO Request Method 574 If a UAS receives an INFO request, it MUST send a final response. A 575 UAS MUST send a 200 OK response for an INFO request with no message 576 body and no Info-Package header if the UAS received the INFO request 577 on an existing session. This protocol action supports legacy use of 578 INFO as a keep-alive mechanism. 580 If the UAS receives an INFO request with an Info-Package the UAS 581 advertised with a Recv-Info in the last session state update and the 582 body of the INFO request is an appropriate MIME type for the Info 583 Package, the UAS MUST send a 200 OK response. 585 If the INFO request contains a body the server does not understand 586 then, in the absence of Info Package associated processing rules for 587 the body, including the absence of an Info-Package header, the server 588 MUST respond with a 415 Unsupported Media Type message. 590 If the INFO request indicates an Info Package type the server does 591 not understand, then the server MUST respond with a 469 Bad INFO 592 Package. In the terminology of Multiple Dialog Usages [RFC5057], 593 this represents a Transaction Only failure. 595 If a server receives an INFO request with a body it understands, but 596 the request has no Info-Package header, the UAS MAY use the body as 597 it sees fit. If the UAS accepts the INFO request, the UAS MUST 598 respond to the INFO request with a 200 OK. This enables legacy use 599 of INFO. If the UAS needs to enforce strict compliance with the 600 current INFO framework described here, the UAS MUST reject the 601 request with a 469. 603 The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message 604 if the INFO request does not match any existing INVITE-initiated 605 session. 607 The UAS MAY send other responses, such as Request Failure (4xx), 608 Server Failure (5xx) and Global Failure (6xx) as appropriate for the 609 request. 611 4.4. Routing Behavior 613 Unless stated otherwise, the protocol rules for the INFO request 614 governing the usage of tags, Route and Record-Route, retransmission 615 and reliability, CSeq incrementing and message formatting follow 616 those in RFC 3261 [RFC3261] as defined for the BYE request. 618 The INFO message MUST NOT change the state of the SIP session. Of 619 course, outside the INFO machinery specific failure responses as 620 documented in the SIP dialog usages document [RFC5057], may cause the 621 INVITE session to terminate. 623 4.5. Behavior of Registrars 625 Registrars receiving a REGISTER request that includes Recv-Info 626 headers MAY store such information and use it for routing purposes. 627 How the registrar uses this information is beyond the scope of this 628 document. 630 4.6. OPTIONS Processing 632 A UAC, the sender of the OPTIONS request, SHOULD include Recv-Info 633 headers, populated appropriately for the packages the UAC supports. 634 The UAS SHOULD include its set of Recv-Info packages. These 635 strictures are of "should" strength because local policy might 636 restrict the advertisement of full capabilities, the UA may know the 637 best choice of equivalent packages to list from local configuration, 638 and so on. 640 The UAS and UAC MUST NOT consider the OPTIONS request to be part of a 641 capabilities negotiation. The OPTIONS request is purely a probe. 642 For the UAC or UAS to renegotiate package support, they must use the 643 procedures described in Section 3. 645 4.7. Order of Delivery 647 The INFO method does not define mechanisms for ensuring in-order 648 delivery for overlapping INFO requests. That is, the UAC can send 649 another INFO request before receiving a transaction response from the 650 UAS to a prior INFO request. While the UAC will increment the CSeq 651 header upon the transmission of new INFO messages, the UAS cannot use 652 the CSeq to determine the sequence of INFO information. All a UAS 653 can determine is the UAC sent one INFO message after another. This 654 is due to the fact that there could be gaps in the INFO message CSeq 655 count caused by a user agent sending re-INVITES or other SIP 656 messages. 658 It is up to the individual Info Package definition to specify what 659 happens when there are overlapping INFO requests. However, since it 660 is legal SIP to have overlapping requests, the application must be 661 able to handle the reception of overlapping requests. Overlapping 662 requests can occur even if the particular instance of an application 663 (Info Package) does not allow it, as the mechanism described here is 664 package-agnostic. Thus, the Info Package needs to define the 665 appropriate response. This is more especially so given the UAC could 666 send from multiple Info Packages. Some of those packages may allow 667 overlapping INFO requests, while others do not. In this situation, 668 it would be hard to tell if the non-overlapping packages were being 669 violated or not. 671 5. Formal INFO Method Definition 673 5.1. INFO Method 675 This document describes one new SIP method: INFO. This document 676 replaces the definition and registrations found in [RFC2976]. 678 This table expands on Tables 2 and 3 in [RFC3261]. 680 Header Where INFO 681 ------ ----- ---- 682 Accept R o 683 Accept-Encoding R o 684 Accept-Encoding 2xx o 685 Accept-Encoding 415 c 686 Accept-Language R o 687 Accept-Language 2xx o 688 Accept-Language 415 c 689 Alert-Info - 690 Allow R o 691 Allow 200 - 692 Allow 405 o 693 Authentication-Info 2xx o 694 Authorization R o 695 Call-ID c m 696 Call-Info o 697 Contact - 698 Content-Disposition o 699 Content-Encoding o 700 Content-Language o 701 Content-Length o 702 Content-Type * 703 CSeq c m 704 Date o 705 Error-Info 3xx-6xx o 706 Expires - 707 From c m 708 Geolocation R o 709 Max-Breadth R - 710 Max-Forwards R o 711 MIME-Version o 712 Min-Expires - 713 Organization o 714 Priority R - 715 Privacy R o 716 Proxy-Authenticate 407 o 717 Proxy-Authorization R o 718 Proxy-Require R o 719 Reason r o 720 Record-Route R o 721 Record-Route 2xx,18x o 722 Require o 723 Retry-After R - 724 Retry-After 404,480,486 o 725 Retry-After 503 o 726 Retry-After 600,603 o 727 Route R o 728 Security-Client R o 729 Security-Server 421,494 o 730 Security-Verify R o 731 Server r o 732 Subject R o 733 Supported R o 734 Supported 2xx o 735 Timestamp o 736 To c m (w/ Tag) 737 Unsupported 420 o 738 User-Agent o 739 Via m 740 Warning r o 741 WWW-Authenticate 401 m 742 WWW-Authenticate 407 o 744 Figure 1: Table 1: Summary of Header Fields 746 5.2. INFO Headers 748 This table expands on tables 2 and 3 in [RFC3261]. 750 Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR 751 ------------------------------------------------------------------------ 752 Info-Package R - - - - - - - o* - - - - - 753 Recv-Info R o - - o o o o - - o - - - 754 Recv-Info 2xx o - - o o - o - - o - - - 755 Recv-Info 1xx o - - o o - o - - o - - - 756 Recv-Info r o - - - o - o - - o - - - 758 * Info-Package is MANDATORY for INFO messages sent using Info 759 Packages as described in this document. Info-Package is OPTIONAL for 760 legacy (RFC2976) INFO messages. 762 Table 2: INFO-related Header Fields 764 5.2.1. Info-Package header 766 This document adds Info-Package to the definition of the element 767 "message-header" in the SIP message grammar. 769 For the purposes of matching Info Package types indicated in Recv- 770 Info with those in the Info-Package header field value, one compares 771 the Info-package-name portion of the Info-package-type portion of the 772 Info-Package header octet-by-octet with that of the Recv-Info header 773 value. That is, the Info Package name is case sensitive. Info- 774 package-param is not part of the comparison-checking algorithm. 776 This document does not define values for Info-Package types. 777 Individual Info Packages define these values. Such documents MUST 778 register such values with IANA. These values are Specification 779 Required [RFC5226]. 781 5.2.2. Recv-Info header 783 This document adds Recv-Info to the definition of the element 784 "general-header" in the SIP [RFC3261] message grammar. Section 3 785 describes the Recv-Info header usage. 787 6. Legacy Uses of INFO 789 Several RFC-defined and other standards-defined uses of RFC 2976 INFO 790 [RFC2976] exist and are in use, as well as numerous proprietary uses. 791 Appendix B describes some of these usages. By definition, 792 identifying such uses has relied on either static local configuration 793 or implicit context determination based on the body Content-Type or 794 Content-Disposition value or some proprietary mechanism. This draft 795 cannot forbid nor avoid such uses, since local configuration can 796 always override standardized mechanisms. 798 To maintain backward compatibility with the extant standardized uses 799 of INFO, a server MAY interpret an INFO request with no "Info- 800 Package" header as being of such legacy use. 802 It should be noted that such legacy use will not "break" the 803 mechanism in this draft. For example, if a UA supports SIP-T 804 [RFC3372], it does so based on static local configuration or based on 805 acceptance of the application/isup body. If it adds support for this 806 draft's Info Package negotiation mechanism, the local configuration 807 still applies, and the UA will send/receive INFO messages based on 808 SIP-T regardless of the Info Package negotiation. It will also be 809 able to send/receive INFO messages based on the Info Packages it 810 negotiated. If, at some future time, an Info Package is defined for 811 SIP-T, the UA can indicate such in the negotiation, and again local 812 configuration would supersede if need be. The UA would not lose the 813 ability to use SIP-T with legacy devices. Rather, it would gain the 814 ability to use it with devices which support this draft and with 815 which it did not have such local configuration set, and could avoid 816 failures related to unsupported bodies. 818 It is the hope of this draft's authors that vendors that implement 819 proprietary INFO uses submit their mechanisms as Info Package 820 extension documents, and follow the Info Package negotiation 821 mechanism defined in this draft. 823 7. Info Package Requirements 825 Info Packages SHOULD NOT reiterate any of the behavior described in 826 this document, unless required for clarity or emphasis. However, 827 such packages MUST describe the behavior that extends or modifies the 828 behavior described in this document. 830 Info Packages MUST NOT weaken any behavior designated with "SHOULD" 831 or "MUST" in this document. However, Info Packages MAY strengthen 832 "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if 833 the application requires it. 835 In addition to the normal sections expected in standards-track RFCs 836 and SIP extension documents, authors of Info Packages need to address 837 each of the issues detailed in the following subsections, whenever 838 applicable. 840 7.1. Applicability 842 This section, which MUST be present, describes why any of the other 843 established user-to-user data transfer protocols are not appropriate 844 for the given Info Package. Common reasons can be a requirement for 845 SIP Proxies or back-to-back User Agents (B2BUAs) to see the 846 application level information. Consideration in this section MUST 847 describe what happens if one or both endpoints encrypt the payload. 849 7.2. Info Package Name 851 This section, which MUST be present, defines the token name that 852 designates the Info Package. The name MUST conform to the token ABNF 853 production described in Section 8. It MUST include the information 854 that appears in the IANA registration of the token. For information 855 on registering such types, see Section 9. 857 7.3. Info Package Parameters 859 If the "Info-Package" header allows parameters to modify the behavior 860 of the Info Package, this section MUST clearly define the syntax and 861 semantics of such parameters. 863 7.4. Info Package Tags 865 If useful for the Info Package to have SIP option tags, this is the 866 place to define the tag. Note that if the Info Package defines a SIP 867 option tag, the Info Package must conform to the SIP Change Process 868 [RFC3427]. 870 7.5. INFO Bodies 872 Each Info Package MUST define what type or types of bodies are 873 expected in INFO requests. Such packages MUST specify or cite 874 detailed specifications for the syntax and semantics associated with 875 such a body. 877 The UAS MUST enumerate every MIME type associated with the Info 878 Packages advertised in the UAS' Recv-Info header the UAS is willing 879 to receive. If a UAC sends a body that includes something not 880 enumerated by the UAS, this is a protocol error and the UAS MUST 881 respond appropriately. 883 7.6. UAC generation of INFO requests 885 Each Info Package MUST describe the process by which a UA generates 886 and sends an INFO request. This includes detailed information about 887 what events cause the UA to send an INFO request. 889 If the Info Package does not allow overlapping (outstanding) INFO 890 requests, the Info Package MUST disclose this in the section 891 describing UA generation of INFO requests. Note the generic protocol 892 machinery of the INFO method has no way of enforcing such a 893 requirement. Section 7.7 describes this situation. 895 7.7. UAS processing of INFO requests 897 The Info Package MAY describe the process followed by the UA upon 898 receipt of an INFO request. Since INFO does not change SIP state, 899 and may not even change application state, there may be no useful 900 guidance required in the Info Package specification for UA 901 processing. 903 If the info Package does not permit overlapping INFO requests, it is 904 important to note the issuance of overlapping INFO requests is an 905 application-layer protocol failure and not an INFO method failure. 906 Therefore, in the event a UAC issues overlapping INFO requests for an 907 Info Package, the UAS MUST NOT return an error response as a result 908 of the overlapping INFO request. Of course, if there are other 909 problems with the request that results in a failure, the UAC issues 910 the appropriate response code. This section of the Info Package 911 specification MUST describe the application level response to 912 overlapping INFO requests. Examples include a new INFO request back 913 to the offending UAC indicating an application error, ignoring the 914 overlapping request and processing it to the UAS' best effort, or 915 terminating the entire SIP session. 917 7.8. Rate of INFO Requests 919 Each Info Package MUST define a requirement of MUST strength which 920 defines an absolute maximum on the rate at which an Info Package of a 921 given type can generate INFO messages by a UA in a session. 923 If possible, a package MUST define a throttle mechanism that allows 924 UAs to further limit the rate of INFO messages. 926 7.9. IANA Registrations 928 The Info Package MUST have an IANA Considerations section that 929 includes definitions for the Info Package Name and, if needed, 930 supported MIME types. 932 7.10. Security Considerations 934 The INFO mechanism transports application level information. One 935 implication of this is INFO messages may require a higher level of 936 protection than the underlying SIP-based session signaling. If the 937 application transports sensitive information, such as credit card 938 numbers, health history, personal identifiers, and so on, the Info 939 Package MUST document security procedures that exceed the default 940 procedures presented in this document. In most circumstances, it is 941 not sufficient for a package to attempt to mandate TLS for the 942 signaling channel to secure the data carried by the INFO. 943 Intermediaries will have access to the payload and past the first 944 hop, there is no way to assure subsequent hops will not transmit the 945 payload in clear text. The only way to ensure secure transport at 946 the application level is to have the security at the application 947 level. The most common method of achieving this is to use end-to-end 948 security techniques such as S/MIME [RFC3851]. If the application 949 demands this level of security, the Info Package definition MUST 950 indicate such. 952 7.11. Examples 954 We RECOMMEND Info Packages include several demonstrative message flow 955 diagrams paired with several typical, syntactically correct, and 956 complete messages. 958 Documents describing Info Packages MUST clearly indicate the examples 959 are informative and not normative, with instructions that 960 implementers refer to the main text of the document for exact 961 protocol details. 963 8. Syntax 965 This section describes the syntax extensions required for the INFO 966 method. The previous sections describe the semantics. Note the 967 formal syntax definitions described in this document use the ABNF 968 format used in SIP [RFC3261] and contain references to elements 969 defined therein. 971 INFOm = %x49.4E.46.4F ; INFO in caps 972 extension-method = INFOm / token 974 Info-Package = "Info-Package" HCOLON Info-package-type 975 Recv-Info = "Recv-Info" HCOLON Info-package-list 976 Info-package-list = "nil" 977 / Info-package-type *( COMMA Info-package-type ) 978 Info-package-type = Info-package-name *( ";" Info-package-param) 979 Info-package-name = token 980 Info-package-param = token 982 NOTE on the Recv-Info production: if the value is "nil", there can be 983 one and only one Recv-Info header in the SIP message. 985 9. IANA Considerations 987 9.1. Update to Registration of SIP INFO Method 989 Please update the existing registration in the SIP Methods and 990 Response Codes registry under the SIP Parameters registry that 991 states: 993 Method: INFO 994 Reference: [RFC2976] 996 to: 998 Method: INFO 999 Reference: [RFCXXXX] 1001 9.2. Registration of the Info-Package Header Field 1003 Please add the following new SIP header field in the Header Fields 1004 subregistry under the SIP Parameters registry. 1006 Header Name: Info-Package 1007 Compact Form: (none) 1008 Reference: [RFCXXXX] 1010 9.3. Registration of the Recv-Info Header Field 1012 Please add the following new SIP header field in the Header Fields 1013 subregistry under the SIP Parameters registry. 1015 Header Name: Recv-Info 1016 Compact Form: (none) 1017 Reference: [RFCXXXX] 1019 9.4. Creation of the Info Packages Registry 1021 Please create a subregistry in the SIP Parameters registry for Info 1022 Packages. This subregistry has a modified First Come First Served 1023 [RFC5226] policy. 1025 The following data elements populate the Info Package Registry. 1026 o Info Package Name: The Info Package Name is a case-sensitive 1027 token. In addition, IANA shall not register multiple Info Package 1028 names that have identical case-insensitive values. 1029 o Info Package Payload MIME Types: A list of zero or more registered 1030 MIME types from the MIME Type Registry. 1031 o Standards Status: Values are "Standards Track" or empty. See 1032 below for a discussion and rules on this field. 1033 o Reference: If there is a published specification describing the 1034 Info Package, place a reference to that specification in this 1035 column. See below for a discussion on this field. 1037 If there is a published specification, the registration MUST include 1038 a reference to such specification. The Standards Status field is an 1039 indicator of the level of community review for the Info Package 1040 specification. If the specification meets the requirements for 1041 Specification Required [RFC5226], the value for the Standards Status 1042 field is "Standards Track". Otherwise, the field is empty. 1044 This document uses the Info Package Name "nil" to represent "no Info 1045 Package present" and as such, IANA shall not honor a request to 1046 register the "nil" Info Package. 1048 The initial population of this table shall be: 1050 Name MIME Type Standards Status Reference 1051 nil Standards Track [RFCXXXX] 1053 9.5. Registration of the Info-Package Content-Disposition 1055 Please add the following registration to the Content-Disposition 1056 registry. The description suitable for the IANA registry is as 1057 follows. 1059 The payload of the message carrying this Content-Disposition header 1060 field value is the payload of an Info Package. 1062 9.6. SIP Response Code 469 Registration 1064 Please register the 469 response code in the Session Initiation 1065 Protocol Parameters - Response Codes registry as follows. 1066 Response Code: 469 1067 Default Reason Phrase: Bad INFO Package 1068 Reference: RFCXXXX 1070 10. Examples 1072 10.1. Simple Info Package 1074 Here Alice sends Bob a simple Info Package payload. 1076 INFO sip:alice@192.0.2.1 SIP/2.0 1077 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1078 To: Alice ;tag=1234567 1079 From: Bob ;tag=abcdefg 1080 Call-Id: 123456mcmxcix 1081 CSeq: 2 INFO 1082 Contact: 1083 Info-Package: foo 1084 Content-type: application/foo 1085 Content-length: 24 1087 I am a foo message type 1089 10.2. Multipart INFO Example 1091 Other SIP extensions can put payloads into an INFO method, 1092 independent of the Info Package. In this case, the Info Package 1093 payload gets put into a Multipart MIME body, with the content 1094 disposition indicating which body belongs to the Info Package. Since 1095 there is one and only one Info Package payload in the message, we 1096 only need to tag which body part goes with the Info Package. 1098 INFO sip:alice@192.0.2.1 SIP/2.0 1099 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1100 To: Alice ;tag=1234567 1101 From: Bob ;tag=abcdefg 1102 Call-Id: 123456mcmxcix 1103 CSeq: 7 INFO 1104 Contact: 1105 Info-Package: foo 1106 mumble-extension: 1107 Content-Type: multipart/mixed;boundary="theboundary" 1108 Content-Length: ... 1110 --theboundary 1111 Content-Type: application/mumble 1112 Content-Id: abcd9999qq 1113 ... 1115 1117 --theboundary 1118 Content-Type: application/foo 1119 Content-Disposition: Info-Package 1120 Content-length: 24 1122 I am a foo message type 1123 --theboundary-- 1125 11. Modifications to SIP Change Process 1127 This document updates RFC 3427 [RFC3427] to add a process for 1128 registering new Info Packages. The process for registering new Info 1129 Packages follows the process outlined in Section 4.3 of RFC 3427 for 1130 the registration of SIP Event Packages. Namely, the registration of 1131 a new SIP Info Package requires the DISPATCH chairs to assign an 1132 individual to perform expert review of the proposal if the work is 1133 not a RAI work item in itself. 1135 12. Security Considerations 1137 By eliminating multiple uses of INFO messages without adequate 1138 community review and by eliminating the possibility for rogue SIP 1139 User Agents from confusing another User Agent by purposely sending 1140 unrelated INFO messages, we expect this document's clarification of 1141 the use of INFO to improve the security of the Internet. Whilst 1142 rogue UACs can still send unrelated INFO messages, this framework 1143 provides mechanisms for which the UAS and other security devices can 1144 filter for approved Info Packages. 1146 If the content of the Info Package payload is private, User Agents 1147 will need to use end-to-end encryption, such as S/MIME, to prevent 1148 access to the content. This is particularly important as transport 1149 of INFO is likely not to be end-to-end, but through SIP proxies and 1150 back-to-back user agents (B2BUA's), which the user may not trust. 1152 The INFO mechanism transports application level information. One 1153 implication of this is INFO messages may require a higher level of 1154 protection than the underlying SIP-based session signaling. In 1155 particular, if one does not protect the SIP signaling from 1156 eavesdropping or authentication and repudiation attacks, for example 1157 by using TLS transport, then the INFO request and its contents will 1158 be vulnerable, as well. Even with SIP/TLS, any SIP hop along the 1159 path from UAC to UAS can view, modify, or intercept INFO requests, as 1160 they can with any SIP request. This means some applications may 1161 require end-to-end encryption of the INFO payload, beyond, for 1162 example, hop-by-hop protection of the SIP signaling itself. Since 1163 the application dictates the level of security required, individual 1164 Info Packages have to enumerate these requirements. In any event, 1165 the INFO Framework described by this document provides the tools for 1166 such secure, end-to-end transport of application data. 1168 One interesting property of Info Package use is one can reuse the 1169 same digest-challenge mechanism used for INVITE-based authentication 1170 for the INFO request. For example, one could use a quality-of- 1171 protection (qop) value of authentication with integrity (auth-int), 1172 to challenge the request and its body, and prevent intermediate 1173 devices from modifying the body. However this assumes the device 1174 which knows the credentials in order to perform the INVITE challenge 1175 is still in the path for the INFO, or that the far-end UAS knows such 1176 credentials. 1178 13. References 1180 13.1. Normative References 1182 [I-D.ietf-sip-body-handling] 1183 Camarillo, G., "Message Body Handling in the Session 1184 Initiation Protocol (SIP)", 1185 draft-ietf-sip-body-handling-06 (work in progress), 1186 March 2009. 1188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1189 Requirement Levels", RFC 2119, BCP 14, March 1997. 1191 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1192 A., Peterson, J., Sparks, R., Handley, M., and E. 1193 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1194 June 2002. 1196 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1197 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1198 May 2008. 1200 13.2. Informative References 1202 [I-D.ietf-speechsc-mrcpv2] 1203 Shanmugham, S. and D. Burnett, "Media Resource Control 1204 Protocol Version 2 (MRCPv2)", 1205 draft-ietf-speechsc-mrcpv2-19 (work in progress), 1206 June 2009. 1208 [I-D.saleem-msml] 1209 Sharratt, G. and A. Saleem, "Media Server Markup Language 1210 (MSML)", draft-saleem-msml-08 (work in progress), 1211 February 2009. 1213 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1214 August 1980. 1216 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1217 RFC 793, September 1981. 1219 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1220 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1221 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1223 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1224 October 2000. 1226 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 1227 RFC 3080, March 2001. 1229 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1230 Event Notification", RFC 3265, June 2002. 1232 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 1233 for Telephones (SIP-T): Context and Architectures", 1234 BCP 63, RFC 3372, September 2002. 1236 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 1237 and B. Rosen, "Change Process for the Session Initiation 1238 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 1240 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1241 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1242 for Instant Messaging", RFC 3428, December 2002. 1244 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1245 Context for Internet Mail", RFC 3458, January 2003. 1247 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1248 Camarillo, "Best Current Practices for Third Party Call 1249 Control (3pcc) in the Session Initiation Protocol (SIP)", 1250 BCP 85, RFC 3725, April 2004. 1252 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1253 Preferences for the Session Initiation Protocol (SIP)", 1254 RFC 3841, August 2004. 1256 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1257 Extensions (S/MIME) Version 3.1 Message Specification", 1258 RFC 3851, July 2004. 1260 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 1261 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 1263 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1264 the Session Description Protocol (SDP)", RFC 4145, 1265 September 2005. 1267 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1268 Media Services with SIP", RFC 4240, December 2005. 1270 [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, 1271 "Interworking between the Session Initiation Protocol 1272 (SIP) and QSIG", BCP 117, RFC 4497, May 2006. 1274 [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol 1275 (SIP) Event Package for Key Press Stimulus (KPML)", 1276 RFC 4730, November 2006. 1278 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1279 RFC 4949, August 2007. 1281 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1282 RFC 4960, September 2007. 1284 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1285 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1287 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1288 Control Markup Language (MSCML) and Protocol", RFC 5022, 1289 September 2007. 1291 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 1292 Initiation Protocol", RFC 5057, November 2007. 1294 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1295 Media Control", RFC 5168, March 2008. 1297 [W3C.REC-voicexml21-20070619] 1298 Porter, B., McGlashan, S., Lee, A., Burnett, D., Carter, 1299 J., Oshry, M., Bodell, M., Baggia, P., Rehor, K., Burke, 1300 D., Candell, E., and R. Auburn, "Voice Extensible Markup 1301 Language (VoiceXML) 2.1", World Wide Web Consortium 1302 Recommendation REC-voicexml21-20070619, June 2007, 1303 . 1305 Appendix A. Info Package Considerations 1307 This section covers several issues that one should take into 1308 consideration when proposing new Info Packages. 1310 A.1. Appropriateness of Usage 1312 When designing an Info Package using the method described in this 1313 document for application level information exchange, it is important 1314 to consider: is INFO and, more importantly, is signaling within a SIP 1315 session, an appropriate mechanism for the problem set? Is it because 1316 it is the most reasonable and appropriate choice, or merely because 1317 "it's easy"? 1319 These are difficult issues to consider, especially when presented 1320 with real-world deadlines and implementation cost issues. However, 1321 choosing to use INFO for inappropriate uses *will* lead to issues in 1322 the real world, not the least of which are certain types of 1323 middleboxes which will remove the device from the network if it is 1324 found to cause damage to other SIP nodes. 1326 Therefore, the following sections provide consideration guidelines 1327 and alternatives to INFO use. 1329 A.2. Dialog Fate-Sharing 1331 INFO, by design, is a method within an INVITE dialog usage. RFC 5057 1332 [RFC5057] enumerates the problems with using dialogs for multiple 1333 usages, and we strongly urge the reader to review RFC 5057. The most 1334 relevant issue is a failure of transmission or processing of an INFO 1335 request may render the INVITE session terminated, depending on the 1336 type of failure. Prior to RFC 5057, it was not clear if the INFO 1337 usage was a separate usage or not. RFC 5057 clarifies the INFO 1338 method is always part of the INVITE usage. 1340 Some uses of INFO can tolerate this fate sharing of the INFO message 1341 over the entire session. For example, in the SIP-T usage, it may be 1342 acceptable for a call to fail, or to tear down the call, if one 1343 cannot deliver the associated SS7 information. The same is usually 1344 true for DTMF. However, it may not be acceptable for a call to fail 1345 if, for example, a DTMF buffer overflows. Then again, for some 1346 services, that may be the exact desired behavior. 1348 A.3. Messaging Rates and Volume 1350 There is no throttling mechanism for INFO. Consider that most call 1351 signaling occurs on the order of 7-10 messages per 3 minutes, 1352 although with a burst of 5-7 messages in one second during call 1353 setup. DTMF tones occur in bursts at a rate of up to 20 messages per 1354 second. This is a considerably higher rate than for call signaling. 1355 Sending constant GPS location updates, on the other hand, would incur 1356 an undue burden on SIP Proxies along the path. 1358 Furthermore, SIP messages tend to be relatively small, on the order 1359 of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct 1360 exchange of bulk data beyond these limits, especially if the headers 1361 plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for 1362 such traffic include MSRP [RFC4975], COMEDIA [RFC4145], or HTTP 1363 [RFC2616]. 1365 A.4. Is there a better alternative? 1367 The first alternative for application level interaction is SIP 1368 Events, also known as SUBSCRIBE/NOTIFY [RFC3265]. In this model, a 1369 user agent requests state information, such as key pad presses from a 1370 device to an application server or key map images from an application 1371 server to a device. The SUBSCRIBE creates a new session that does 1372 not share the fate of the related INVITE-initiated session. 1373 Moreover, using the SUBSCRIBE model enables multiple applications to 1374 receive state updates. These applications can be outside the media 1375 path and potentially outside the INVITE-initiated session's proxy 1376 path. In fact, SIUBSCRIBE/NOTIFY is your only option if you need to 1377 exchange data outside a communications session. 1379 SUBSCRIBE/NOTIFY messages pass through the SIP signaling 1380 infrastructure, such as SIP Proxies and B2BUAs. Application 1381 designers need to understand this can be a feature, as when the User 1382 Agents are exchanging information that elements in the SIP signaling 1383 path need to be aware of. Conversely, this can be a problem, as 1384 messages these network elements have no interest in can put a 1385 significant burden on those element's ability to process other 1386 traffic. Moreover, such network elements may not be able to read 1387 end-to-end encrypted SUBSCRIBE or NOTIFY bodies. 1389 Implementers do need to be aware the price of having a protocol that 1390 works in all cases, can scale, can easily load balance, and will not 1391 mysteriously fail a session in the event of state synchronization 1392 failure does come at a cost. Session establishment is a minimum of 1393 two messages in addition to the INVITE session establishment. If the 1394 SUBSCRIBE application is co-resident with the INVITE application, the 1395 application will have to manage two SIP sessions instead of one. 1396 Tracking the application level state dominates memory and processing 1397 for some applications, and as such, the doubling of SIP sessions is 1398 not an issue. However, for other applications, this may be an issue. 1400 The MESSAGE method [RFC3428] defines one-time instant message 1401 exchange, typically for sending MIME contents for rendering to the 1402 user. 1404 Another model for application level information exchange is to 1405 establish a communication channel in the media plane. One model for 1406 this is MRCPv2 [I-D.ietf-speechsc-mrcpv2]. Here, the INVITE- 1407 initiated session establishes a separate reliable, connection- 1408 oriented channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream. 1409 One uses SIP to locate the remote endpoint, but uses a direct 1410 connection for the UUI. One then can create whatever protocol one 1411 wishes, whether from scratch (as in MRCPv2) or using a substrate such 1412 as BEEP [RFC3080]. 1414 A low latency requirement for the exchange of information is one 1415 strong indicator for using a media channel. Exchanging information 1416 through the SIP routing network can introduce hundreds of 1417 milliseconds of latency. In addition, if there will be a lot of 1418 information exchanged, and there is no need for the SIP routing 1419 network to examine the information, one should use a separate media 1420 channel. 1422 Another model is to use a totally externally signaled channel, such 1423 as HTTP [RFC2616]. In this model, the user agent knows about a 1424 rendezvous point to direct HTTP requests to for the transfer of 1425 information. Examples include encoding of a prompt to retrieve in 1426 the SIP Request URI in RFC 4240 [RFC4240] or the encoding of a SUBMIT 1427 target in a VoiceXML [W3C.REC-voicexml21-20070619] script. 1429 MSRP [RFC4975] defines session-based instant messaging as well as 1430 bulk file transfer and other such large-volume uses. It is part of 1431 an INVITE-based session, similar to other media. Unlike INFO, MSRP 1432 follows a direct media path, rather than through the network elements 1433 composing the SIP signaling path. 1435 A common reason people in the past used INFO for application level 1436 information exchange is the negotiation is very lightweight compared 1437 to SUBSCRIBE/NOTIFY. This is more especially so if it is not certain 1438 if there will be application level information exchange. The 1439 SUBSCRIBE/NOTIFY machinery requires the user agents to exchange rich 1440 capabilities and maintain state for additional SIP sessions. 1441 However, this is a weak argument if there is a high likelihood of 1442 application level information exchange. In this case, we recommend 1443 the use of a more robust application level information exchange 1444 protocol. 1446 A.5. Alternatives for Common INFO Use 1448 What alternatives to INFO are there for UA-to-UA application session 1449 signaling? As noted above, there are three broad classes of session 1450 signaling available. The choice depends on the circumstances. 1451 Following is a list of situations that have used INFO in the past. 1452 o State updates 1453 o User stimulus 1454 o Direct signaling channel 1455 o Proxy-aware signaling 1456 o Dialog probe 1458 A.5.1. State Updates 1460 This is the broad class of one User Agent updating another with 1461 changes in state. The design goal of the SUBSCRIBE/NOTIFY [RFC3265] 1462 event framework is to meet just this need. 1464 A.5.2. User Stimulus: Touch Tones and Others 1466 This is the class of the user entering stimulus at one User Agent, 1467 and the User Agent transporting that stimulus to the other. A key 1468 thing to realize is key presses on the telephone keypad is user 1469 stimulus. Thus, the appropriate mechanism to use here is KPML 1470 [RFC4730]. 1472 A.5.3. Direct Signaling Channel 1474 State updates and user stimulus tend to have relatively few messages 1475 per session. Sometimes, User Agents need to exchange a relatively 1476 high number of messages. In addition, User Agents may have a need 1477 for a relatively low-latency exchange of messages. In this latter 1478 case, the User Agent may not be able to tolerate the latency 1479 introduced by intermediate proxies. Likewise, the intermediate 1480 proxies may have no interest in processing all of that data. 1482 In this case, establishing a separate, direct control channel, as in 1483 MSRP [RFC4975] or MRCPv2 [I-D.ietf-speechsc-mrcpv2] is appropriate. 1485 In addition, not every situation requires a SIP solution. Some 1486 signaling is really just one-shot to third-party endpoints. That 1487 situation may better be handled using an appropriate protocol, such 1488 as HTTP [RFC2616]. 1490 A.5.4. Proxy-Aware Signaling 1492 Sometimes, one does want proxies to be in the signaling path for UA- 1493 to-UA application signaling. In this case, the use of a SIP request 1494 is appropriate. To date, there are no mechanisms for completely 1495 disambiguating INFO requests. For example, one could create a 1496 registry of INFO packages. The definition of the package would 1497 define the contexts for the various MIME Content-Types, as well as 1498 the context of the request itself. However, a package can have 1499 multiple content types. Moreover, having the context, or package 1500 identifier, at the SIP level precludes bundling multiple contexts 1501 responding in the same INFO request. For example, a User Agent might 1502 want to bundle two different responses in a multipart/mixed MIME body 1503 type. 1505 Because there is no difference in either the protocol machinery or 1506 registration process due to these factors, we will not create an INFO 1507 framework. If one needs a SIP User Agent-to-SIP User Agent 1508 application session signaling transport protocol that touches all 1509 Record-Route proxies in a path, one MUST create a new SIP method as 1510 described in Section 27.4 of RFC 3261 [RFC3261]. 1512 A.5.5. Dialog Probe 1514 Some implementations in the wild use INFO to probe if an INVITE- 1515 initiated session is alive. While this works, it is NOT RECOMMENDED. 1516 In particular, RFC 4028 [RFC4028] describes how to ensure an INVITE- 1517 initiated session is alive. 1519 A.5.6. Malicious Indicator 1521 Take the case of Malicious Indicator. This is where a subscriber 1522 receives a call, realizes it is a malicious call (threatening, SPIT, 1523 etc.). They then press the SPIT button (or press *xx), which tells 1524 their service provider to mark the UAC as a bad actor. One might be 1525 tempted to think that INFO would be a great option for this service. 1526 It follows the return path of the INVITE, and so the INFO will hit 1527 the caller's inbound proxy, which it can learn the caller is 1528 (statistically) a bad actor. That way the inbound proxy can do stuff 1529 like notify law enforcement, add a vote to "this is a SPIT source," 1530 or other useful action. 1532 However, consider a few issues. First, since INFO lives exclusively 1533 within an established session, there is no way to assert this message 1534 after the call completes. Second, this mechanism relies on an active 1535 service provider topology. If there is no proxy in the chain that 1536 will eat the INFO, the caller will see the "this is a bad guy" 1537 message, which may have consequences in the real world. Third, there 1538 is no a'priori way for the UAS to know whether it can issue the INFO. 1539 The caller certainly will not advertise, "please tell me if I am bad, 1540 particularly I know in advance that I *am* a bad actor." 1542 One approach is for the service provider's proxy to SUBSCRIBE for the 1543 SPIT event at the UAS. At this point, life is good, interoperable, 1544 and works across networks. This enables events after the session is 1545 torn down, as presumably the SPIT event will refer not to, "this 1546 session," which does not exist, but to "that session identifier," 1547 which exists (and is theoretically unique) forever. 1549 Another approach that saves considerably on the overhead of 1550 subscriptions would be for the service provider to insert a HTTP URI 1551 in the initial INVITE, noting it is for reporting malicious behavior. 1552 When the subscriber presses the SPIT button, an HTTP POST gets 1553 executed, delivering the call information to the service provider. 1554 The service provider can encode basic call information in the HTTP 1555 URI and can instruct the device to send whatever arbitrary data is 1556 necessary in the POST. This method has the added benefit of being 1557 entirely outside the real-time SIP proxy network. 1559 Appendix B. Legacy INFO Usages 1561 We do not intend this section to be a comprehensive catalog of INFO 1562 usages. However, it should give the reader a flavor for current INFO 1563 usages. 1565 B.1. ISUP 1567 SIP-T uses Content-Type to identify ISUP protocol elements in an INFO 1568 message. See RFC3372 [RFC3372]. 1570 B.2. QSIG 1572 QSIG uses Content-Type to identify QSIG protocol elements in an INFO 1573 message. See RFC4497 [RFC4497]. 1575 B.3. MSCML 1577 MSCML uses a Require to ensure the UAS understands that INFO messages 1578 of the MSCML type are in fact MSCML messages. See RFC5022 [RFC5022]. 1580 B.4. MSML 1582 MSML endpoints just know the INFO messages carry MSML and from the 1583 Content-Type of the given INFO method request. See the MSML 1584 [I-D.saleem-msml] draft. 1586 B.5. Video Fast Update 1588 Microsoft, Polycom, and Radvision used INFO messages as an interim 1589 solution for requesting fast video update before the ability to 1590 request I-Frames in RTCP was available. See the XML Schema for Media 1591 Control [RFC5168] for more information. 1593 Appendix C. Acknowledgements 1595 We are standing on the shoulders of giants. Jonathan Rosenberg did 1596 the original "INFO Considered Harmful" Internet Draft on 26 December 1597 2002, which influenced the work group and this document. Likewise, 1598 Dean Willis influenced the text from his Internet Draft, "Packaging 1599 and Negotiation of INFO Methods for the Session Initiation Protocol" 1600 of 15 January 2003. Four paragraphs come from Jonathan Rosenberg's 1601 INFO Litmus draft. My, we have been working on this for a long time! 1603 This and other related drafts have elicited well over 450 messages on 1604 the SIP list. People who have argued with its thesis, supported its 1605 thesis, added to the examples, or argued with the examples, include 1606 the following individuals: 1607 Adam Roach, Bram Verburg, Brian Stucker, Chris Boulton, Cullen 1608 Jennings, Dale Worley, Dean Willis, Frank Miller, Gonzalo 1609 Camarillo, Gordon Beith, Henry Sinnreich, James Jackson, James 1610 Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan 1611 Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, 1612 Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul 1613 Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, 1614 Robert Sparks, Roland Jesske, Salvatore Loreto, Sam Ganesan, 1615 Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg, and 1616 Xavier Marjou. 1618 John Elwell and Francois Audet helped with QSIG references. In 1619 addition, Francois Audet provided actual text for the revised 1620 abstract. Keith Drage gave lots of excellent comments and helped 1621 immensely with Figure 1. 1623 The work group version of this document benefited from the close 1624 readings and comments from 1625 John Elwell, Paul Kyzivat, Dean Willis, Francois Audet, Dale 1626 Worley, Andrew Allen, Adam Roach, Anders Kristensen, Gordon Beith, 1627 Ben Campbell, Bob Penfield, Keith Drage, Jeroen van Bemmel, Mary 1628 Barnes, and Salvatore Loreto. 1630 Since publication of the first work group version of this document, 1631 we have had over 329 messages. New voices in addition to those 1632 included above include 1633 Arun Arunachalam, Christian Stredicke, Eric Rescorla, Inaki Baz 1634 Castillo, and Roni Evan. 1636 However, any errors and issues we missed are still our own. 1638 Appendix D. Change Log 1640 [RFC EDITOR NOTE: Please remove this section when publishing] 1642 Changes from draft-ietf-sip-info-events-03 1643 o Clarified Abstract language 1644 o All SIP dialogs are now refered to as sessions 1645 o Clarified the image example in the Introduction 1646 o Clarified the relationship (none) between SIP Event Packages and 1647 SIP Info Packages 1648 o Really, really clarified the protocol is NOT a negotiation but an 1649 advertisement 1650 o Split Section 3 into UAS and UAC behavior 1651 o Moved the example in section 3 into its own sub-section, and used 1652 full SIP headers 1653 o Clarified forking behavior 1654 o Clarified language around when to send a body 1655 o Added 469 error response, instead of reusing 489 1656 o Clarified overlapping INFO method handling 1657 o Fixed table 1 to follow 3261, not 2543 1658 o Added REFER to the INFO Headers table 1659 o replaced token-nodot with token for Info-Package values 1660 o Clarified end-to-end security considerations 1661 o Info Package parameters are semi-colon delimited, not dot 1662 delimited 1664 Changes from -02 1665 o Applicability statement explicitly says we're backwards compatible 1666 o Explicitly state we work like UPDATE (both early and confirmed 1667 dialogs) 1668 o Agreed text for IANA Considerations package registry 1670 Changes from -01 1671 o One and only one Info Package per INFO 1672 o Removed Send-Info header, greatly simplifying negotiation 1673 o Multiple body part identification through Content-Disposition: 1674 Info-Package 1675 o Note that forking INVITEs may result in multiple INFO's coming 1676 back to INVITE originator 1677 o Describe how a UAS can enforce strict adherence to this document 1678 o Remove CANCEL INFO faux pas 1679 o Better explained overlapping INFO issues and resolutions 1680 o Token names are now really case sensitive 1681 o Moved Info Package Considerations to an Appendix 1682 o Introduced stronger, yet more open, IANA registration process 1683 o Took a few more paragraphs from INFO Litmus to cover all bases. 1684 o Added RFC 5168 to legacy usages 1686 Changes from -00 1687 o Corrected ABNF. 1688 o Enabled sending of legacy INFO messages. Receiving legacy INFO 1689 messages was already here. 1690 o Negotiation is not Offer/Answer, it is Offer/Offer. 1691 o Created the explicit "nil" Info Package to indicate no info 1692 package. 1693 o Fixed CANCEL impacting future transactions. 1694 o Added Registrar behavior. 1695 o Added OPTIONS processing. 1696 o Clarified overlapping INFO method processing. 1697 o Described multiple INFO bodies in a single INFO method. 1698 o Took out Info-Package as a header for responses to the INFO 1699 method. 1700 o Expanded on risks of using INFO and filled-in more on the 1701 alternatives 1702 o Moved definitions of INFO into the body of the text and cleaned up 1703 IANA Considerations section 1705 o Added legacy usages descriptions 1707 Authors' Addresses 1709 Eric W. Burger 1710 NeuStar, Inc. 1711 46000 Center Oak Plaza 1712 Sterling, VA 20166-6579 1713 USA 1715 Email: eburger@standardstrack.com 1716 URI: http://www.standardstrack.com 1718 Hadriel Kaplan 1719 Acme Packet 1720 71 Third Ave. 1721 Burlington, MA 01803 1722 USA 1724 Phone: 1725 Fax: 1726 Email: hkaplan@acmepacket.com 1727 URI: 1729 Christer Holmberg 1730 Ericsson 1731 Hirsalantie 11 1732 Jorvas, 02420 1733 Finland 1735 Phone: 1736 Fax: 1737 Email: christer.holmberg@ericsson.com 1738 URI: