idnits 2.17.1 draft-ietf-sip-info-events-03.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 651 has weird spacing: '...3xx-6xx o...' == Line 697 has weird spacing: '... 2xx o ...' == Line 698 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 27, 2009) is 5568 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 990, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-sip-body-handling-05 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-28) exists of draft-ietf-speechsc-mrcpv2-17 == Outdated reference: A later version (-09) exists of draft-saleem-msml-07 -- 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 (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP E. Burger 3 Internet-Draft This Space For Sale 4 Obsoletes: RFC 2976 H. Kaplan 5 (if approved) Acme Packet 6 Intended status: Standards Track C. Holmberg 7 Expires: July 31, 2009 Ericsson 8 January 27, 2009 10 Session Initiation Protocol (SIP) INFO Method and Package Framework 11 draft-ietf-sip-info-events-03 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 July 31, 2009. 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 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This document defines the new SIP INFO method and a mechanism for 51 defining, negotiating and exchanging Info Packages that use the INFO 52 method. Applications that need to exchange session-related 53 information within a SIP INVITE-created dialog, also known as 54 application level information, use these INFO requests. This draft 55 addresses issues and open items from RFC 2976 and replaces it. 57 Conventions Used in this Document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 The terminology in this document conforms to the Internet Security 63 Glossary [RFC4949]. 65 Be mindful of the terms User Agent Server (UAS) and User Agent Client 66 (UAC). This document strictly follows RFC 3261 [RFC3261]. The UAC 67 issues a SIP request and the UAS responds. This terminology may be 68 confusing when one combines the INFO case with the INVITE case. For 69 an INVITE, the initiator of the session is the UAC and the target of 70 the session is the UAS. However, it is possible for the target UA of 71 the session, the UAS of the INVITE transaction, to send an INFO to 72 the initiating UA of the session, the UAC of the INVITE transaction. 73 From the perspective of the INFO, the target UA of the session 74 (INVITE UAS) is, in fact, the UAC (sender) of the INFO request. 75 Likewise, from the perspective of the INFO, the initiating UA of the 76 session (INVITE UAC) is the UAS (recipient) of the INFO request. 77 Since this document strictly follows RFC 3261, we refer to the UA 78 that issues the INVITE as the "initiating UA" and the UA that 79 responds to the INVITE as the "target UA" to remove any confusion. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3. Info Package Negotiation . . . . . . . . . . . . . . . . . . . 7 86 3.1. UA Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 87 3.2. Package Versions . . . . . . . . . . . . . . . . . . . . . 9 88 4. The INFO Method Request . . . . . . . . . . . . . . . . . . . 10 89 4.1. INFO Requests . . . . . . . . . . . . . . . . . . . . . . 10 90 4.2. INFO Request Body . . . . . . . . . . . . . . . . . . . . 11 91 4.3. Responses to the INFO Request Method . . . . . . . . . . . 12 92 4.4. Routing Behavior . . . . . . . . . . . . . . . . . . . . . 13 93 4.5. Behavior of Registrars . . . . . . . . . . . . . . . . . . 13 94 4.6. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . 13 95 4.7. Order of Delivery . . . . . . . . . . . . . . . . . . . . 14 96 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 14 97 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 14 98 5.2. INFO Headers . . . . . . . . . . . . . . . . . . . . . . . 16 99 5.2.1. Info-Package header . . . . . . . . . . . . . . . . . 16 100 5.2.2. Recv-Info header . . . . . . . . . . . . . . . . . . . 16 101 6. Legacy Uses of INFO . . . . . . . . . . . . . . . . . . . . . 17 102 7. Info Package Requirements . . . . . . . . . . . . . . . . . . 17 103 7.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 18 104 7.2. Info Package Name . . . . . . . . . . . . . . . . . . . . 18 105 7.3. Info Package Parameters . . . . . . . . . . . . . . . . . 18 106 7.4. Info Package Tags . . . . . . . . . . . . . . . . . . . . 18 107 7.5. INFO Bodies . . . . . . . . . . . . . . . . . . . . . . . 18 108 7.6. UAC generation of INFO requests . . . . . . . . . . . . . 19 109 7.7. UAS processing of INFO requests . . . . . . . . . . . . . 19 110 7.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 19 111 7.9. IANA Registrations . . . . . . . . . . . . . . . . . . . . 19 112 7.10. Security Considerations . . . . . . . . . . . . . . . . . 20 113 7.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 114 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 116 9.1. Update to Registration of SIP INFO Method . . . . . . . . 21 117 9.2. Registration of the Info-Package Header Field . . . . . . 21 118 9.3. Registration of the Recv-Info Header Field . . . . . . . . 21 119 9.4. Creation of the Info Packages Registry . . . . . . . . . . 22 120 9.5. Registration of the Info-Package Content-Disposition . . . 22 121 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 122 10.1. Single Info Package . . . . . . . . . . . . . . . . . . . 23 123 10.2. Multipart INFO Example . . . . . . . . . . . . . . . . . . 24 124 11. Modifications to SIP Change Process . . . . . . . . . . . . . 24 125 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 126 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 127 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 128 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 130 Appendix A. Info Package Considerations . . . . . . . . . . . . . 28 131 A.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 28 132 A.2. Dialog Fate-Sharing . . . . . . . . . . . . . . . . . . . 29 133 A.3. Messaging Rates and Volume . . . . . . . . . . . . . . . . 29 134 A.4. Is there a better alternative? . . . . . . . . . . . . . . 29 135 A.5. Alternatives for Common INFO Use . . . . . . . . . . . . . 31 136 A.5.1. State Updates . . . . . . . . . . . . . . . . . . . . 31 137 A.5.2. User Stimulus: Touch Tones and Others . . . . . . . . 32 138 A.5.3. Direct Signaling Channel . . . . . . . . . . . . . . . 32 139 A.5.4. Proxy-Aware Signaling . . . . . . . . . . . . . . . . 32 140 A.5.5. Dialog Probe . . . . . . . . . . . . . . . . . . . . . 33 141 A.5.6. Malicious Indicator . . . . . . . . . . . . . . . . . 33 142 Appendix B. Legacy INFO Usages . . . . . . . . . . . . . . . . . 34 143 B.1. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 144 B.2. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 145 B.3. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 146 B.4. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 147 B.5. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 148 B.6. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 149 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 34 150 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 35 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 153 1. Introduction 155 The SIP protocol [RFC3261] defines session control messages used to 156 setup and tear down a SIP controlled session. In addition, a SIP 157 User Agent (UA) can use the re-INVITE and UPDATE methods during a 158 session to change the characteristics of the session. Most often, 159 this is to change the properties of media flows related to the 160 session or to update the SIP session timer [RFC4028]. The purpose of 161 the INFO message [RFC2976] is to carry application level information 162 along the SIP signaling path. Note the INFO method does not change 163 the SIP dialog state. It may, however, change application state for 164 applications using the SIP dialog. 166 While INFO has been widely adopted for specific application use 167 cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither 168 defined a negotiation mechanism nor a means by which to explicitly 169 indicate the type of application information contained in the INFO 170 message. This led to problems associated with static configuration. 171 In addition, the industry realized there was a potential for 172 interoperability problems due to undefined content syntax and 173 semantics. This draft addresses these deficiencies and provides a 174 framework for explicit negotiation of capabilities and content 175 context using "Info Packages". 177 The INFO method as defined by RFC 2976 did not provide any context 178 for the information the request carried. While it may sometimes be 179 clear what the content is based on the Content-Type, this is only 180 true where there is only one contextual usage of the content-type. 181 For example, if the Content-Type is "image/jpeg", the MIME-attached 182 content is a JPEG image. However, there is no indication what the 183 purpose of the image is. The image could be a caller-id picture, a 184 contact icon, a photo for sharing, and so on. The sender does not 185 know which JPEG to give the receiver if the receiver supports a JPEG 186 content type, and the receiver does not know which JPEG the client is 187 sending if the receiver supports receiving more than one JPEG content 188 type. Thus we need a well defined and documented statement of what 189 the information sent is for. This situation is identical to the 190 context issue in Internet Mail [RFC3458]. RFC 3458 goes into this 191 and other issues in detail. 193 Event Packages [RFC3265] perform the role of disambiguating the 194 context of a message for subscription-based events. This document 195 provides a similar framework for INVITE-based application level 196 information exchange. The mechanism defined in this draft has no 197 relationship to the SUBSCRIBE and NOTIFY methods. The mechanism 198 defined here neither creates a separate subscription dialog nor a 199 subscription usage within an existing dialog. Instead, it uses the 200 INVITE method and its responses to indicate and negotiate supported 201 Info Packages, and the INFO method to convey the Info Packages. This 202 mechanism is not appropriate for IANA-registered Subscribe Event 203 [RFC3265] package types. Info Package definitions and registrations 204 indicate support for this mechanism when one registers them with 205 IANA. 207 Each UA enumerates which Info Packages it can receive. If the far 208 end indicates it can receive a package offered by the near end, the 209 near end can send INFO methods containing the payload for that 210 package. Likewise, if the near end indicates it can receive a 211 package, the far end can send INFO methods containing the payload for 212 that package. The Recv-Info header indicates which packages a UA is 213 willing to receive. The Info-Package header indicates which package 214 a particular INFO method request belongs to. There is a reserved 215 Info Package, "nil", which indicates the UA conforms to this 216 document, but does not wish to receive Info Packages. This enables 217 other UAs that conform with this document to detect legacy UAs, as 218 the legacy UA will not include a Recv-Info header in their SIP dialog 219 establishment or modification requests. Section 3 describes the 220 negotiation in detail. 222 This document does not describe any specific Info Package type 223 extensions. One must extend this protocol by other documents, herein 224 referred to as "Info Packages". Section 7 describes guidelines for 225 creating these extensions. 227 The INFO method does not change the state of SIP calls or the 228 parameters of the sessions SIP initiates. It merely sends optional 229 application layer information, generally related to the session. 231 Applications need to be aware that application level information 232 transported by the INFO method constitutes mid-dialog signaling. 233 These messages traverse the post-session-setup SIP signaling path. 234 This is the path taken by SIP re-INVITEs, BYEs, and other SIP 235 requests within an individual dialog. SIP proxy servers will 236 receive, and potentially act on, mid-dialog signaling information. 237 Application designers need to understand this can be a feature, as 238 when the User Agents are exchanging information that elements in the 239 SIP signaling path need to be aware of. Conversely, this can be a 240 problem, as messages these network elements have no interest in can 241 put a significant burden on those element's ability to process other 242 traffic. Moreover, such network elements may not be able to read 243 end-to-end encrypted INFO bodies. 245 2. Applicability 247 This document replaces the SIP INFO method document [RFC2976] to 248 include explicit negotiation of supported Info Packages in the INVITE 249 transaction and indication of the Info Package to use by using a new 250 header field in the INFO request. As described in Section 4.1, the 251 mechanism described here is backwards-compatible with legacy, RFC 252 2976 INFO mechanisms. 254 3. Info Package Negotiation 256 To be abundantly clear, as stated in the Conventions section, the 257 term UAC refers to the UAC (sender) of the INFO method and UAS refers 258 to the recipient of the INFO method. "Initiating UA" refers to the 259 sender of an initial INVITE to establish a session and "target UA" 260 refers to the recipient of that INVITE request. 262 3.1. UA Behavior 264 A UA supporting this document MUST advertise a set of Recv-Info 265 packages in the initial INVITE exchange. This includes the initial 266 INVITE request, as well as provisional 1xx, final 2xx responses, and 267 the ACK. The initiating UA (UAC of the INVITE) may choose not to 268 offer any packages in the initial INVITE and negotiate packages from 269 the target UA's subsequent responses and the ACK, in order to support 270 third-party call control [RFC3725]. 272 Info Package negotiation may occur any time the UAs negotiate session 273 parameters. There are two cases to consider for SIP dialog parameter 274 negotiation: the initial INVITE transaction and subsequent 275 renegotiation. By subsequent renegotiation, we mean procedures such 276 as re-INVITE and UPDATE [RFC3311]. In the first case, dialog 277 establishment (the initial INVITE transaction), the UAC MUST NOT send 278 INFO requests for a given Info Package until the UAS lists the given 279 Info Package in a Recv-Info header. If the UAS sends a subsequent 280 message in the dialog establishment exchange that removes a listed 281 Info Package, the UAC MUST NOT send INFO requests for that package. 282 In the second case, dialog renegotiation, the UAC MUST NOT send INFO 283 requests for a newly listed Info Package until the dialog 284 renegotiation exchange successfully completes and the newly listed 285 Info Package is in the UAS' final renegotiation exchange message. 287 A UAS lists multiple packages by enumerating the package name(s), 288 separated by commas, as values for the Recv-Info header in the 289 session establishment exchange. A UAS can also list multiple 290 packages by including multiple Recv-Info headers. The UAS can also 291 combine multiple Recv-Info headers with one or more packages in each 292 header value. If the UAS has a preference for receiving one package 293 over another, the UAS MUST list the preferred Info Package lexically 294 earlier in the message. That is, by listing it earlier in a list 295 within a given Recv-Info header or listing it in a previous Recv-Info 296 header in a given message. Listing a package multiple times does no 297 harm. As far as a hint to the UAC, the first appearance is what the 298 UAC uses for determining the UAS' preference. Note this order is 299 only a hint to the UAC, as there is no meaningful way of enforcing 300 the use of a preferred package at the UAC. 302 If a UAS does not wish to receive any Info Packages, the UAS MUST 303 indicate this by including one and only one Recv-Info header with the 304 value 'nil'. This enables the UAC to discern the difference between 305 the UAS understanding Info Packages but not wishing to receive any 306 from a UAS that does not understand Info Packages. A UAC conforming 307 to this document can always send or receive legacy INFO usages 308 without packages. 310 NOTE: We could allow an empty Recv-Info header to indicate the UAS 311 does not wish to receive Info Packages. Semantically that is what 312 this means, as there is no null package. However, this is sloppy 313 and we may find we need an explicit value here in the event we 314 require a richer negotiation strategy. Since mandating nil at 315 this time is no burden, and it will be a burden in the future if 316 we do not specify it now, we specify it now. 318 Info Package capability negotiation occurs within the context of a 319 single session negotiation exchange. Moreover, the last capability 320 set received within the exchange is the one the receiver applies 321 against its advertised capability set. For example, if in an INVITE, 322 the initiating UA offers the following. 324 INVITE ... 325 ... 326 Recv-Info: P, R 327 ... 329 The target UA responds with a 200 OK, and the initiating UA then 330 confirms in an ACK, as shown. 332 ACK 333 ... 334 Recv-Info: R, T 335 ... 337 The target UA can now send from package T to the initiating UA. 338 Moreover, in this example, the target UA may not send form package P, 339 as P no longer is in the initiating UA's Info Package set. 341 The limitation on requiring the negotiation to occur within the 342 context of a session negotiation exchange means that if the 343 initiating UA issues a re-INVITE (after the above ACK) with the 344 following. 346 INVITE ... 347 ... 348 Recv-Info: P, R, T 349 ... 351 The target UA MUST NOT send any package P INFO methods until the 352 target UA sees P in the final ACK from the initiating UA. 354 In the case of a SIP dialog refresh, if the initiating UA and target 355 UA wishes to keep their Info Package set active, the UAs MUST include 356 the Recv-Info header with the appropriate values. Otherwise, if the 357 UA neglects to include the Recv-Info header, the other UA in the dial 358 will assume the first UA no longer supports INFO as specified by this 359 document. 361 INFO itself does not necessitate the use of Require or Proxy-Require 362 headers. There is no token defined for "Supported" headers. If 363 necessary, clients may probe for the support of this version of INFO 364 using the OPTIONS request defined in SIP [RFC3261]. One could 365 envision a particular Info Package implementation that relied on 366 either of these headers. See Section 7 for more on this issue. 368 The presence of the Recv-Info header in a message is sufficient to 369 indicate support for this version of INFO. The "methods" parameter 370 for Contact [RFC3841] is not sufficient to determine if the endpoints 371 support Info Packages, as the INFO method supported might be the 372 obsolete RFC 2976 [RFC2976] version. 374 For Info Packages, this draft does not provide a means of requiring 375 support for a specific Info Package. If the far-end UA does not 376 indicate support for an Info Package that the local server requires, 377 the server MAY terminate the session with a CANCEL or BYE request. 379 3.2. Package Versions 381 The protocol mechanism described herein does not provide for a 382 package versioning mechanism. This is for two reasons. The first is 383 that if an Info Package has a capability for forward and backward 384 compatibility in the Info Package payload, then that compatibility 385 comes from the application level semantics of the information. This 386 means it is the responsibility of the application to handle such 387 compatibility and not the INFO framework. For example, one could use 388 XML versioning techniques in the payload to indicate versions of the 389 Info Package. 391 The second reason we do not have a package versioning system is if 392 the payload is not sufficient to carry payload versions, then it is 393 highly unlikely payloads would be backwards compatible. That is, 394 what one really is defining is a new Info Package. This is more 395 especially so when one considers User Agents can negotiate package 396 support but cannot negotiate package version support. 398 4. The INFO Method Request 400 4.1. INFO Requests 402 The INFO method provides additional, application level information 403 that can further enhance a SIP application. It is important to note 404 there are some types of application information for which using INFO 405 messages are inappropriate. See Appendix A for a discussion of this. 407 The UAC MUST include the Info-Package header field when it sends an 408 INFO request carrying an Info Package. The Info-Package header field 409 value in an INFO request MUST contain a single Info Package token. 410 That Info Package token MUST match one of the Info Packages the UAS 411 indicated support for during the negotiation described in Section 3. 413 The UAC MAY send an INFO in a legacy usage context. See Appendix B 414 for examples of legacy usages. In general a legacy usage is where 415 there is no Info-Package header. In this case, if the UAS has never 416 offered a Recv-Info header or never offered a Recv-Info header with a 417 package of a similar function to the legacy INFO usage, the UAC MAY 418 send an INFO without an Info-Package header field and a body 419 appropriate to the said legacy usage. 421 A UAC MUST NOT use the INFO method outside an INVITE dialog usage. 422 The INFO method has no lifetime or usage of its own, as it is 423 inexorably linked to that of the INVITE. When the INVITE-created 424 dialog terminates, that signals the termination of the negotiated 425 Info Packages. A UAS that receives an INFO message after the INVITE 426 dialog usage terminates MUST respond with a 481 Call Does Not Exist. 428 The dialog identifiers defined in RFC 3261 [RFC3261] must match those 429 of the provisional or final responses to the INVITE. As a result, 430 INFO requests cannot fork. The UAC may send INFO requests once the 431 UAS has sent the Recv-Info header field value, indicating what the 432 UAS supports. 434 The converse is not true during initial session establishment. The 435 initiating UA of the first INVITE MUST be prepared to receive 436 multiple INFO requests, as the first INVITE may fork. Since dialog 437 negotiation has not completed, and we allow early INFO requests, 438 multiple target UAs may respond. This initial dialog establishment 439 phase is the only time the UAS need be prepared to receive multiple 440 INFO requests, as we require post-session-establishment negotiation 441 to fully complete before a UAC can send an INFO request. 443 The construction of the INFO request is the same as any other request 444 within an existing INVITE-initiated dialog. A UAC MAY send an INFO 445 request on both an early and confirmed dialog. 447 The INFO request MUST NOT carry a Recv-Info header. The UAC can only 448 negotiate Info Packages using the procedures of Section 3. 450 The signaling path for the INFO method is the signaling path 451 established as a result of the dialog setup. This can be direct 452 signaling between the calling and called user agents or a signaling 453 path involving SIP proxy servers that were involved in the call setup 454 and added themselves to the Record-Route header on the initial INVITE 455 message. 457 4.2. INFO Request Body 459 The purpose of the INFO request is to carry application level 460 information between SIP user agents. The INFO message body SHOULD 461 carry this information, unless the message headers carry the 462 information of interest. Note this is not an invitation to invent 463 SIP headers for the purposes of application level information 464 exchange. Rather, one could envision circumstances where existing 465 SIP headers already convey the information the application has 466 interest in. 468 If the Info Package defines a payload, and the UAC determines it is 469 appropriate to send that payload to the UAS, the UAC MUST include the 470 payload, with the MIME type specified by the Info Package. 472 If the Info Package allows the UAC to send a request without a 473 payload, the UAC MAY send the INFO request without a body. 475 Some SIP extensions, which are orthogonal to INFO proper, may insert 476 body parts unrelated to the INFO payload. User Agents MUST conform 477 to RFC 3261 as updated by body-handling [I-D.ietf-sip-body-handling] 478 to support multipart MIME handling. If there are bodies unrelated to 479 the Info Package, and the Info Package also has a payload, the UAC 480 MUST bundle these elements into a multipart MIME body. In this case, 481 the UAS needs a means to unambiguously identify the body part 482 belonging to the Info Package. To do this, the UAC MUST identify the 483 Info Package payload MIME body part with a Content-Disposition of 484 'Info-Package'. 486 If the payload of an Info Package is already a multipart MIME body, 487 the UAC MUST identify the payload with a Content-Disposition of 488 'Info-Package' in the headers for the appropriate MIME body part. 490 If there is no payload in the INFO request unrelated to the Info 491 Package and the payload of the Info Package is not a multipart MIME, 492 the UAC MUST identify the message, at the SIP header level, with a 493 Content-Disposition of 'Info-Package'. 495 If there is no payload for the Info Package, they UAC MAY omit the 496 Content-Disposition header. 498 NOTE: We could be lazy and even save 33 octets by allowing the UAC 499 to construct a non-multipart MIME payload without a Content- 500 Disposition header. However, mandating the presence makes parsing 501 considerably easier, and it is easier to have it required now than 502 run into a problem later. 504 NOTE: One could offer that the Info-Package header is redundant, 505 as we could have the Info Package name be a parameter for Content- 506 Disposition. However, there could be corner cases with legacy 507 INFO usage that makes this a poor choice. 509 4.3. Responses to the INFO Request Method 511 If a UAS receives an INFO request it MUST send a final response. A 512 UAS MUST send a 200 OK response for an INFO request with no message 513 body and no Info-Package header if the UAS received the INFO request 514 on an existing dialog. This protocol action supports legacy use of 515 INFO as a keep-alive mechanism. 517 If the UAS receives an INFO request with an Info-Package the UAS 518 advertised with a Recv-Info in the last dialog state update and the 519 body of the INFO request is an appropriate MIME type for the Info 520 Package, the UAS MUST send a 200 OK response. 522 If the INFO request contains a body the server does not understand 523 then, in the absence of Info Package associated processing rules for 524 the body, including the absence of an Info-Package header, the server 525 MUST respond with a 415 Unsupported Media Type message. 527 If the INFO request indicates an Info Package type the server does 528 not understand, then the server MUST respond with a 489 Bad Event. 529 The server then MUST terminate the INVITE dialog, as this represents 530 a protocol failure. 532 NOTE: Some may think "Bad Event" implies there is a link between 533 INFO and NOTIFY. However, what this does is refine 489 to mean, 534 "Received some package in some context that I do not understand," 535 where today the possible contexts are INFO and NOTIFY. The text 536 is irrelevant and the meaning is clear from the context. 538 If a server receives an INFO request with a body it understands, but 539 it has no Info-Package header, the UAS MAY use the body as it sees 540 fit. The UAS SHOULD respond to the INFO request with a 200 OK. This 541 enables legacy use of INFO. The UAS MAY reject the request with a 542 489 if the UAS needs to enforce strict compliance with the current 543 INFO framework described here. 545 The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message 546 if the INFO request does not match any existing INVITE-initiated 547 dialog. 549 The UAS MAY send other responses, such as Request Failure (4xx), 550 Server Failure (5xx) and Global Failure (6xx) as appropriate for the 551 request. 553 4.4. Routing Behavior 555 Unless stated otherwise, the protocol rules for the INFO request 556 governing the usage of tags, Route and Record-Route, retransmission 557 and reliability, CSeq incrementing and message formatting follow 558 those in RFC 3261 [RFC3261] as defined for the BYE request. 560 The INFO message MUST NOT change the state of the SIP dialog. Of 561 course, outside the INFO machinery specific failure responses as 562 documented in the SIP dialog usages document [RFC5057], may cause the 563 INVITE dialog to terminate. 565 4.5. Behavior of Registrars 567 Registrars receiving a REGISTER request that includes Recv-Info 568 headers MAY store such information and use it for routing purposes. 569 How the registrar uses this information is beyond the scope of this 570 document. 572 4.6. OPTIONS Processing 574 A UAC, the sender of the OPTIONS request, SHOULD include Recv-Info 575 headers, populated appropriately for the packages the UAC supports. 576 The UAS SHOULD include its set of Recv-Info packages. These 577 strictures are of "should" strength because local policy might 578 restrict the advertisement of full capabilities, the UA may know the 579 best choice of equivalent packages to list from local configuration, 580 and so on. 582 The UAS and UAC MUST NOT consider the OPTIONS request to be part of a 583 capabilities negotiation. The OPTIONS request is purely a probe. 584 For the UAC or UAS to renegotiate package support, they must use the 585 procedures described in Section 3. 587 4.7. Order of Delivery 589 The INFO method does not define mechanisms for ensuring in-order 590 delivery for overlapping INFO requests. That is, the UAC can send 591 another INFO request before receiving a transaction response from the 592 UAS to a prior INFO request. While the UAC will increment the CSeq 593 header upon the transmission of new INFO messages, the UAS cannot use 594 the CSeq to determine the sequence of INFO information. This is due 595 to the fact that there could be gaps in the INFO message CSeq count 596 caused by a user agent sending re-INVITES or other SIP messages. 598 It is up to the individual Info Package definition to specify what 599 happens when there are overlapping INFO requests. However, since it 600 is legal SIP to have overlapping requests, the application must be 601 able to handle the reception of overlapping requests, even if the 602 Info Package does not allow for it. Since overlapping requests can 603 occur even if the application (Info Package) does not allow it, the 604 Info Package needs to define the appropriate response. This is more 605 especially so given the UAC could send from multiple Info Packages. 606 Some of those packages may allow overlapping INFO requests, while 607 others do not. In this situation, it would be hard to tell if the 608 non-overlapping packages were being violated or not. 610 5. Formal INFO Method Definition 612 5.1. INFO Method 614 This document describes one new SIP method: INFO. This document 615 replaces the definition and registrations found in [RFC2976]. 617 This table expands on Tables 2 and 3 in [RFC3261]. 619 Table 1: Summary of Header Fields 620 Header Where INFO 621 ------ ----- ---- 622 Accept R o 623 Accept-Encoding R o 624 Accept-Encoding 2xx o 625 Accept-Encoding 415 c 626 Accept-Language R o 627 Accept-Language 2xx o 628 Accept-Language 415 c 629 Allow R o 630 Allow 200 - 631 Allow 405 o 632 Allow-Events R o 633 Allow-Events r o 634 Authentication-Info 2xx o 635 Authorization R o 636 Call-ID gc m 637 Call-Info R o 638 Call-Info r o 639 Contact R - 640 Contact 1xx - 641 Contact 2xx - 642 Contact 3xx - 643 Contact 485 - 644 Content-Disposition e o 645 Content-Encoding e o 646 Content-Language e o 647 Content-Length e o 648 Content-Type e * 649 CSeq gc m 650 Date g o 651 Error-Info 3xx-6xx o 652 Expires g - 653 From gc m 654 Geolocation R o 655 Max-Breadth R - 656 Max-Forwards R o 657 MIME-Version R o 658 MIME-Version r o 659 Organization g o 660 Privacy R o 661 Proxy-Authenticate 407 o 662 Proxy-Authorization R o 663 Proxy-Require R o 664 Reason R o 665 Record-Route R o 666 Record-Route 2xx o 667 Require R o 668 Require r o 669 Retry-After R - 670 Retry-After 404,480,486 o 671 Retry-After 503 o 672 Retry-After 600,603 o 673 Route R o 674 Security-Client R o 675 Security-Server 421,494 o 676 Security-Verify R o 677 Server r o 678 Subject R o 679 Supported R o 680 Supported 2xx o 681 Timestamp g o 682 To gc(1) m 683 Unsupported 420 o 684 User-Agent g o 685 Via gc(2) m 686 Warning r o 687 WWW-Authenticate 401 o 689 5.2. INFO Headers 691 This table expands on tables 2 and 3 in [RFC3261]. 693 Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT 694 -------------------------------------------------------------------- 695 Info-Package R - - - - - - - m - - - - 696 Recv-Info R o - - o o o o - - o - - 697 Recv-Info 2xx o - - o o - o - - o - - 698 Recv-Info 1xx o - - o o - o - - o - - 699 Recv-Info r o - - - o - o - - o - - 701 5.2.1. Info-Package header 703 This document adds Info-Package to the definition of the element 704 "message-header" in the SIP message grammar. 706 For the purposes of matching Info Package types indicated in Recv- 707 Info with those in the Info-Package header field value, one compares 708 the Info-package-name portion of the Info-package-type portion of the 709 Info-Package header octet-by-octet with that of the Recv-Info header 710 value. That is, the Info Package name is case sensitive. Info- 711 package-param is not part of the comparison-checking algorithm. 713 This document does not define values for Info-Package types. 714 Individual Info Packages define these values. Such documents MUST 715 register such values with IANA. These values are Specification 716 Required [RFC5226]. 718 5.2.2. Recv-Info header 720 This document adds Recv-Info to the definition of the element 721 "general-header" in the SIP [RFC3261] message grammar. Section 3 722 describes the Recv-Info header usage. 724 6. Legacy Uses of INFO 726 Several RFC-defined and other standards-defined uses of RFC 2976 INFO 727 [RFC2976] exist and are in use, as well as numerous proprietary uses. 728 Appendix B describes some of these usages. By definition, 729 identifying such uses has relied on either static local configuration 730 or implicit context determination based on the body Content-Type or 731 Content-Disposition value or some proprietary mechanism. This draft 732 cannot forbid nor avoid such uses, since local configuration can 733 always override standardized mechanisms. 735 To maintain backward compatibility with the extant standardized uses 736 of INFO, a server MAY interpret an INFO request with no "Info- 737 Package" header as being of such legacy use. 739 It should be noted that such legacy use will not "break" the 740 mechanism in this draft. For example, if a UA supports SIP-T 741 [RFC3372], it does so based on static local configuration or based on 742 acceptance of the application/isup body. If it adds support for this 743 draft's Info Package negotiation mechanism, the local configuration 744 still applies, and the UA will send/receive INFO messages based on 745 SIP-T regardless of the Info Package negotiation. It will also be 746 able to send/receive INFO messages based on the Info Packages it 747 negotiated. If, at some future time, an Info Package is defined for 748 SIP-T, the UA can indicate such in the negotiation, and again local 749 configuration would supersede if need be. The UA would not lose the 750 ability to use SIP-T with legacy devices. Rather, it would gain the 751 ability to use it with devices which support this draft and with 752 which it did not have such local configuration set, and could avoid 753 failures related to unsupported bodies. 755 It is the hope of this draft's authors that vendors that implement 756 proprietary INFO uses submit their mechanisms as Info Package 757 extension documents, and follow the Info Package negotiation 758 mechanism defined in this draft. 760 7. Info Package Requirements 762 Info Packages SHOULD NOT reiterate any of the behavior described in 763 this document, unless required for clarity or emphasis. However, 764 such packages MUST describe the behavior that extends or modifies the 765 behavior described in this document. 767 Info Packages MUST NOT weaken any behavior designated with "SHOULD" 768 or "MUST" in this document. However, Info Packages MAY strengthen 769 "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if 770 the application requires it. 772 In addition to the normal sections expected in standards-track RFCs 773 and SIP extension documents, authors of Info Packages need to address 774 each of the issues detailed in the following subsections, whenever 775 applicable. 777 7.1. Applicability 779 This section, which MUST be present, describes why any of the other 780 established user-to-user data transfer protocols are not appropriate 781 for the given Info Package. Common reasons can be a requirement for 782 SIP Proxies or back-to-back User Agents (B2BUAs) to see the 783 application level information. Consideration in this section MUST 784 describe what happens if one or both endpoints encrypt the payload. 786 7.2. Info Package Name 788 This section, which MUST be present, defines the token name that 789 designates the Info Package. The name MUST conform to the token- 790 nodot ABNF production described in Section 8. It MUST include the 791 information that appears in the IANA registration of the token. For 792 information on registering such types, see Section 9. 794 7.3. Info Package Parameters 796 If the "Info-Package" header allows parameters to modify the behavior 797 of the Info Package, this section MUST clearly define the syntax and 798 semantics of such parameters. 800 7.4. Info Package Tags 802 If useful for the Info Package to have SIP option tags, this is the 803 place to define the tag. Note that if the Info Package defines a SIP 804 option tag, the Info Package must conform to the SIP Change Process 805 [RFC3427]. 807 7.5. INFO Bodies 809 Each Info Package MUST define what type or types of bodies are 810 expected in INFO requests. Such packages MUST specify or cite 811 detailed specifications for the syntax and semantics associated with 812 such a body. 814 The UAS MUST enumerate every MIME type associated with the Info 815 Packages advertised in the UAS' Recv-Info header the UAS is willing 816 to receive. If a UAC sends a body that includes something not 817 enumerated by the UAS, this is a protocol error and the UAS MUST 818 respond appropriately. 820 7.6. UAC generation of INFO requests 822 Each Info Package MUST describe the process by which a UA generates 823 and sends an INFO request. This includes detailed information about 824 what events cause the UA to send an INFO request. 826 If the Info Package does not allow overlapping (outstanding) INFO 827 requests the Info Package MUST disclose this in the section 828 describing UA generation of INFO requests. Note the generic protocol 829 machinery of the INFO method has no way of enforcing such a 830 requirement. Section 7.7 describes this situation. 832 7.7. UAS processing of INFO requests 834 The Info Package MAY describe the process followed by the UA upon 835 receipt of an INFO request. Since INFO does not change SIP state, 836 and may not even change application state, there may be no useful 837 guidance required in the Info Package specification for UA 838 processing. 840 If the info Package does not permit overlapping INFO requests, it is 841 important to note the issuance of overlapping INFO requests is an 842 application-layer protocol failure and not an INFO method failure. 843 Therefore, in the event a UAC issues overlapping INFO requests for an 844 Info Package, the UAS MUST NOT return an error response. This 845 section of the Info Package specification MUST describe the 846 application level response to overlapping INFO requests. Examples 847 include a new INFO request back to the offending UAC indicating an 848 application error, ignoring the overlapping request and processing it 849 to the UAS' best effort, or terminating the entire SIP dialog. 851 7.8. Rate of INFO Requests 853 Each Info Package MUST define a requirement of MUST strength which 854 defines an absolute maximum on the rate at which an Info Package of a 855 given type can generate INFO messages by a UA in a dialog. 857 If possible, a package MUST define a throttle mechanism that allows 858 UAs to further limit the rate of INFO messages. 860 7.9. IANA Registrations 862 The Info Package MUST have an IANA Considerations section that 863 includes definitions for the Info Package Name and, if needed, 864 supported MIME types. 866 7.10. Security Considerations 868 The INFO mechanism transports application level information. One 869 implication of this is INFO messages may require a higher level of 870 protection than the underlying SIP-based session signaling. If the 871 application transports sensitive information, such as credit card 872 numbers, health history, personal identifiers, and so on, the Info 873 Package MUST document security procedures that exceed the default 874 procedures presented in this document. In most circumstances it is 875 not sufficient for a package to attempt to mandate TLS for the 876 signaling channel to secure the data carried by the INFO. This is 877 because there are few protocol mechanisms to enforce this 878 requirement. It may be possible for an Info Package to inform the 879 SIP transport layer stack to be "secure." However, the only way to 880 ensure secure transport at the application level is to have the 881 security be part of the Info Package itself. The most common method 882 of achieving this is to use end-to-end security techniques such as 883 S/MIME [RFC3851]. 885 7.11. Examples 887 We RECOMMEND Info Packages include several demonstrative message flow 888 diagrams paired with several typical, syntactically correct, and 889 complete messages. 891 Documents describing Info Packages MUST clearly indicate the examples 892 are informative and not normative, with instructions that 893 implementers refer to the main text of the document for exact 894 protocol details. 896 8. Syntax 898 This section describes the syntax extensions required for user-to- 899 user data exchange in SIP. The previous sections describe the 900 semantics. Note the formal syntax definitions described in this 901 document use the ABNF format used in SIP [RFC3261] and contain 902 references to elements defined therein. 904 The Augmented BNF definitions for the various new and modified syntax 905 elements follow. The notation is as used in SIP [RFC3261]. See SIP 906 for any elements not defined in this section. 908 INFOm = %x49.4E.46.4F ; INFO in caps 909 extension-method = INFOm / token 911 Info-Package = "Info-Package" HCOLON Info-package-type 912 Recv-Info = "Recv-Info" HCOLON "nil" 913 / Info-package-type 914 *( COMMA Info-package-type ) 915 Info-package-type = Info-package-name *( "." Info-package-param) 916 Info-package-name = token-nodot 917 Info-package-param = token-nodot 918 token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" 919 / "_" / "+" / "`" / "'" / "~" ) 921 NOTE on the Recv-Info production: if the value is "nil", there can be 922 one and only one Recv-Info header in the SIP message. 924 9. IANA Considerations 926 9.1. Update to Registration of SIP INFO Method 928 Please update the existing registration in the SIP Methods and 929 Response Codes registry under the SIP Parameters registry that 930 states: 932 Method: INFO 933 Reference: [RFC2976] 935 to: 937 Method: INFO 938 Reference: [RFCXXXX] 940 9.2. Registration of the Info-Package Header Field 942 Please add the following new SIP header field in the Header Fields 943 subregistry under the SIP Parameters registry. 945 Header Name: Info-Package 946 Compact Form: (none) 947 Reference: [RFCXXXX] 949 9.3. Registration of the Recv-Info Header Field 951 Please add the following new SIP header field in the Header Fields 952 subregistry under the SIP Parameters registry. 954 Header Name: Recv-Info 955 Compact Form: (none) 956 Reference: [RFCXXXX] 958 9.4. Creation of the Info Packages Registry 960 Please create a subregistry in the SIP Parameters registry for Info 961 Packages. This subregistry has a modified First Come First Served 962 [RFC5226] policy. 964 The following data elements populate the Info Package Registry. 965 o Info Package Name: The Info Package Name is a case-sensitive 966 token. In addition, IANA shall not register multiple Info Package 967 names that have identical case-insensitive values. 968 o Info Package Payload MIME Types: A list of zero or more registered 969 MIME types from the MIME Type Registry. 970 o Standards Status: Values are "Standards Track" or empty. See 971 below for a discussion and rules on this field. 972 o Reference: If there is a published specification describing the 973 Info Package, place a reference to that specification in this 974 column. See below for a discussion on this field. 976 If there is a published specification, the registration MUST include 977 a reference to such specification. The Standards Status field is an 978 indicator of the level of community review for the Info Package 979 specification. If the specification meets the requirements for 980 Specification Required [RFC5226], the value for the Standards Status 981 field is "Standards Track". Otherwise, the field is empty. 983 This document uses the Info Package Name "nil" to represent "no Info 984 Package present" and as such IANA shall not honor a request to 985 register the "nil" Info Package. 987 The initial population of this table shall be: 989 Name MIME Type Standards Status Reference 990 nil Standards Track [RFCXXXX] 992 9.5. Registration of the Info-Package Content-Disposition 994 Please add the following registration to the Content-Disposition 995 registry. The description suitable for the IANA registry is as 996 follows. 998 The payload of the message carrying this Content-Disposition header 999 field value is the payload of an Info Package. 1001 10. Examples 1003 10.1. Single Info Package 1005 In the following example, Alice initiates a call to Bob. Alice can 1006 support sending or receiving "foo" Info Packages, and sending "bar" 1007 Info Packages. 1009 Alice generates the following: (note: much has been left out for 1010 simplicity) 1012 INVITE sip:bob@example.com SIP/2.0 1013 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 1014 From: Alice ;tag=1234567 1015 To: Bob 1016 Call-Id: 123456mcmxcix 1017 CSeq: 1 INVITE 1018 Contact: 1019 Recv-Info: foo 1021 Bob does not support anything, so he says so. 1023 SIP/2.0 180 Ringing 1024 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 1025 From: Alice ;tag=1234567 1026 To: Bob ;tag=abcdefg 1027 Call-Id: 123456mcmxcix 1028 CSeq: 1 INVITE 1029 Recv-Info: nil 1031 Bob answers, but still does not support anything. 1033 SIP/2.0 200 OK 1034 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 1035 From: Alice ;tag=1234567 1036 To: Bob ;tag=abcdefg 1037 Call-Id: 123456mcmxcix 1038 CSeq: 1 INVITE 1039 Contact: 1040 Recv-Info: nil 1042 Alice could have sent an Info Package as soon as she received the 1043 180, but in this example she would not have been able to do so since 1044 Bob didn't say he could receive any Info Packages in his 180 1045 response. Bob, on the other hand, may send an INFO: 1047 INFO sip:alice@192.0.2.1 SIP/2.0 1048 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1049 To: Alice ;tag=1234567 1050 From: Bob ;tag=abcdefg 1051 Call-Id: 123456mcmxcix 1052 CSeq: 2 INFO 1053 Contact: 1054 Info-Package: foo 1056 10.2. Multipart INFO Example 1058 This is for where there is a single INFO payload in a multipart/mime. 1060 INFO .... 1061 To: .... 1062 From: .... 1063 Info-Package: foo 1064 Mumble: 1065 Content-Type: multipart/mixed;boundary="theboundary" 1066 ... 1068 --theboundary 1069 Content-Type: application/mumble 1070 Content-Id: abcd9999qq 1071 ... 1073 1075 --theboundary 1076 Content-Type: application/foo 1077 Content-Disposition: Info-Package 1079 1081 --theboundary-- 1083 11. Modifications to SIP Change Process 1085 [EDITOR'S NOTE: This section may become a separate document in the 1086 future.] 1087 This document updates RFC 3427 [RFC3427] to add a process for 1088 registering new Info Packages. The process for registering new Info 1089 Packages follows the process outlined in Section 4.3 of RFC 3427 for 1090 the registration of SIP Event Packages. Namely, the registration of 1091 a new SIP Info Package requires the SIPPING chairs to assign an 1092 individual to perform expert review of the proposal if the work is 1093 not a SIPPING work item in itself. 1095 12. Security Considerations 1097 By eliminating multiple uses of INFO messages without adequate 1098 community review and by eliminating the possibility for rogue SIP 1099 User Agents from confusing another User Agent by purposely sending 1100 unrelated INFO messages, we expect this document's clarification of 1101 the use of INFO to improve the security of the Internet. Whilst 1102 rogue UACs can still send unrelated INFO messages, this framework 1103 provides mechanisms for which the UAS and other security devices can 1104 filter for approved Info Packages. 1106 If the content of the Info Package payload is private, User Agents 1107 will need to use end-to-end encryption, such as S/MIME, to prevent 1108 access to the content. This is particularly important as transport 1109 of INFO is likely not to be end-to-end, but through SIP proxies and 1110 back-to-back user agents (B2BUA's), which the user may not trust. 1112 The INFO mechanism transports application level information. One 1113 implication of this is INFO messages may require a higher level of 1114 protection than the underlying SIP-based session signaling. In 1115 particular, if one does not protect the SIP signaling from 1116 eavesdropping or authentication and repudiation attacks, for example 1117 by using TLS transport, then the INFO request and its contents will 1118 be vulnerable, as well. Even with SIP/TLS, any SIP hop along the 1119 path from UAC to UAS can view, modify, or intercept INFO requests, as 1120 they can with any SIP request. This means some applications may 1121 require end-to-end encryption of the INFO payload, beyond, for 1122 example, hop-by-hop protection of the SIP signaling itself. Since 1123 the application dictates the level of security required, individual 1124 Info Packages have to enumerate these requirements. In any event, 1125 the INFO Framework described by this document provides the tools for 1126 such secure, end-to-end transport of application data. 1128 One interesting property of Info Package use is one can reuse the 1129 same digest-challenge mechanism used for INVITE-based authentication 1130 for the INFO request. For example one could use a quality-of- 1131 protection (qop) value of authentication with integrity (auth-int), 1132 to challenge the request and its body, and prevent intermediate 1133 devices from modifying the body. However this assumes the device 1134 which knows the credentials in order to perform the INVITE challenge 1135 is still in the path for the INFO, or that the far-end UAS knows such 1136 credentials. 1138 13. References 1139 13.1. Normative References 1141 [I-D.ietf-sip-body-handling] 1142 Camarillo, G., "Message Body Handling in the Session 1143 Initiation Protocol (SIP)", 1144 draft-ietf-sip-body-handling-05 (work in progress), 1145 October 2008. 1147 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1148 Requirement Levels", RFC 2119, BCP 14, March 1997. 1150 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1151 A., Peterson, J., Sparks, R., Handley, M., and E. 1152 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1153 June 2002. 1155 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1156 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1157 May 2008. 1159 13.2. Informative References 1161 [I-D.ietf-speechsc-mrcpv2] 1162 Shanmugham, S. and D. Burnett, "Media Resource Control 1163 Protocol Version 2 (MRCPv2)", 1164 draft-ietf-speechsc-mrcpv2-17 (work in progress), 1165 November 2008. 1167 [I-D.saleem-msml] 1168 Saleem, A., "Media Server Markup Language (MSML)", 1169 draft-saleem-msml-07 (work in progress), August 2008. 1171 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1172 August 1980. 1174 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1175 RFC 793, September 1981. 1177 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1178 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1179 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1181 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1182 October 2000. 1184 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 1185 RFC 3080, March 2001. 1187 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1188 Event Notification", RFC 3265, June 2002. 1190 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1191 UPDATE Method", RFC 3311, October 2002. 1193 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 1194 for Telephones (SIP-T): Context and Architectures", 1195 BCP 63, RFC 3372, September 2002. 1197 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 1198 and B. Rosen, "Change Process for the Session Initiation 1199 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 1201 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1202 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1203 for Instant Messaging", RFC 3428, December 2002. 1205 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1206 Context for Internet Mail", RFC 3458, January 2003. 1208 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1209 Camarillo, "Best Current Practices for Third Party Call 1210 Control (3pcc) in the Session Initiation Protocol (SIP)", 1211 BCP 85, RFC 3725, April 2004. 1213 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1214 Preferences for the Session Initiation Protocol (SIP)", 1215 RFC 3841, August 2004. 1217 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1218 Extensions (S/MIME) Version 3.1 Message Specification", 1219 RFC 3851, July 2004. 1221 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 1222 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 1224 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1225 the Session Description Protocol (SDP)", RFC 4145, 1226 September 2005. 1228 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1229 Media Services with SIP", RFC 4240, December 2005. 1231 [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, 1232 "Interworking between the Session Initiation Protocol 1233 (SIP) and QSIG", BCP 117, RFC 4497, May 2006. 1235 [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol 1236 (SIP) Event Package for Key Press Stimulus (KPML)", 1237 RFC 4730, November 2006. 1239 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1240 RFC 4949, August 2007. 1242 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1243 RFC 4960, September 2007. 1245 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1246 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1248 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1249 Control Markup Language (MSCML) and Protocol", RFC 5022, 1250 September 2007. 1252 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 1253 Initiation Protocol", RFC 5057, November 2007. 1255 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1256 Media Control", RFC 5168, March 2008. 1258 [W3C.REC-voicexml21-20070619] 1259 Porter, B., McGlashan, S., Lee, A., Burnett, D., Carter, 1260 J., Oshry, M., Bodell, M., Baggia, P., Rehor, K., Burke, 1261 D., Candell, E., and R. Auburn, "Voice Extensible Markup 1262 Language (VoiceXML) 2.1", World Wide Web Consortium 1263 Recommendation REC-voicexml21-20070619, June 2007, 1264 . 1266 Appendix A. Info Package Considerations 1268 This section covers several issues that one should take into 1269 consideration when proposing new Info Packages. 1271 A.1. Appropriateness of Usage 1273 When designing an Info Package using the method described in this 1274 document for application level information exchange, it is important 1275 to consider: is INFO and, more importantly, is signaling within a SIP 1276 dialog, an appropriate mechanism for the problem set? Is it because 1277 it is the most reasonable and appropriate choice, or merely because 1278 "it's easy"? 1280 These are difficult issues to consider, especially when presented 1281 with real-world deadlines and implementation cost issues. However, 1282 choosing to use INFO for inappropriate uses *will* lead to issues in 1283 the real world, not the least of which are certain types of 1284 middleboxes which will remove the device from the network if it is 1285 found to cause damage to other SIP nodes. 1287 Therefore, the following sections provide consideration guidelines 1288 and alternatives to INFO use. 1290 A.2. Dialog Fate-Sharing 1292 INFO, by design, is a method within an INVITE dialog usage. RFC 5057 1293 [RFC5057] enumerates the problems with using dialogs for multiple 1294 usages, and we strongly urge the reader to review RFC 5057. The most 1295 relevant issue is a failure of transmission or processing of an INFO 1296 request may render the INVITE dialog terminated, depending on the 1297 type of failure. Prior to RFC 5057 it was not clear if the INFO 1298 usage was a separate usage or not. RFC 5057 clarifies the INFO 1299 method is always part of the INVITE usage. 1301 Some uses of INFO can tolerate this fate sharing of the INFO message 1302 over the entire dialog. For example, in the SIP-T usage, it may be 1303 acceptable for a call to fail, or to tear down the call, if one 1304 cannot deliver the associated SS7 information. The same is usually 1305 true for DTMF. However, it may not be acceptable for a call to fail 1306 if, for example, a DTMF buffer overflows. Then again, for some 1307 services, that may be the exact desired behavior. 1309 A.3. Messaging Rates and Volume 1311 There is no throttling mechanism for INFO. Consider that most call 1312 signaling occurs on the order of 7-10 messages per 3 minutes, 1313 although with a burst of 5-7 messages in one second during call 1314 setup. DTMF tones occur in bursts at a rate of up to 20 messages per 1315 second. This is a considerably higher rate than for call signaling. 1316 Sending constant GPS location updates, on the other hand, would incur 1317 an undue burden on SIP Proxies along the path. 1319 Furthermore, SIP messages tend to be relatively small, on the order 1320 of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct 1321 exchange of bulk data beyond these limits, especially if the headers 1322 plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for 1323 such traffic include MSRP [RFC4975], COMEDIA [RFC4145], or HTTP 1324 [RFC2616]. 1326 A.4. Is there a better alternative? 1328 The first alternative for application level interaction is SIP 1329 Events, also known as SUBSCRIBE/NOTIFY [RFC3265]. In this model, a 1330 user agent requests state information, such as key pad presses from a 1331 device to an application server or key map images from an application 1332 server to a device. The SUBSCRIBE creates a new dialog that does not 1333 share the fate of the related INVITE-initiated dialog. Moreover, 1334 using the SUBSCRIBE model enables multiple applications to receive 1335 state updates. These applications can be outside the media path and 1336 potentially outside the INVITE-initiated dialog's proxy path. In 1337 fact, SIUBSCRIBE/NOTIFY is your only option if you need to exchange 1338 data outside a communications session. 1340 SUBSCRIBE/NOTIFY messages pass through the SIP signaling 1341 infrastructure, such as SIP Proxies and B2BUAs. Application 1342 designers need to understand this can be a feature, as when the User 1343 Agents are exchanging information that elements in the SIP signaling 1344 path need to be aware of. Conversely, this can be a problem, as 1345 messages these network elements have no interest in can put a 1346 significant burden on those element's ability to process other 1347 traffic. Moreover, such network elements may not be able to read 1348 end-to-end encrypted SUBSCRIBE or NOTIFY bodies. 1350 Implementers do need to be aware the price of having a protocol that 1351 works in all cases, can scale, can easily load balance, and will not 1352 mysteriously fail a session in the event of state synchronization 1353 failure does come at a cost. Session establishment is a minimum of 1354 two messages in addition to the INVITE dialog establishment. If the 1355 SUBSCRIBE application is co-resident with the INVITE application, the 1356 application will have to manage two SIP dialogs instead of one. 1357 Tracking the application level state dominates memory and processing 1358 for some applications, and as such the doubling of SIP dialogs is not 1359 an issue. However, for other applications, this may be an issue. 1361 The MESSAGE method [RFC3428] defines one-time instant message 1362 exchange, typically for sending MIME contents for rendering to the 1363 user. 1365 Another model for application level information exchange is to 1366 establish a communication channel in the media plane. One model for 1367 this is MRCPv2 [I-D.ietf-speechsc-mrcpv2]. Here, the INVITE- 1368 initiated dialog establishes a separate reliable, connection-oriented 1369 channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream. One uses 1370 SIP to locate the remote endpoint, but uses a direct connection for 1371 the UUI. One then can create whatever protocol one wishes, whether 1372 from scratch (as in MRCPv2) or using a substrate such as BEEP 1373 [RFC3080]. 1375 A low latency requirement for the exchange of information is one 1376 strong indicator for using a media channel. Exchanging information 1377 through the SIP routing network can introduce hundreds of 1378 milliseconds of latency. Also, if there will be a lot of information 1379 exchanged, and there is no need for the SIP routing network to 1380 examine the information, one should use a separate media channel. 1382 Another model is to use a totally externally signaled channel, such 1383 as HTTP [RFC2616]. In this model, the user agent knows about a 1384 rendezvous point to direct HTTP requests to for the transfer of 1385 information. Examples include encoding of a prompt to retrieve in 1386 the SIP Request URI in RFC 4240 [RFC4240] or the encoding of a SUBMIT 1387 target in a VoiceXML [W3C.REC-voicexml21-20070619] script. 1389 MSRP [RFC4975] defines session-based instant messaging as well as 1390 bulk file transfer and other such large-volume uses. It is part of 1391 an INVITE-based session, similar to other media. Unlike INFO, MSRP 1392 follows a direct media path, rather than through the network elements 1393 composing the SIP signaling path. 1395 A common reason people in the past used INFO for application level 1396 information exchange is the negotiation is very lightweight compared 1397 to SUBSCRIBE/NOTIFY. This is more especially so if it is not certain 1398 if there will be application level information exchange. The 1399 SUBSCRIBE/NOTIFY machinery requires the user agents to exchange rich 1400 capabilities and maintain state for additional SIP dialogs. However, 1401 this is a weak argument if there is a high likelihood of application 1402 level information exchange. In this case, we recommend the use of a 1403 more robust application level information exchange protocol. 1405 A.5. Alternatives for Common INFO Use 1407 What alternatives to INFO are there for UA-to-UA application session 1408 signaling? As noted above, there are three broad classes of session 1409 signaling available. The choice depends on the circumstances. 1410 Following is a list of situations that have used INFO in the past. 1411 o State updates 1412 o User stimulus 1413 o Direct signaling channel 1414 o Proxy-aware signaling 1415 o Dialog probe 1417 A.5.1. State Updates 1419 This is the broad class of one User Agent updating another with 1420 changes in state. The design goal of the SUBSCRIBE/NOTIFY [RFC3265] 1421 event framework is to meet just this need. 1423 A.5.2. User Stimulus: Touch Tones and Others 1425 This is the class of the user entering stimulus at one User Agent, 1426 and the User Agent transporting that stimulus to the other. A key 1427 thing to realize is key presses on the telephone keypad is user 1428 stimulus. Thus, the appropriate mechanism to use here is KPML 1429 [RFC4730]. 1431 A.5.3. Direct Signaling Channel 1433 State updates and user stimulus tend to have relatively few messages 1434 per session. Sometimes, User Agents need to exchange a relatively 1435 high number of messages. In addition, User Agents may have a need 1436 for a relatively low-latency exchange of messages. In this latter 1437 case, the User Agent may not be able to tolerate the latency 1438 introduced by intermediate proxies. Likewise, the intermediate 1439 proxies may have no interest in processing all of that data. 1441 In this case, establishing a separate, direct control channel, as in 1442 MSRP [RFC4975] or MRCPv2 [I-D.ietf-speechsc-mrcpv2] is appropriate. 1444 In addition, not every situation requires a SIP solution. Some 1445 signaling is really just one-shot to third-party endpoints. That 1446 situation may better be handled using an appropriate protocol, such 1447 as HTTP [RFC2616]. 1449 A.5.4. Proxy-Aware Signaling 1451 Sometimes, one does want proxies to be in the signaling path for UA- 1452 to-UA application signaling. In this case, the use of a SIP request 1453 is appropriate. To date, there are no mechanisms for completely 1454 disambiguating INFO requests. For example, one could create a 1455 registry of INFO packages. The definition of the package would 1456 define the contexts for the various MIME Content-Types, as well as 1457 the context of the request itself. However, a package can have 1458 multiple content types. Moreover, having the context, or package 1459 identifier, at the SIP level precludes bundling multiple contexts 1460 responding in the same INFO request. For example, a User Agent might 1461 want to bundle two different responses in a multipart/mixed MIME body 1462 type. 1464 Because there is no difference in either the protocol machinery or 1465 registration process due to these factors, we will not create an INFO 1466 framework. If one needs a SIP User Agent-to-SIP User Agent 1467 application session signaling transport protocol that touches all 1468 Record-Route proxies in a path, one MUST create a new SIP method as 1469 described in Section 27.4 of RFC 3261 [RFC3261]. 1471 A.5.5. Dialog Probe 1473 Some implementations in the wild use INFO to probe if an INVITE- 1474 initiated dialog is alive. While this works, it is NOT RECOMMENDED. 1475 In particular, RFC 4028 [RFC4028] describes how to ensure an INVITE- 1476 initiated dialog is alive. 1478 A.5.6. Malicious Indicator 1480 Take the case of Malicious Indicator. This is where a subscriber 1481 receives a call, realizes it is a malicious call (threatening, SPIT, 1482 etc.). They then press the SPIT button (or press *xx), which tells 1483 their service provider to mark the UAC as a bad actor. One might be 1484 tempted to think that INFO would be a great option for this service. 1485 It follows the return path of the INVITE, and so the INFO will hit 1486 the caller's inbound proxy, which it can learn the caller is 1487 (statistically) a bad actor. That way the inbound proxy can do stuff 1488 like notify law enforcement, add a vote to "this is a SPIT source," 1489 or other useful action. 1491 However, consider a few issues. First, since INFO lives exclusively 1492 within an established dialog, there is no way to assert this message 1493 after the call completes. Second, this mechanism relies on an active 1494 service provider topology. If there is no proxy in the chain that 1495 will eat the INFO, the caller will see the "this is a bad guy" 1496 message, which may have consequences in the real world. Third, there 1497 is no a'priori way for the UAS to know whether or not it can issue 1498 the INFO. The caller certainly will not advertise, "please tell me 1499 if I am bad, particularly I know in advance that I *am* a bad actor." 1501 One approach is for the service provider's proxy to SUBSCRIBE for the 1502 SPIT event at the UAS. At this point, life is good, interoperable, 1503 and works across networks. This enables events after the dialog is 1504 torn down, as presumably the SPIT event will refer not to, "this 1505 dialog," which does not exist, but to "that dialog identifier," which 1506 exists (and is theoretically unique) forever. 1508 Another approach that saves considerably on the overhead of 1509 subscriptions would be for the service provider to insert a HTTP URI 1510 in the initial INVITE, noting it is for reporting malicious behavior. 1511 When the subscriber presses the SPIT button, an HTTP POST gets 1512 executed, delivering the call information to the service provider. 1513 The service provider can encode basic call information in the HTTP 1514 URI and can instruct the device to send whatever arbitrary data is 1515 necessary in the POST. This method has the added benefit of being 1516 entirely outside the real-time SIP proxy network. 1518 Appendix B. Legacy INFO Usages 1520 We do not intend this section to be a comprehensive catalog of INFO 1521 usages. However, it should give the reader a flavor for current INFO 1522 usages. 1524 B.1. ISUP 1526 SIP-T uses Content-Type to identify ISUP protocol elements in an INFO 1527 message. See RFC3372 [RFC3372]. 1529 B.2. QSIG 1531 QSIG uses Content-Type to identify QSIG protocol elements in an INFO 1532 message. See RFC4497 [RFC4497]. 1534 B.3. MSCML 1536 MSCML uses a Require to ensure the UAS understands that INFO messages 1537 of the MSCML type are in fact MSCML messages. See RFC5022 [RFC5022]. 1539 B.4. MSML 1541 MSML endpoints just know the INFO messages carry MSML and from the 1542 Content-Type of the given INFO method request. See the MSML 1543 [I-D.saleem-msml] draft. 1545 B.5. Video Fast Update 1547 Microsoft, Polycom, and Radvision used INFO messages as an interim 1548 solution for requesting fast video update before the ability to 1549 request I-Frames in RTCP was available. See the XML Schema for Media 1550 Control [RFC5168] for more information. 1552 B.6. DTMF 1554 [EDITOR'S NOTE: Are there public references? The AS5300 1555 documentation from Cisco describes Cisco's use of INFO to carry DTMF. 1556 Anyone else want to belly up to the bar and have us collect your 1557 proprietary DTMF INFO payload here?] 1559 Appendix C. Acknowledgements 1561 We are standing on the shoulders of giants. Jonathan Rosenberg did 1562 the original "INFO Considered Harmful" Internet Draft on 26 December 1563 2002, which influenced the work group and this document. Likewise, 1564 Dean Willis influenced the text from his Internet Draft, "Packaging 1565 and Negotiation of INFO Methods for the Session Initiation Protocol" 1566 of 15 January 2003. Four paragraphs come from Jonathan Rosenberg's 1567 INFO Litmus draft. My, we have been working on this for a long time! 1569 This and other related drafts have elicited well over 450 messages on 1570 the SIP list. People who have argued with its thesis, supported its 1571 thesis, added to the examples, or argued with the examples, include 1572 the following individuals: 1573 Adam Roach, Bram Verburg, Brian Stucker, Chris Boulton, Cullen 1574 Jennings, Dale Worley, Dean Willis, Frank Miller, Gonzalo 1575 Camarillo, Gordon Beith, Henry Sinnreich, James Jackson, James 1576 Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan 1577 Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, 1578 Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul 1579 Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, 1580 Robert Sparks, Roland Jesske, Salvatore Loreto, Sam Ganesan, 1581 Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg, and 1582 Xavier Marjou. 1584 John Elwell and Francois Audet helped with QSIG references. In 1585 addition, Francois Audet provided actual text for the revised 1586 abstract. Keith Drage gave lots of excellent comments and helped 1587 immensely with Figure 1. 1589 The work group version of this document benefited from the close 1590 readings and comments from 1591 John Elwell, Paul Kyzivat, Dean Willis, Francois Audet, Dale 1592 Worley, Andrew Allen, Adam Roach, Anders Kristensen, Gordon Beith, 1593 Ben Campbell, Bob Penfield, Keith Drage, Jeroen van Bemmel, Mary 1594 Barnes, and Salvatore Loreto. 1596 Since publication of the first work group version of this document, 1597 we have had over 329 messages. New voices in addition to those 1598 included above include 1599 Arun Arunachalam, Christian Stredicke, Eric Rescorla, Inaki Baz 1600 Castillo, and Roni Evan. 1602 However, any errors and issues we missed are still our own. 1604 Appendix D. Change Log 1606 [RFC EDITOR NOTE: Please remove this section when publishing] 1608 Changes from -02 1609 o Applicability statement explicitly says we're backwards compatible 1610 o Explicitly state we work like UPDATE (both early and confirmed 1611 dialogs) 1612 o Agreed text for IANA Considerations package registry 1614 Changes from -01 1615 o One and only one Info Package per INFO 1616 o Removed Send-Info header, greatly simplifying negotiation 1617 o Multiple body part identification through Content-Disposition: 1618 Info-Package 1619 o Note that forking INVITEs may result in multiple INFO's coming 1620 back to INVITE originator 1621 o Describe how a UAS can enforce strict adherence to this document 1622 o Remove CANCEL INFO faux pas 1623 o Better explained overlapping INFO issues and resolutions 1624 o Token names are now really case sensitive 1625 o Moved Info Package Considerations to an Appendix 1626 o Introduced stronger, yet more open, IANA registration process 1627 o Took a few more paragraphs from INFO Litmus to cover all bases. 1628 o Added RFC 5168 to legacy usages 1630 Changes from -00 1631 o Corrected ABNF. 1632 o Enabled sending of legacy INFO messages. Receiving legacy INFO 1633 messages was already here. 1634 o Negotiation is not Offer/Answer, it is Offer/Offer. 1635 o Created the explicit "nil" Info Package to indicate no info 1636 package. 1637 o Fixed CANCEL impacting future transactions. 1638 o Added Registrar behavior. 1639 o Added OPTIONS processing. 1640 o Clarified overlapping INFO method processing. 1641 o Described multiple INFO bodies in a single INFO method. 1642 o Took out Info-Package as a header for responses to the INFO 1643 method. 1644 o Expanded on risks of using INFO and filled-in more on the 1645 alternatives 1646 o Moved definitions of INFO into the body of the text and cleaned up 1647 IANA Considerations section 1648 o Added legacy usages descriptions 1650 Authors' Addresses 1652 Eric W. Burger 1653 This Space For Sale 1654 USA 1656 Email: eburger@standardstrack.com 1657 URI: http://www.standardstrack.com 1659 Hadriel Kaplan 1660 Acme Packet 1661 71 Third Ave. 1662 Burlington, MA 01803 1663 USA 1665 Phone: 1666 Fax: 1667 Email: hkaplan@acmepacket.com 1668 URI: 1670 Christer Holmberg 1671 Ericsson 1672 Hirsalantie 11 1673 Jorvas, 02420 1674 Finland 1676 Phone: 1677 Fax: 1678 Email: christer.holmberg@ericsson.com 1679 URI: