idnits 2.17.1 draft-ietf-sipcore-info-events-01.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 'Intended status' indicated for this document; assuming Proposed Standard 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 557 has weird spacing: '...3xx-6xx o...' == Line 606 has weird spacing: '... 2xx o ...' == Line 607 has weird spacing: '... 1xx o ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 29, 2009) is 5323 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 921, but not defined == Unused Reference: 'RFC3080' is defined on line 1081, but no explicit reference was found in the text == Unused Reference: 'RFC3725' is defined on line 1088, but no explicit reference was found in the text == Unused Reference: 'RFC3841' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'RFC4145' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: 'RFC4730' is defined on line 1125, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- 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 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == 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 Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 9 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 Expires: April 2, 2010 C. Holmberg 7 Ericsson 8 September 29, 2009 10 Session Initiation Protocol (SIP) INFO Method and Package Framework 11 draft-ietf-sipcore-info-events-01 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 April 2, 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, indicating support of, and exchanging Info 53 Packages that use the INFO method. Applications that need to 54 exchange application information within a SIP invite usage dialog 55 (RFC 5057), can use these Info Packages. This document replaces RFC 56 2976 but still allows existing legacy INFO usages as defined in RFC 57 2976. 59 Conventions Used in this Document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 64 The terminology in this document conforms to the Internet Security 65 Glossary [RFC4949]. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Info Package Support . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 7 74 3.3. Package Versioning . . . . . . . . . . . . . . . . . . . . 8 75 3.4. REGISTER Processing . . . . . . . . . . . . . . . . . . . 8 76 3.5. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . 8 77 3.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . . 10 81 4.3. INFO Request Message Body . . . . . . . . . . . . . . . . 11 82 4.4. INFO Response . . . . . . . . . . . . . . . . . . . . . . 12 83 4.5. INFO Response Message Body . . . . . . . . . . . . . . . . 12 84 4.6. Order of Delivery . . . . . . . . . . . . . . . . . . . . 12 85 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13 86 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13 87 5.2. INFO Header Fields . . . . . . . . . . . . . . . . . . . . 14 88 5.2.1. Info-Package header field . . . . . . . . . . . . . . 15 89 5.2.2. Recv-Info header field . . . . . . . . . . . . . . . . 15 90 6. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 15 91 7. Info Package Requirements . . . . . . . . . . . . . . . . . . 16 92 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 7.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 16 94 7.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 17 95 7.4. Info Package Parameters . . . . . . . . . . . . . . . . . 17 96 7.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 17 97 7.6. INFO Message Bodies . . . . . . . . . . . . . . . . . . . 17 98 7.7. Info Package Usage Restrictions . . . . . . . . . . . . . 17 99 7.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 18 100 7.9. IANA Registrations . . . . . . . . . . . . . . . . . . . . 18 101 7.10. Security Considerations . . . . . . . . . . . . . . . . . 18 102 7.11. Application Procedures . . . . . . . . . . . . . . . . . . 19 103 7.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 108 9.1. Update to Registration of SIP INFO Method . . . . . . . . 20 109 9.2. Registration of the Info-Package Header Field . . . . . . 20 110 9.3. Registration of the Recv-Info Header Field . . . . . . . . 20 111 9.4. Creation of the Info Packages Registry . . . . . . . . . . 20 112 9.5. Registration of the Info-Package Content-Disposition . . . 21 113 9.6. SIP Response Code 469 Registration . . . . . . . . . . . . 21 114 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 115 10.1. Simple Info Package . . . . . . . . . . . . . . . . . . . 21 116 10.2. Multipart INFO Example . . . . . . . . . . . . . . . . . . 22 117 11. Modifications to SIP Change Process . . . . . . . . . . . . . 23 118 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 119 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 120 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 121 Appendix A. Info Package Considerations . . . . . . . . . . . . . 27 122 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 27 123 A.2. Appropriateness of Info Package Usage . . . . . . . . . . 27 124 A.3. Dialog Fate Sharing . . . . . . . . . . . . . . . . . . . 27 125 A.4. INFO Request Rate and Volume . . . . . . . . . . . . . . . 27 126 A.5. Alternative Mechanisms . . . . . . . . . . . . . . . . . . 28 127 A.5.1. Alternative SIP signaling plane mechanisms . . . . . . 28 128 A.5.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 29 129 A.5.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 29 130 Appendix B. Legacy INFO Usages . . . . . . . . . . . . . . . . . 29 131 B.1. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 132 B.2. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 133 B.3. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 30 134 B.4. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 135 B.5. Video Fast Update . . . . . . . . . . . . . . . . . . . . 30 136 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 30 137 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 31 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 140 1. Introduction 142 [RFC3261] defines a mechanism to setup and tear down SIP sessions. A 143 SIP User Agent (UA) can use the re-INVITE and UPDATE methods during a 144 session to change characteristics of the session, including media 145 properties, target information or properties related to the SIP 146 session timer mechanism [RFC4028]. 148 The purpose of the INFO message [RFC2976] is to carry application 149 level information between endpoints, using the SIP session signaling 150 path. Note that the INFO method is not used to update 151 characteristics of the SIP session, but to allow the applications 152 which use the SIP session to exchange information. 154 While the INFO method has been widely adopted for specific 155 application use cases, such as ISUP and DTMF exchange, [RFC2976] does 156 not define a mechanisms for SIP UAs to indicate what usages of INFO 157 they support. In addition, [RFC2976] does not provide a mechanism to 158 explicitly indicate the type of application for which the INFO 159 message is used. In some cases it can be determined by the INFO 160 message body content, but not in a general way. 162 Example: If the Content-Type is "image/jpeg", the MIME-attached 163 content is a JPEG image. Still, there are many useful ways a UA can 164 render an image. The image could be a caller-id picture, a contact 165 icon, a photo for sharing, and so on. The sender does not know which 166 image to send to the receiver if the receiver supports an image 167 content type. Likewise, the receiver does not know the context of an 168 image the client is sending if the receiver supports receiving more 169 than one image content type. 171 Due to the problems described above, the usage of INFO often requires 172 static configuration about what INFO usages the UAs support, and the 173 way the handle application information transported in INFO messages. 174 That has caused a big risk interoperability problems in the industry, 175 due to undefined content syntax, semantics and UA support of the INFO 176 messages. Therefore, there is a need for a well defined and 177 documented description of what the information sent in the INFO is 178 used for. This situation is identical to the context issue in 179 Internet Mail [RFC3458]. 181 This document defines a mechanism, using Info Packages, which 182 provides the possibility for UAs to indicate what INFO usages they 183 support, and to define content syntax and semantics for the data 184 transported in the INFO messages. The mechanism allows existing 185 legacy INFO usages as defined in RFC 2976. New INFO usages MUST use 186 the mechanism defined in this document. 188 Event Packages [RFC3265] perform the role of disambiguating the 189 context of a message for subscription-based events. The Info Package 190 mechanisms provides similar functionality for application information 191 exchange using invite dialog usages [RFC5057]. 193 Note that while Info Packages may be similar to subscription-based 194 events, there is no formal relationship between this mechanism and 195 the subscription mechanism. 197 The Info Package mechanism does not create a separate dialog usage. 198 INFO messages are always part of, and share the fate of, an invite 199 dialog usage. INFO message can not be sent as part of other dialog 200 usages, and they can not be sent outside an existing session. 202 If a UA supports the Info Package mechanism it indicates, using the 203 Recv-Info header field which Info Packages it is willing to receive, 204 on a per-session basis. A UA can indicate a new set of Info Packages 205 at any time during the lifetime of the invite dialog usage of the 206 session. A UA can use a "nil" value to indicate that it is not 207 willing to receive any Info Packages at a certain moment, but that 208 the UA still supports the Info Package mechanism. 210 When a UA sends an INFO request, it uses the Info-Package header 211 field to indicate which Info Package is associated with the request. 213 Section 3 describes the mechanism to indicate support of Info 214 Packages. 216 Section 4 describes the usage of INFO messages. 218 Section 6 describes legacy usage of INFO, as defined in [RFC2976]. 220 Section 7 describes guidelines on how to define Info Packages. This 221 document does not define any specific Info Packages. 223 Annex A provides guidelines and issues to consider when deciding if 224 usage of Info Packages is the most appropriate mechanism for a 225 specific use-case. 227 2. Applicability 229 This document extends [RFC2976] to include a mechanism to in SIP 230 messages explicitly indicate the supported Info Packages, and to 231 explicitly indicate what Info Package is associated with an INFO 232 request. The mechanism is backward compatible with legacy usage of 233 INFO, as defined in [RFC2976], and allows such usage. New INFO 234 usages MUST use the mechanism defined in this document. 236 3. Info Package Support 238 3.1. General 240 This section describes how SIP UAs indicate which Info Packages they 241 are willing to receive. 243 3.2. User Agent Behavior 245 A UA which supports the Info Package mechanism MUST indicate the set 246 of Info Packages it is willing to receive, using the Revc-Info header 247 field. A UA can list multiple Info Packages in a single Recv-Info 248 header field, and the UA can use multiple Recv-Info header fields. 250 The indication of Info Packages can take place during the session 251 establishment, and during a target refresh. This includes INVITE, 252 UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx 253 only). Note that the UAC is not required to indicate its set of Info 254 Packages in the initial INVITE request. 256 Once a UA has indicated that it is willing to to receive a specific 257 Info Package, and a dialog has been established, the UA MUST be 258 prepared to receive INFO request associated with that Info Package. 260 A UA MUST NOT send INFO request associated with Info Packages until 261 it has received an indication of which Info Packages the remote UA is 262 willing to receive. 264 If a UA indicates that it is willing to receive of multiple Info 265 Packages, which provide similar functionality, it is not possible to 266 indicate that the UA wishes to receive only one of them. It is up to 267 the application logic associated with the Info Packages, and specific 268 Info Package descriptions to describe application behavior in such 269 cases. 271 If a UA is not willing to receive any Info Packages, during session 272 establishment or later during the session, the UA MUST indicate this 273 by including a Recv-Info header field with a header value of 'nil'. 274 This enables other UAs to detect that the UA still supports the Info 275 Package mechanism. 277 Example: If a UA has previously indicated support of Info Packages 278 foo and bar, and the UA during the session wants to indicate that it 279 does not want to receive any Info Packages anymore, the UA sends a 280 target refresh request with a Recv-Info header field with a header 281 value of 'nil'. 283 For backward compatibility purpose, even if a UA indicates support 284 the Info Package mechanism, it is still allowed to enable legacy 285 usages of INFO. 287 This document does not define a SIP option tag [RFC3261] for the Info 288 Package mechanism. However, Info Package specifications MAY define 289 option-tags associated with the specific Info Package, as described 290 in Section 7.5. 292 Note that, for backward compatibility purpose, if a UA indicates 293 support of the INFO method, it does not implicitly indicate support 294 of the Info Package mechanism. A UA MUST use the Recv-Info header 295 field to indicate support of the Info Package mechanism. Likewise, 296 even if a UA uses the Recv-Info header field to indicate that it 297 support the Info Package mechanism, in addition the UA MUST still 298 also explicitly indicate support of the INFO method. 300 3.3. Package Versioning 302 The Info Package mechanism does not support package versioning. 303 Specific Info Package payloads MAY contain version information, which 304 is handled by the applications associated wit the Info Package, but 305 that is outside the scope of the Info Package framework. 307 Note: Even if an Info Package name contains version numbering (e.g. 308 foo_v2), the Info Package mechanism does not distinguish a version 309 number from the rest of the Info Package name. 311 3.4. REGISTER Processing 313 When a UA registers, it SHALL include Recv-Info header field in the 314 REGISTER request, and list the Info Packages that it supports. The 315 registrar MAY later use the information e.g. for forking decisions. 317 3.5. OPTIONS Processing 319 If a UA sends an OPTIONS request, or a response, the UA SHALL include 320 Recv-Info header field in the message, and list the Info Packages 321 that it supports. 323 A UA MUST NOT send INFO requests with Info Packages based on the 324 information the UA received in an OPTIONS request. The Info Packages 325 MUST be negotiated for each session. 327 3.6. Example 329 The UAC sends an INVITE request, where the UAC indicates that it is 330 willing to receive Info Packages P and R. 332 INVITE sip:bob@example.com SIP/2.0 333 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 334 Max-Forwards: 70 335 To: Bob 336 From: Alice ;tag=1928301774 337 Call-ID: a84b4c76e66710@pc33.example.com 338 CSeq: 314159 INVITE 339 Recv-Info: P, R 340 Contact: 341 Content-Type: application/sdp 342 Content-Length: ... 344 ... 346 The UAS sends a 200 OK response back to the UAC, where the UAS 347 indicates that it is willing to receive Info Packages R and T. 348 SIP/2.0 200 OK 349 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 350 To: Bob ;tag=a6c85cf 351 From: Alice ;tag=1928301774 352 Call-ID: a84b4c76e66710@pc33.example.com 353 CSeq: 314159 INVITE 354 Contact: 355 Recv-Info: R, T 356 Content-Type: application/sdp 357 Content-Length: ... 359 ... 361 Since the UAS does not support Info Package P, the UAC decides to 362 indicate in the ACK request that it is only willing to receive Info 363 Package R, which the UAS also indicated support of. 365 ACK sip:ngw1@a.example.com SIP/2.0 366 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 367 To: Bob ;tag=a6c85cf 368 From: Alice ;tag=1928301774 369 Call-ID: a84b4c76e66710@pc33.example.com 370 CSeq: 314163 ACK 371 Recv-Info: R 372 Content-Length: 0 374 4. The INFO Method 375 4.1. General 377 This section describes how the UA handling of INFO requests and 378 responses, and message bodies carried in INFO messages. It also 379 describes how an UA can indicate support of Info Packages in OPTIONS 380 requests and during registration. 382 The INFO method provides additional, application level information 383 that can further enhance a SIP application. Annex A gives more 384 details on the types of application for which the usage of INFO is 385 seen as appropriate. 387 The rules and procedures in this Section apply to implementations and 388 applications which support this. Existing implementations of, and 389 applications using, [RFC2976], may not follow the rules in this 390 Section. Because of backward compatibility purpose such cases MUST 391 NOT be regarded as error behavior, or wrong protocol usage, but 392 simply part of legacy INFO usage. 394 4.2. INFO Request 396 A UA MUST include a Info-Package header field, which indicates the 397 Info Package contained in the request, when it sends an INFO request 398 carrying an Info Package. An INFO request can contain only a single 399 Info Package. A UA MUST NOT send INFO requests associated with Info 400 Packages for which the remote entity has not indicated willingness 401 (using the Recv-Info header filed) to receive for the session. 403 A UA MAY send an INFO in a legacy usage context. In such case there 404 is no Info Package associated with the usage, and the INFO request 405 does not contain an Info-Package header field. In addition, the 406 support of the legacy usage has not been negotiated using the Recv- 407 Info header field. See Appendix B for examples of legacy usages. 409 The INFO method MUST NOT be used outside an INVITE dialog usage. The 410 INFO method has no lifetime or usage of its own. Supported Info 411 Packages are negotiated on a per session basis, and the negotiation 412 result MUST NOT be used for other sessions. If a UA receives an INFO 413 request outside an existing dialog, the UA MUST response with a 481 414 Call Does Not Exist error response. 416 Due to the possibility of forking, a UAC which during the early 417 dialog phase indicates support of one or more Info Packages (using 418 the Recv-Info header field) MUST be prepared to receive INFO requests 419 from multiple remote entities. Note that different remote entities 420 can indicate different sets of Info Packages which they are willing 421 to receive. 423 The construction of the INFO request is the same as any other request 424 within an existing INVITE dialog usage. A UA can send INFO requests 425 both on early and confirmed dialogs. 427 The INFO request MUST NOT contain a Recv-Info header field. The UA 428 can only indicate the Info Packages that it is willing to receive 429 using the messages listed in Section 3. 431 4.3. INFO Request Message Body 433 The purpose of the INFO request is to carry application level 434 information between SIP UAs. The application data associated with an 435 Info Package SHOULD be carried as a payload in the message body of 436 the INFO request, unless the information can be retrieved from a SIP 437 header field. 439 Info Package specifications MUST describe the application level 440 information associated with the Info Package. Message body payloads 441 MUST have a MIME type value defined. 443 If a UA indicates that it is willing to receive a specific Info 444 Package, it means that the UA also supports any associated message 445 body MIME type associated with the Info Package. However, the UA 446 MUST still indicate support of those MIME types also in the Accept 447 header filed, according to the procedures in [RFC3261]. 449 Some SIP extensions, which are orthogonal to INFO, MAY insert body 450 parts unrelated to the Info Package. UAs MUST conform to [RFC3261] 451 as updated by body-handling [I-D.ietf-sip-body-handling] to support 452 multipart MIME handling. 454 Each message body (or body part in the case of multipart MIME) MUST 455 contain a Content-Disposition header with an 'Info-Package' header 456 value, in order to in an easy way distinguish payloads associated 457 with the Info Package from other payloads. 459 If the whole message body is associated with the Info Package, the UA 460 MUST insert a Content-Disposition header with an 'Info-Package' 461 header value in the SIP part of the message. In that case, if 462 multipart MIME is used, the UA does not need to insert an 'Info- 463 Package' header value for the individual body parts. 465 NOTE: To avoid corner cases with legacy INFO usage, the Info-Package 466 header field is used to indicate the Info Package name, rather than 467 to use a Content-Disposition header field parameter in order to 468 indicate the name. 470 4.4. INFO Response 472 If a UA receives an INFO request, associated with an Info-Package 473 that the UA has indicated willingness to receive, and the INFO 474 request contains data associated with that Info-Package, the UA MUST 475 send a 200 OK response. 477 If a UA receives an INFO request, associated with an Info Package 478 that the UA has not indicated willingness to receive, the UA MUST 479 send a 469 Bad INFO Package response. In the terminology of Multiple 480 Dialog Usages [RFC5057], this represents a Transaction Only failure. 482 If a UA receives an INFO request for legacy usage, for which no Info- 483 Package is associated (the INFO request does not contain an Info- 484 Package header filed), the UA must send a 200 OK response. 486 If a UA receives an INFO request, which does not match any existing 487 INVITE dialog usage, the UA MUST send a 481 Call Leg/Transaction Does 488 Not Exist response. 490 If a UA receives an INFO request, which carries a message body that 491 the UA does not support, and support of the message body is required 492 in the Content-Disposition header field, the UA MUST send a 415 493 Unsupported Media Type response. If support of the message body is 494 optional, the UA MUST send a 200 OK response even if the UA does not 495 support the message body. 497 The UAS MAY send other responses, such as Request Failure (4xx), 498 Server Failure (5xx) and Global Failure (6xx) as appropriate for the 499 request. 501 4.5. INFO Response Message Body 503 The response to the INFO request is normally generated by the SIP 504 stack before the Info Package application data has been provided to 505 the application associated with the Info Package. Therefore, an Info 506 Package MUST NOT define the inclusion of a message body in an INFO 507 response. 509 If the application that received the information needs to send some 510 information in the other direction, it MUST trigger a new INFO 511 request, rather than using the response of the received INFO request. 513 4.6. Order of Delivery 515 The Info Package framework relies on the CSeq header field to detect 516 if an INFO request is received out of order. 518 If specific applications need additional mechanisms for order of 519 delivery, those mechanisms, and related procedures, MUST be specified 520 as part of the associated Info Package, and possible sequence numbers 521 etc MUST be defined as application data. 523 5. Formal INFO Method Definition 525 5.1. INFO Method 527 This document describes one new SIP method: INFO. This document 528 replaces the definition and registrations found in [RFC2976]. 530 This table expands on Tables 2 and 3 in [RFC3261]. 532 Header Where INFO 533 ------ ----- ---- 534 Accept R o 535 Accept-Encoding R o 536 Accept-Encoding 2xx o 537 Accept-Encoding 415 c 538 Accept-Language R o 539 Accept-Language 2xx o 540 Accept-Language 415 c 541 Alert-Info - 542 Allow R o 543 Allow 200 - 544 Allow 405 o 545 Authentication-Info 2xx o 546 Authorization R o 547 Call-ID c m 548 Call-Info o 549 Contact - 550 Content-Disposition o 551 Content-Encoding o 552 Content-Language o 553 Content-Length o 554 Content-Type * 555 CSeq c m 556 Date o 557 Error-Info 3xx-6xx o 558 Expires - 559 From c m 560 Geolocation R o 561 Max-Breadth R - 562 Max-Forwards R o 563 MIME-Version o 564 Min-Expires - 565 Organization o 566 Priority R - 567 Privacy R o 568 Proxy-Authenticate 407 o 569 Proxy-Authorization R o 570 Proxy-Require R o 571 Reason r o 572 Record-Route R o 573 Record-Route 2xx,18x o 574 Require o 575 Retry-After R - 576 Retry-After 404,480,486 o 577 Retry-After 503 o 578 Retry-After 600,603 o 579 Route R o 580 Security-Client R o 581 Security-Server 421,494 o 582 Security-Verify R o 583 Server r o 584 Subject R o 585 Supported R o 586 Supported 2xx o 587 Timestamp o 588 To c m (w/ Tag) 589 Unsupported 420 o 590 User-Agent o 591 Via m 592 Warning r o 593 WWW-Authenticate 401 m 594 WWW-Authenticate 407 o 596 Figure 1: Table 1: Summary of Header Fields 598 5.2. INFO Header Fields 600 This table expands on tables 2 and 3 in [RFC3261]. 602 Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR 603 ------------------------------------------------------------------------ 604 Info-Package R - - - - - - - m* - - - - - 605 Recv-Info R o - - o o o o - - o - o o 606 Recv-Info 2xx o - - o o - o - - o - o - 607 Recv-Info 1xx o - - o o - o - - o - - - 608 Recv-Info r o - - - o - o - - o - - - 610 * The Info-Package header field is MANDATORY for INFO requests 611 associated with Info Packages. The Info-Package header field is not 612 applicable for legacy usage INFO requests [RFC2976]. 614 Table 2: INFO-related Header Fields 616 5.2.1. Info-Package header field 618 This document adds Info-Package to the definition of the element 619 "message-header" in the SIP message grammar. Section 4 describes the 620 Info-Package header field usage. 622 For the purposes of matching Info Package types indicated in Recv- 623 Info with those in the Info-Package header field value, one compares 624 the Info-package-name portion of the Info-package-type portion of the 625 Info-Package header field octet-by-octet with that of the Recv-Info 626 header field value. That is, the Info Package name is case 627 sensitive. Info-package-param is not part of the comparison-checking 628 algorithm. 630 This document does not define values for Info-Package types. 631 Individual Info Package specifications define these values. Such 632 specifications MUST register the values with IANA. These values are 633 Specification Required [RFC5226]. 635 5.2.2. Recv-Info header field 637 This document adds Recv-Info to the definition of the element 638 "general-header" in the SIP [RFC3261] message grammar. Section 3 639 describes the Recv-Info header field usage. 641 6. Legacy INFO Usage 643 A number of applications, standardized and proprietary, make use of 644 INFO messages as defined in [RFC2976], without defined Info Packages 645 the and a possibility to use SIP to indicate what INFO usages UAs are 646 willing to use. For backward compatibility purpose, this document 647 does not deprecate such usage, and does not mandate to define Info 648 Packages for existing usages. However, any new usage of INFO SHALL 649 use the Info Package mechanism defined in this specification. 651 Since legacy INFO usages to not have associated Info Packages, it is 652 not possible to use the Recv-Info and Info-Package header fields for 653 legacy INFO usages. That is, a UA can not use the Recv-Info header 654 filed to indicate for which legacy usages it is willing to receive 655 INFO requests, and a UA can not use the Info-Package header to 656 indicate for which legacy INFO usage an INFO request is associated 657 with. 659 NOTE: For legacy INFO usages, static configuration is often used to 660 define what specific legacy INFO usages UAs support. 662 An INFO request associated with an Info Package MUST contain a Info- 663 Package header field. An INFO request without an Info-Package header 664 field MUST NOT contain an Info-Package header field, and the request 665 SHALL be interpreted as being a legacy INFO usage request. 667 UAs are allowed to enable both legacy INFO usages and Info Package 668 usages as part of the same session. 670 7. Info Package Requirements 672 7.1. General 674 This Section provides guidance on how to define an Info Package, and 675 what information needs to be provided. 677 If an Info Package extends or modifies the behavior described in this 678 document, it MUST be described in the definition for that Info 679 Package. Info Package definitions SHOULD NOT repeat procedures 680 defined in this specification, unless needed for clarification or 681 emphasis purpose. 683 Info Packages MUST NOT weaken any behavior designated with "SHOULD" 684 or "MUST" in this specification. However, Info Packages MAY 685 strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" 686 strength if applications associated with the Info Package requires 687 it. 689 Info Package definitions SHALL address the issues defined in the 690 following subsections, unless an issue is not applicable for the 691 specific Info Package. 693 7.2. Applicability 695 The Info Package specification MUST describe why the Info Package 696 mechanism, rather than some other mechanism, has been chosen for the 697 specific use-case to transfer application information between SIP 698 endpoints. Common reasons can be a requirement for SIP Proxies or 699 back-to-back User Agents (B2BUAs) to see the transport application 700 information, or that it is seen unfeasible to establish separate 701 dialogs (subscription) for transporting the information. 703 Annex A provides more information, and describes alternative 704 mechanisms which one should consider for solving the specific use- 705 case. 707 7.3. Info Package Name 709 The Info Package specification MUST define an Info Package name. 711 The specification MUST also define the header field value to be used 712 to indicate support of this package in the Recv-Info and Info-Package 713 header fields. The header field value MUST conform to the ABNF 714 defined in Section 8.2. 716 The specification MUST also include the information that appears in 717 the IANA registration of the token. For information on registering 718 such types, see Section **9. 720 7.4. Info Package Parameters 722 The Info Package specification MAY define Info Package parameters 723 which can be used in the Recv-Info or Info-Package header fields, 724 together with the header field value representing the Info Package. 726 The specification MUST describe the syntax and semantics of the 727 parameters. It MUST be specified whether a specific parameter is 728 only applicable to the Recv-Info header, the Info-Package header, or 729 both. 731 Note that Info Package parameters are only applicable for the Info 732 Package(s) for which they have been explicitly defined. If used for 733 other Info Packages they MUST be discarded. 735 7.5. SIP Option Tags 737 The Info Package specification MAY define SIP option tags, which can 738 be used as described in [RFC3261]. 740 SIP option tags MUST conform to the SIP Change Process [RFC3427]. 742 7.6. INFO Message Bodies 744 The Info Package specification MUST define what type of message 745 bodies, if any, are associated with the Info Package, and MUST refer 746 to specifications where the syntax, semantics and MIME type of the 747 message body is described. 749 7.7. Info Package Usage Restrictions 751 The Info Package specification MUST define whether a UA is allowed to 752 send overlapping (outstanding) INFO requests associated with the Info 753 Package, or whether the UA has to wait for the response for a 754 previous INFO request associated with the same Info Package. 756 The specification MUST define whether there SIP level restrictions in 757 the usage of the Info Package. For example, an Info Package may 758 require support of other SIP extensions (e.g. reliable provisional 759 responses). 761 The specification MUST define whether there are restrictions on 762 indicating support of, or using, the Info Package together with other 763 Info Packages. 765 If Info Package restrictions are violated (i.e. if overlapping INFO 766 requests are not allowed for an Info Package, but a UA still receives 767 overlapping requests), the UA MUST NOT reject such requests. Instead 768 the application logic associated with the Info Package MUST handle 769 such situations. 771 7.8. Rate of INFO Requests 773 The Info Package specification MUST a maximum rate at which INFO 774 requests associated with the specific Info Package can be generated 775 by a UA in a dialog. 777 The specification MAY define Info Package parameters to be used for 778 indicating or negotiating the INFO request rate. Alternatively the 779 rate information can be included in the application information 780 associated with the Info Package. 782 7.9. IANA Registrations 784 The Info Package specification MUST contain an IANA Considerations 785 section that includes definitions for the Info Package Name and, if 786 needed, supported MIME types. 788 7.10. Security Considerations 790 If the application information associated with the Info Package 791 requires certain level of security, the Info Package specification 792 MUST describe the mechanisms to be used in order to provide the 793 required security. 795 Otherwise, even if no additional security than what is provided for 796 the underlying SIP protocol is needed, it SHALL be stated in the Info 797 Package specification. 799 NOTE: In some cases, it may not be sufficient to mandate TLS in order 800 to secure the Info Package payload, since intermediaries will have 801 access to the payload and past the first hop, there is no way to 802 assure subsequent hops will not forwards the payload in clear text. 803 The best way to ensure secure transport at the application level is 804 to have the security at the application level. The most common 805 method of achieving this is to use end-to-end security techniques 806 such as S/MIME [RFC3851]. 808 7.11. Application Procedures 810 The Info Package specification SHOULD contain a description of the 811 application procedures associated with the Info Package, or 812 alternatively refer to application procedures defined elsewhere. 814 7.12. Examples 816 It is RECOMMENDED that Info Package specifications include 817 demonstrative message flow diagrams, paired with complete messages 818 and message descriptions. 820 Note that example flows are by definition informative, and MUST NOT 821 replace normative text 823 8. Syntax 825 8.1. General 827 This Section describes the syntax extensions required for the INFO 828 method. The previous sections describe the semantics. Note the 829 formal syntax definitions described in this document use the ABNF 830 format used in [RFC3261] and contain references to elements defined 831 therein. 833 8.2. ABNF 835 INFOm = %x49.4E.46.4F ; INFO in caps 836 extension-method = INFOm / token 838 Info-Package = "Info-Package" HCOLON Info-package-type 839 Recv-Info = "Recv-Info" HCOLON Info-package-list 840 Info-package-list = "nil" 841 / Info-package-type *( COMMA Info-package-type ) 842 Info-package-type = Info-package-name *( ";" Info-package-param) 843 Info-package-name = token 844 Info-package-param = generic-param 846 NOTE on the Recv-Info production: if the header field value is "nil", 847 the header field MUST NOT contain any other Info Packages, and the 848 SIP message MUST NOT contain more than one Recv-Info header field. 850 9. IANA Considerations 852 9.1. Update to Registration of SIP INFO Method 854 Please update the existing registration in the SIP Methods and 855 Response Codes registry under the SIP Parameters registry that 856 states: 858 Method: INFO 859 Reference: [RFC2976] 861 to: 863 Method: INFO 864 Reference: [RFCXXXX] 866 9.2. Registration of the Info-Package Header Field 868 Please add the following new SIP header field in the Header Fields 869 subregistry under the SIP Parameters registry. 871 Header Name: Info-Package 872 Compact Form: (none) 873 Reference: [RFCXXXX] 875 9.3. Registration of the Recv-Info Header Field 877 Please add the following new SIP header field in the Header Fields 878 subregistry under the SIP Parameters registry. 880 Header Name: Recv-Info 881 Compact Form: (none) 882 Reference: [RFCXXXX] 884 9.4. Creation of the Info Packages Registry 886 Please create a subregistry in the SIP Parameters registry for Info 887 Packages. This subregistry has a modified First Come First Served 888 [RFC5226] policy. 890 The following data elements populate the Info Package Registry. 891 o Info Package Name: The Info Package Name is a case-sensitive 892 token. In addition, IANA shall not register multiple Info Package 893 names that have identical case-insensitive values. 894 o Info Package Parameters: The Info Package Parameters are case- 895 sensitive tokens. Info Package Parameters are only applicable to 896 the Info Package for which they are defined, so the same Info 897 Package Parameter Names may exist for different Info Packages. 899 o Info Package Payload MIME Types: A list of zero or more registered 900 MIME types from the MIME Type Registry. 901 o Standards Status: Values are "Standards Track" or empty. See 902 below for a discussion and rules on this field. 903 o Reference: If there is a published specification describing the 904 Info Package, place a reference to that specification in this 905 column. See below for a discussion on this field. 907 If there is a published specification, the registration MUST include 908 a reference to such specification. The Standards Status field is an 909 indicator of the level of community review for the Info Package 910 specification. If the specification meets the requirements for 911 Specification Required [RFC5226], the value for the Standards Status 912 field is "Standards Track". Otherwise, the field is empty. 914 This document uses the Info Package Name "nil" to represent "no Info 915 Package present" and as such, IANA shall not honor a request to 916 register the "nil" Info Package. 918 The initial population of this table shall be: 920 Name MIME Type Standards Status Reference 921 nil Standards Track [RFCXXXX] 923 9.5. Registration of the Info-Package Content-Disposition 925 Please add the following registration to the Content-Disposition 926 registry. The description suitable for the IANA registry is as 927 follows. 929 The payload of the message carrying this Content-Disposition header 930 field value is the payload of an Info Package. 932 9.6. SIP Response Code 469 Registration 934 Please register the 469 response code in the Session Initiation 935 Protocol Parameters - Response Codes registry as follows. 936 Response Code: 469 937 Default Reason Phrase: Bad INFO Package 938 Reference: RFCXXXX 940 10. Examples 942 10.1. Simple Info Package 944 Here Alice sends Bob a simple Info Package payload. 946 INFO sip:alice@192.0.2.1 SIP/2.0 947 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 948 To: Alice ;tag=1234567 949 From: Bob ;tag=abcdefg 950 Call-Id: 123456mcmxcix 951 CSeq: 2 INFO 952 Info-Package: foo 953 Content-type: application/foo 954 Content-Disposition: Info-Package 955 Content-length: 24 957 I am a foo message type 959 10.2. Multipart INFO Example 961 Other SIP extensions can put payloads into an INFO method, 962 independent of the Info Package. In this case, the Info Package 963 payload gets put into a Multipart MIME body, with the content 964 disposition indicating which body belongs to the Info Package. Since 965 there is one and only one Info Package payload in the message, we 966 only need to tag which body part goes with the Info Package. 968 INFO sip:alice@192.0.2.1 SIP/2.0 969 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 970 To: Alice ;tag=1234567 971 From: Bob ;tag=abcdefg 972 Call-Id: 123456mcmxcix 973 CSeq: 7 INFO 974 Info-Package: foo 975 mumble-extension: 976 Content-Type: multipart/mixed;boundary="theboundary" 977 Content-Length: ... 979 --theboundary 980 Content-Type: application/mumble 981 Content-Id: abcd9999qq 982 ... 984 986 --theboundary 987 Content-Type: application/foo 988 Content-Disposition: Info-Package 989 Content-length: 24 991 I am a foo message type 992 --theboundary-- 994 11. Modifications to SIP Change Process 996 By eliminating multiple uses of INFO messages without adequate 997 community review and by eliminating the possibility for rogue SIP UAs 998 from confusing another User Agent by purposely sending unrelated INFO 999 requests, we expect this document's clarification of the use of INFO 1000 to improve the security of the Internet. Whilst rogue UAs can still 1001 send unrelated INFO requests, this framework provides mechanisms for 1002 which the UAS and other security devices can filter for approved Info 1003 Packages. 1005 If the content of the Info Package payload is private, User Agents 1006 will need to use end-to-end encryption, such as S/MIME, to prevent 1007 access to the content. This is particularly important as transport 1008 of INFO is likely not to be end-to-end, but through SIP proxies and 1009 back-to-back user agents (B2BUA's), which the user may not trust. 1011 The INFO mechanism transports application level information. One 1012 implication of this is INFO messages may require a higher level of 1013 protection than the underlying SIP-based session signaling. In 1014 particular, if one does not protect the SIP signaling from 1015 eavesdropping or authentication and repudiation attacks, for example 1016 by using TLS transport, then the INFO request and its contents will 1017 be vulnerable, as well. Even with SIP/TLS, any SIP hop along the 1018 path from UAC to UAS can view, modify, or intercept INFO requests, as 1019 they can with any SIP request. This means some applications may 1020 require end-to-end encryption of the INFO payload, beyond, for 1021 example, hop-by-hop protection of the SIP signaling itself. Since 1022 the application dictates the level of security required, individual 1023 Info Packages have to enumerate these requirements. In any event, 1024 the Info Package mechanism described by this document provides the 1025 tools for such secure, end-to-end transport of application data. 1027 One interesting property of Info Package use is one can reuse the 1028 same digest-challenge mechanism used for INVITE based authentication 1029 for the INFO request. For example, one could use a quality-of- 1030 protection (qop) value of authentication with integrity (auth-int), 1031 to challenge the request and its body, and prevent intermediate 1032 devices from modifying the body. However this assumes the device 1033 which knows the credentials in order to perform the INVITE challenge 1034 is still in the path for the INFO, or that the far-end UAS knows such 1035 credentials. 1037 12. References 1039 12.1. Normative References 1041 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1042 Requirement Levels", RFC 2119, BCP 14, March 1997. 1044 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1045 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1046 May 2008. 1048 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1049 A., Peterson, J., Sparks, R., Handley, M., and E. 1050 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1051 June 2002. 1053 [I-D.ietf-sip-body-handling] 1054 Camarillo, G., "Message Body Handling in the Session 1055 Initiation Protocol (SIP)", 1056 draft-ietf-sip-body-handling-06 (work in progress), 1057 March 2009. 1059 12.2. Informative References 1061 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1062 RFC 793, September 1981. 1064 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1065 October 2000. 1067 [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, 1068 "Interworking between the Session Initiation Protocol 1069 (SIP) and QSIG", BCP 117, RFC 4497, May 2006. 1071 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1072 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1073 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1075 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1076 August 1980. 1078 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1079 RFC 4949, August 2007. 1081 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 1082 RFC 3080, March 2001. 1084 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1085 Extensions (S/MIME) Version 3.1 Message Specification", 1086 RFC 3851, July 2004. 1088 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1089 Camarillo, "Best Current Practices for Third Party Call 1090 Control (3pcc) in the Session Initiation Protocol (SIP)", 1091 BCP 85, RFC 3725, April 2004. 1093 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 1094 and B. Rosen, "Change Process for the Session Initiation 1095 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 1097 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1098 Preferences for the Session Initiation Protocol (SIP)", 1099 RFC 3841, August 2004. 1101 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 1102 for Telephones (SIP-T): Context and Architectures", 1103 BCP 63, RFC 3372, September 2002. 1105 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1106 Event Notification", RFC 3265, June 2002. 1108 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1109 Context for Internet Mail", RFC 3458, January 2003. 1111 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1112 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1113 for Instant Messaging", RFC 3428, December 2002. 1115 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 1116 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 1118 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1119 the Session Description Protocol (SDP)", RFC 4145, 1120 September 2005. 1122 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1123 Media Services with SIP", RFC 4240, December 2005. 1125 [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol 1126 (SIP) Event Package for Key Press Stimulus (KPML)", 1127 RFC 4730, November 2006. 1129 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1130 RFC 4960, September 2007. 1132 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1133 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1135 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1136 Control Markup Language (MSCML) and Protocol", RFC 5022, 1137 September 2007. 1139 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 1140 Initiation Protocol", RFC 5057, November 2007. 1142 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1143 Media Control", RFC 5168, March 2008. 1145 [W3C.REC-voicexml21-20070619] 1146 Porter, B., McGlashan, S., Lee, A., Burnett, D., Carter, 1147 J., Oshry, M., Bodell, M., Baggia, P., Rehor, K., Burke, 1148 D., Candell, E., and R. Auburn, "Voice Extensible Markup 1149 Language (VoiceXML) 2.1", World Wide Web Consortium 1150 Recommendation REC-voicexml21-20070619, June 2007, 1151 . 1153 [I-D.ietf-speechsc-mrcpv2] 1154 Shanmugham, S. and D. Burnett, "Media Resource Control 1155 Protocol Version 2 (MRCPv2)", 1156 draft-ietf-speechsc-mrcpv2-19 (work in progress), 1157 June 2009. 1159 [I-D.saleem-msml] 1160 Sharratt, G. and A. Saleem, "Media Server Markup Language 1161 (MSML)", draft-saleem-msml-08 (work in progress), 1162 February 2009. 1164 Appendix A. Info Package Considerations 1166 A.1. General 1168 This section covers considerations to take into account when deciding 1169 whether the usage of an Info Package is appropriate for transporting 1170 of application information for a specific use-case. 1172 A.2. Appropriateness of Info Package Usage 1174 When designing an Info Package, for application level information 1175 exchange, it is important to consider: is signaling, using INFO 1176 requests, within a SIP session, an appropriate mechanism for the use- 1177 case? Is it because it is the most reasonable and appropriate 1178 choice, or merely because "it's easy"? Choosing an inappropriate 1179 mechanism for a specific use-case can cause negative effects in SIP 1180 networks where the mechanism is used. 1182 A.3. Dialog Fate Sharing 1184 As described in [RFC5057], an INFO request is always part of an 1185 INVITE dialog usage. 1187 One needs to consider the fate of the dialog usage of an INFO request 1188 is rejected. In some cases it may be acceptable that the whole 1189 dialog useage is terminated, while in other cases is is desirable to 1190 maintain the dialog usage. 1192 A.4. INFO Request Rate and Volume 1194 There is no default throttling mechanism for INFO requests. Apart 1195 from the session establishment, the number of SIP messages exchanged 1196 during a normal SIP session is rather small. 1198 Some applications, like sending of DTMF tones, can generate a burst 1199 of up to 20 messages per second. Other applications, like constant 1200 GPS location updates, could generate a high rate of INFO requests 1201 during the whole session. 1203 Furthermore, SIP messages tend to be relatively small, on the order 1204 of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct 1205 exchange of bulk data beyond these limits, especially if the headers 1206 plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for 1207 such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user 1208 plane data transport mechanisms. 1210 A.5. Alternative Mechanisms 1212 A.5.1. Alternative SIP signaling plane mechanisms 1214 A.5.1.1. General 1216 This subsection describes some alternative mechanisms for 1217 transporting application information on the SIP signaling plane, 1218 using SIP messages. 1220 A.5.1.2. SUBSCRIBE/NOTIFY 1222 An alternative for application level interaction is SIP Events, also 1223 known as SUBSCRIBE/NOTIFY [RFC3265]. In this model, a user agent 1224 requests state information, such as key pad presses from a device to 1225 an application server or key map images from an application server to 1226 a device. 1228 A SUBSCRIBE requests creates a new session, and a subscription dialog 1229 usage [RFC5057], which is separate, and does not share the fate any 1230 other sessions. 1232 The subscription mechanism can be used by SIP entities to receive 1233 state information about SIP sessions, without requiring the entities 1234 to be part of the route set of those sessions. 1236 As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies 1237 and B2BUAs, the resource impact caused by the subscription sessions 1238 needs to be considred. The number of subscription sessions per user 1239 also needs to be considered. 1241 As for any other SIP signaling plane based mechanism for transporting 1242 application information, the SUBSCRIBE/NOTIFY messages can put a 1243 significant burden on intermediate SIP entities which are part of the 1244 session route set, but do not have any interest in the application 1245 information transported between the end users. 1247 A.5.1.3. MESSAGE 1249 The MESSAGE method [RFC3428] defines one-time instant message 1250 exchange, typically for sending MIME contents for rendering to the 1251 user. 1253 A.5.2. Media Plane Mechanisms 1255 A.5.2.1. General 1257 In SIP, media plane channels associated with SIP sessions are 1258 established using SIP signaling, but the data exchanged on the media 1259 plane channel does not traverse SIP signaling intermediates, so if 1260 there will be a lot of information exchanged, and there is no need 1261 for the SIP signaling intermediates routing to examine the 1262 information, it is recommended to use a media plane mechanism, rather 1263 than a SIP signaling based. 1265 A low latency requirement for the exchange of information is one 1266 strong indicator for using a media channel. Exchanging information 1267 through the SIP routing network can introduce hundreds of 1268 milliseconds of latency. 1270 A.5.2.2. MRCPv2 1272 One mechanism for media plane exchange of application data is MRCPv2 1273 [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented 1274 channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is 1275 established. 1277 A.5.2.3. MRSP 1279 MSRP [RFC4975] defines session-based instant messaging as well as 1280 bulk file transfer and other such large-volume uses. 1282 A.5.3. Non-SIP related mechanisms 1284 Another alternative is to use a totally externally signaled channel, 1285 such as HTTP [RFC2616]. In this model, the user agent knows about a 1286 rendezvous point to direct HTTP requests to for the transfer of 1287 information. Examples include encoding of a prompt to retrieve in 1288 the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target 1289 in a VoiceXML [W3C.REC-voicexml21-20070619] script. 1291 Appendix B. Legacy INFO Usages 1293 We do not intend this section to be a comprehensive catalog of INFO 1294 usages. However, it should give the reader a flavor for current INFO 1295 usages. 1297 B.1. ISUP 1299 SIP-T uses Content-Type to identify ISUP protocol elements in an INFO 1300 message. See RFC3372 [RFC3372]. 1302 B.2. QSIG 1304 QSIG uses Content-Type to identify QSIG protocol elements in an INFO 1305 message. See RFC4497 [RFC4497]. 1307 B.3. MSCML 1309 MSCML uses a Require to ensure the UAS understands that INFO messages 1310 of the MSCML type are in fact MSCML messages. See RFC5022 [RFC5022]. 1312 B.4. MSML 1314 MSML endpoints just know the INFO messages carry MSML and from the 1315 Content-Type of the given INFO method request. See the MSML 1316 [I-D.saleem-msml] draft. 1318 B.5. Video Fast Update 1320 Microsoft, Polycom, and Radvision used INFO messages as an interim 1321 solution for requesting fast video update before the ability to 1322 request I-Frames in RTCP was available. See the XML Schema for Media 1323 Control [RFC5168] for more information. 1325 Appendix C. Acknowledgements 1327 We are standing on the shoulders of giants. Jonathan Rosenberg did 1328 the original "INFO Considered Harmful" Internet Draft on 26 December 1329 2002, which influenced the work group and this document. Likewise, 1330 Dean Willis influenced the text from his Internet Draft, "Packaging 1331 and Negotiation of INFO Methods for the Session Initiation Protocol" 1332 of 15 January 2003. Four paragraphs come from Jonathan Rosenberg's 1333 INFO Litmus draft. My, we have been working on this for a long time! 1335 This and other related drafts have elicited well over 450 messages on 1336 the SIP list. People who have argued with its thesis, supported its 1337 thesis, added to the examples, or argued with the examples, include 1338 the following individuals: 1339 Adam Roach, Bram Verburg, Brian Stucker, Chris Boulton, Cullen 1340 Jennings, Dale Worley, Dean Willis, Frank Miller, Gonzalo 1341 Camarillo, Gordon Beith, Henry Sinnreich, James Jackson, James 1342 Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan 1343 Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, 1344 Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul 1345 Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, 1346 Robert Sparks, Roland Jesske, Salvatore Loreto, Sam Ganesan, 1347 Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg, and 1348 Xavier Marjou. 1350 John Elwell and Francois Audet helped with QSIG references. In 1351 addition, Francois Audet provided actual text for the revised 1352 abstract. Keith Drage gave lots of excellent comments and helped 1353 immensely with Figure 1. 1355 The work group version of this document benefited from the close 1356 readings and comments from 1357 John Elwell, Paul Kyzivat, Dean Willis, Francois Audet, Dale 1358 Worley, Andrew Allen, Adam Roach, Anders Kristensen, Gordon Beith, 1359 Ben Campbell, Bob Penfield, Keith Drage, Jeroen van Bemmel, Mary 1360 Barnes, and Salvatore Loreto. 1362 Since publication of the first work group version of this document, 1363 we have had over 329 messages. New voices in addition to those 1364 included above include 1365 Arun Arunachalam, Christian Stredicke, Eric Rescorla, Inaki Baz 1366 Castillo, and Roni Evan. 1368 However, any errors and issues we missed are still our own. 1370 Appendix D. Change Log 1372 [RFC EDITOR NOTE: Please remove this section when publishing] 1374 Changes from draft-ietf-sip-info-events-03 1375 o Clarified Abstract language 1376 o All SIP dialogs are now refered to as sessions 1377 o Clarified the image example in the Introduction 1378 o Clarified the relationship (none) between SIP Event Packages and 1379 SIP Info Packages 1380 o Really, really clarified the protocol is NOT a negotiation but an 1381 advertisement 1382 o Split Section 3 into UAS and UAC behavior 1383 o Moved the example in section 3 into its own sub-section, and used 1384 full SIP header fields 1385 o Clarified forking behavior 1386 o Clarified language around when to send a body 1387 o Added 469 error response, instead of reusing 489 1388 o Clarified overlapping INFO method handling 1389 o Fixed table 1 to follow 3261, not 2543 1390 o Added REFER to the INFO Headers table 1391 o replaced token-nodot with token for Info-Package header field 1392 values 1393 o Clarified end-to-end security considerations 1394 o Info Package parameters are semi-colon delimited, not dot 1395 delimited 1397 Changes from -02 1398 o Applicability statement explicitly says we're backwards compatible 1399 o Explicitly state we work like UPDATE (both early and confirmed 1400 dialogs) 1401 o Agreed text for IANA Considerations package registry 1403 Changes from -01 1404 o One and only one Info Package per INFO 1405 o Removed Send-Info header field, greatly simplifying negotiation 1406 o Multiple body part identification through Content-Disposition: 1407 Info-Package 1408 o Note that forking INVITEs may result in multiple INFOs coming back 1409 to INVITE originator 1410 o Describe how a UAS can enforce strict adherence to this document 1411 o Remove CANCEL INFO faux pas 1412 o Better explained overlapping INFO issues and resolutions 1413 o Token names are now really case sensitive 1414 o Moved Info Package Considerations to an Appendix 1415 o Introduced stronger, yet more open, IANA registration process 1416 o Took a few more paragraphs from INFO Litmus to cover all bases. 1417 o Added RFC 5168 to legacy usages 1419 Changes from -00 1420 o Corrected ABNF. 1421 o Enabled sending of legacy INFO messages. Receiving legacy INFO 1422 messages was already here. 1423 o Negotiation is not Offer/Answer, it is Offer/Offer. 1424 o Created the explicit "nil" Info Package to indicate no info 1425 package. 1426 o Fixed CANCEL impacting future transactions. 1427 o Added Registrar behavior. 1428 o Added OPTIONS processing. 1429 o Clarified overlapping INFO method processing. 1430 o Described multiple INFO bodies in a single INFO method. 1431 o Took out Info-Package as a header field for responses to the INFO 1432 method. 1433 o Expanded on risks of using INFO and filled-in more on the 1434 alternatives 1436 o Moved definitions of INFO into the body of the text and cleaned up 1437 IANA Considerations section 1438 o Added legacy usages descriptions 1440 Authors' Addresses 1442 Eric W. Burger 1443 NeuStar, Inc. 1444 46000 Center Oak Plaza 1445 Sterling, VA 20166-6579 1446 USA 1448 Email: eburger@standardstrack.com 1449 URI: http://www.standardstrack.com 1451 Hadriel Kaplan 1452 Acme Packet 1453 71 Third Ave. 1454 Burlington, MA 01803 1455 USA 1457 Phone: 1458 Fax: 1459 Email: hkaplan@acmepacket.com 1460 URI: 1462 Christer Holmberg 1463 Ericsson 1464 Hirsalantie 11 1465 Jorvas, 02420 1466 Finland 1468 Phone: 1469 Fax: 1470 Email: christer.holmberg@ericsson.com 1471 URI: