idnits 2.17.1 draft-ietf-sipcore-info-events-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC2976], [RFC3261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 501 has weird spacing: '...3xx-6xx o...' == Line 552 has weird spacing: '... 2xx o ...' == Line 553 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 (October 23, 2009) is 5299 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 1044, but not defined == Unused Reference: 'RFC4497' is defined on line 1233, but no explicit reference was found in the text == Unused Reference: 'RFC3080' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: 'RFC3725' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: 'RFC3841' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: 'RFC4028' is defined on line 1281, but no explicit reference was found in the text == Unused Reference: 'RFC4145' is defined on line 1284, but no explicit reference was found in the text == Unused Reference: 'RFC4730' is defined on line 1291, 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 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-04) exists of draft-peterson-rai-rfc3427bis-03 == Outdated reference: A later version (-28) exists of draft-ietf-speechsc-mrcpv2-20 Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 8 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 26, 2010 C. Holmberg 7 Ericsson 8 October 23, 2009 10 Session Initiation Protocol (SIP) INFO Method and Package Framework 11 draft-ietf-sipcore-info-events-02 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 26, 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 defines a new method, INFO, for the Session Initiation 50 Protocol (SIP) [RFC3261], and an Info Package mechanism. The 51 document obsoletes [RFC2976]. For backward compatibility the 52 document also specifies a "legacy" mode of usage of the INFO method 53 that is compatible with the usage previously defined in [RFC2976], 54 referred to as "legacy INFO Usage" in this document. 56 Conventions Used in this Document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 61 The terminology in this document conforms to the Internet Security 62 Glossary [RFC4949]. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3. Info Package Support . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 6 71 3.3. Package Versioning . . . . . . . . . . . . . . . . . . . 7 72 3.4. REGISTER Processing . . . . . . . . . . . . . . . . . . . 7 73 3.5. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 8 74 4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 8 77 4.3. INFO Request Message Body . . . . . . . . . . . . . . . . 9 78 4.4. INFO Response . . . . . . . . . . . . . . . . . . . . . . 10 79 4.5. INFO Response Message Body . . . . . . . . . . . . . . . 11 80 4.6. Order of Delivery . . . . . . . . . . . . . . . . . . . . 11 81 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 11 82 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 11 83 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 84 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 6.2. Info-Package header field . . . . . . . . . . . . . . . . 13 86 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 14 87 7. Info Package Considerations . . . . . . . . . . . . . . . . . 14 88 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 14 90 7.3. Dialog Fate Sharing . . . . . . . . . . . . . . . . . . . 14 91 7.4. INFO Request Rate and Volume . . . . . . . . . . . . . . 14 92 7.5. Alternative Mechanisms . . . . . . . . . . . . . . . . . 15 93 7.5.1. Alternative SIP signaling plane mechanisms . . . . . . 15 94 7.5.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 16 95 7.5.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 96 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 17 100 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 102 9.3. Co-existence with Info Package based INFO usage . . . . . 18 103 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 104 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 10.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 19 106 10.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 19 107 10.4. Info Package Parameters . . . . . . . . . . . . . . . . . 20 108 10.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 20 109 10.6. INFO Message Bodies . . . . . . . . . . . . . . . . . . . 20 110 10.7. Info Package Usage Restrictions . . . . . . . . . . . . . 20 111 10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 21 112 10.9. IANA Registrations . . . . . . . . . . . . . . . . . . . 21 113 10.10. Info Package Security Considerations . . . . . . . . . . 21 114 10.11. Application Procedures . . . . . . . . . . . . . . . . . 22 115 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 22 116 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 117 11.1. Update to Registration of SIP INFO Method . . . . . . . . 22 118 11.2. Registration of the Info-Package Header Field . . . . . . 22 119 11.3. Registration of the Recv-Info Header Field . . . . . . . 23 120 11.4. Creation of the Info Packages Registry . . . . . . . . . 23 121 11.5. Registration of the Info-Package Content-Disposition . . 24 122 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 24 123 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 124 12.1. Indication of which Info Packages UAs are willing to 125 receive INFO requests within an invite dialog usage . . . 24 126 12.2. INFO request with information associated with a 127 simple Info Package . . . . . . . . . . . . . . . . . . . 25 128 12.3. Multipart INFO Example . . . . . . . . . . . . . . . . . 25 129 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 130 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 131 14.1. Normative References . . . . . . . . . . . . . . . . . . 27 132 14.2. Informative References . . . . . . . . . . . . . . . . . 28 133 Appendix A. Legacy INFO Usages . . . . . . . . . . . . . . . . . 30 134 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30 135 A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 30 136 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 30 137 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 30 138 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 31 139 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 31 140 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 31 141 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 31 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 144 1. Introduction 146 This document defines a new method, INFO, for the Session Initiation 147 Protocol (SIP) [RFC3261]. 149 The purpose of the INFO message is to carry application level 150 information between endpoints, using the SIP dialog signaling path. 151 Note that the INFO method is not used to update characteristics of a 152 SIP dialog or session, but to allow the applications which use the 153 SIP session to exchange information (which may update the state of 154 those applications). 156 This document also defines an Info Package mechanism. An Info 157 Package specification defines the content and semantics of the 158 information carried in an INFO message associated with the Info 159 Package. The Info Package mechanism also provides a way for UAs to 160 for which Info Packages they are willing to receive INFO requests. 161 The document defines how the INFO method is used, new SIP header 162 fields for the INFO method, and how to transport payload information 163 associated with an Info Package using INFO requests. 165 Use of the INFO method does not constitute a separate dialog usage. 166 INFO messages are always part of, and share the fate of, an invite 167 dialog usage [RFC5057]. INFO messages cannot be sent as part of 168 other dialog usages. 170 A UA uses the Recv-Info header field, on a per-dialog basis, to 171 indicate for which Info Packages it is willing to receive INFO 172 requests. A UA can indicate an initial set of Info Packages during 173 dialog establishment and can indicate a new set during the lifetime 174 of the invite dialog usage. 176 NOTE: A UA can use the Recv-Info header field with a 'nil' value to 177 indicate that it is not willing to receive INFO requests for any 178 Info-Package, but to inform other UAs that it still supports the Info 179 Package mechanism. 181 When a UA sends an INFO request, it uses the Info-Package header 182 field to indicate which Info Package is associated with the request. 183 One particular INFO request can only be associated with a single Info 184 Package. 186 This document obsoletes [RFC2976]. However, for backward 187 compatibility it specifies a "legacy" mode of usage of the INFO 188 method that is compatible with the usage previously defined in 189 [RFC2976], referred to as "legacy INFO Usage" in this document. 191 2. Applicability 193 This document defines a new method, INFO, for the Session Initiation 194 Protocol (SIP) [RFC3261], and an Info Package mechanism. The 195 document obsoletes [RFC2976]. For backward compatibility the 196 document also specifies a "legacy" mode of usage of the INFO method 197 that is compatible with the usage previously defined in [RFC2976], 198 referred to as "legacy INFO Usage" in this document. 200 3. Info Package Support 202 3.1. General 204 This section describes how SIP UAs indicate for which Info Packages 205 they are willing to receive INFO requests. 207 3.2. User Agent Behavior 209 A UA which supports the Info Package mechanism MUST indicate, using 210 the Revc-Info header field, the set of Info Packages for which it is 211 willing to receive INFO request. A UA can list multiple Info 212 Packages in a single Recv-Info header field, and the UA can use 213 multiple Recv-Info header fields. 215 The indication of Info Packages can take place during the dialog 216 establishment, and during a target refresh. This includes INVITE, 217 UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx 218 only). Note that the UAC is not required to indicate its set of Info 219 Packages in the initial INVITE request. 221 If a UA is not willing to INFO requests for any Info Packages, during 222 dialog establishment or later during the invite dialog usage, the UA 223 MUST indicate this by including a Recv-Info header field with a 'nil' 224 value. This informs other UAs that the UA still supports the Info 225 Package mechanism. 227 Example: If a UA has previously indicated Info Packages 'foo' and 228 'bar', and the UA during the lifetime of the invite dialog usage 229 wants to indicate that it does not want to receive INFO requests for 230 any Info Packages anymore, the UA sends a target refresh request with 231 a Recv-Info header field with a header value of 'nil'. 233 Once a UA has indicated that it is willing to receive INFO requests 234 for a specific Info Package, and a dialog has been established, the 235 UA MUST be prepared to receive INFO request associated with that Info 236 Package. 238 A UA MUST NOT send an INFO request associated with an Info Package 239 until it has received an indication that the remote UA is willing to 240 receive INFO requests for that Info Package, and a dialog has been 241 established with the remote UA. 243 If a UA indicates multiple Info Packages, which provide similar 244 functionality, it is not possible to indicate a priority order of the 245 Info Packages, or that that the UA wishes to only receive INFO 246 request for one of the Info Packages. It is up to the application 247 logic associated with the Info Packages, and specific Info Package 248 descriptions to describe application behavior in such cases. 250 For backward compatibility purpose, even if a UA indicates support of 251 the Info Package mechanism, it is still allowed to enable legacy INFO 252 usages Section 9. 254 This document does not define a SIP option tag [RFC3261] for the Info 255 Package mechanism. However, an Info Package specification can define 256 an option-tag associated with the specific Info Package, as described 257 in Section 10.5. 259 For backward compatibility, if a UA indicates support of the INFO 260 method using the Allow header field [RFC3261], it does not implicitly 261 indicate support of the Info Package mechanism. A UA MUST use the 262 Recv-Info header field in order to indicate that it supports the Info 263 Package mechanism. Likewise, even if a UA uses the Recv-Info header 264 field to indicate that it supports the Info Package mechanism, in 265 addition the UA MUST still also explicitly indicate support of the 266 INFO method using the Allow header field. 268 3.3. Package Versioning 270 The Info Package mechanism does not support package versioning. 271 Specific Info Package payloads MAY contain version information, which 272 is handled by the applications associated with the Info Package, but 273 that is outside the scope of the Info Package mechanism. 275 NOTE: Even if an Info Package name contains version numbering (e.g. 276 foo_v2), the Info Package mechanism does not distinguish a version 277 number from the rest of the Info Package name. 279 3.4. REGISTER Processing 281 This document allows a UA to insert a Recv-Info header field in a 282 REGISTER request. However, a UA SHALL NOT include a header value for 283 a specific Info Package unless the specific Info Package 284 specification describes how the header field value shall be 285 interpreted and used by the registrar, e.g. in order to determine 286 request targets. 288 NOTE: Rather than using the Recv-Info header field in order to 289 determine request targets, it is recommended to use more appropriate 290 mechanisms, e.g. based on [RFC3840]. 292 3.5. OPTIONS Processing 294 If a UA sends an OPTIONS request, or a response, the UA SHALL include 295 Recv-Info header field in the message, and list the Info Packages 296 that it supports to receive. 298 NOTE: As for any other capability and extension, for a specific 299 dialog UAs need to indicate which Info Packages they are willing to 300 receive within that dialog. 302 4. The INFO Method 304 4.1. General 306 This section describes the UA handling of INFO requests and 307 responses, and message bodies carried in INFO messages. 309 The INFO method provides additional, application level information 310 that can further enhance a SIP application. Annex A gives more 311 details on the types of application for which the usage of INFO is 312 seen as appropriate. 314 4.2. INFO Request 316 When a UA sends an INFO request associated with an Info Package, it 317 MUST include an Info-Package header field that indicates which Info 318 Package is associated with the request. A specific INFO request can 319 be used only for a single Info Package. For a specific dialog, a UA 320 MUST NOT send INFO requests associated with Info Packages that the 321 remote UA has not indicated that it is willing to receive. 323 A UA can send an INFO requests associated with a legacy INFO usage 324 Section 9. In such case there is no Info Package associated with the 325 usage, and the INFO request does not contain an Info-Package header 326 field. In addition, the UA cannot use the Recv-Info header field to 327 indicate whether it is willing to receive INFO requests associated 328 with that legacy INFO usage. 330 The INFO method MUST NOT be used outside an invite dialog usage. The 331 INFO method has no lifetime beyond its transaction or usage of its 332 own. UAs indicate, per-dialog basis, for which Info Packages they 333 are willing to receive INFO requests. The set of Info Packages 334 cannot automatically be used within other dialogs. 336 Due to the possibility of forking, a UAC which, during the early 337 dialog phase indicates that it is willing to receive INFO requests 338 for one or more Info Packages MUST be prepared to receive INFO 339 requests associated with those Info Packages from multiple remote 340 UAs. Note that each remote UA can indicate a different set of Info 341 Packages for which they are willing to receive INFO request. 343 The construction of the INFO request is the same as any other request 344 within an existing invite dialog usage. A UA can send INFO requests 345 both within early and confirmed dialogs. 347 The INFO request MUST NOT contain a Recv-Info header field. The UA 348 can only indicate a set of Info Packages for which it is willing to 349 receive INFO requests by using the SIP methods (and their responses) 350 listed in Section 3. 352 4.3. INFO Request Message Body 354 The purpose of the INFO request is to carry application level 355 information between SIP UAs. The application data associated with an 356 Info Package is carried as payload in the message body of the INFO 357 request, using one or more body parts. 359 Info Package specifications MUST describe the application level 360 information associated with the Info Package. Each body part MUST 361 have a MIME type value, and the syntax and content of the body part, 362 defined. 364 Each body part, when associated with an Info Package, MUST have a 365 Content-Disposition header field with an 'Info-Package' value 366 assigned, in order to be able distinguish body parts associated with 367 the Info Package from other body parts. 369 NOTE: Some SIP functions that are orthogonal to INFO may insert body 370 parts unrelated to the Info Package. 372 Body parts associated with specific MIME types may sometimes have 373 specific Content-Disposition header field values defined for them. 374 For example, for body parts with a 'text/plain' MIME a Content- 375 Disposition header field with a 'render' value is often assigned. 376 However, when a body part in the INFO message is associated with an 377 Info Package, it MUST always have a Content-Disposition header field 378 with an 'Info-Package' value assigned. The Info Package 379 specification defines how applications process the body part 380 contents. 382 If a SIP message body contains multiple body parts, multipart body 383 parts [RFC5621] are used to separate them. If all body parts within 384 a multipart body part are associated with the Info Package, the 385 multipart body part SHALL have a Content-Disposition header field 386 with an 'Info-Package' value assigned to it. However, each body part 387 within the multipart body part MUST still have a Content-Disposition 388 header field with an 'Info-Package' value assigned to them, in order 389 to avoid that the parser assigns a default Content-Disposition header 390 value to the body part. 392 NOTE: According to [RFC5621], body parts within a multipart are not 393 implicitly assigned the Content-Disposition header field value of the 394 multipart body part which they belong to. 396 This document does not define Info Package specific rules on how body 397 parts associated with Info Packages are to be inserted into multipart 398 body parts, and what type of multiparts are used. If an Info Package 399 requires special rules regarding the usage of multipart body parts, 400 the specification for that Info Package MUST specify such rules. 402 UAs MUST conform to [RFC5621] to support multipart body parts. 404 If a UA indicates that it is willing to receive a specific Info 405 Package, the UA naturally also supports any associated message body 406 part MIME type associated with the Info Package. However, in 407 addition the UA MUST still indicate support of those MIME types in 408 the Accept header field, according to the procedures in [RFC3261]. 410 NOTE: To avoid corner cases with legacy INFO usage, the Info-Package 411 header field is used to indicate the Info Package name, rather than 412 to use a Content-Disposition header field parameter in order to 413 indicate the name. 415 4.4. INFO Response 417 If a UA receives an INFO request, associated with an Info-Package 418 that the UA has indicated willingness to receive, and the INFO 419 request contains data associated with that Info-Package, the UA MUST 420 send a 200 OK response. 422 If a UA receives an INFO request for legacy usage, for which no Info- 423 Package is associated (the INFO request does not contain an Info- 424 Package header field), the UA MUST send a 200 OK response. 426 The UAS MAY send other responses, such as Request Failure (4xx), 427 Server Failure (5xx) and Global Failure (6xx) as appropriate for the 428 request. 430 If a UA receives an INFO request associated with an Info Package that 431 the UA has not indicated willingness to receive, the UA MUST send a 432 469 Bad INFO Package response Section 11.6. In the terminology of 433 Multiple Dialog Usages [RFC5057], this represents a Transaction Only 434 failure. 436 If a UA receives an INFO request that does not match any existing 437 invite dialog usage, the UA MUST send a 481 Call Leg/Transaction Does 438 Not Exist response. 440 If a UA receives an INFO request that carries a message body that the 441 UA does not support, and support of the message body is required in 442 the Content-Disposition header field, the UA MUST send a 415 443 Unsupported Media Type response. If support of the message body is 444 optional, the UA MUST send a 200 OK response even if the UA does not 445 support the message body. 447 4.5. INFO Response Message Body 449 The Info Package mechanism allows a SIP stack to generate a response 450 to an INFO request without application interaction. As a result, 451 Info Packages cannot require a message body in INFO responses, 452 require different response codes, or otherwise require the response 453 to the INFO request to contain application information. If the 454 application needs to send information in the other direction, it can 455 send a new INFO request which contains the information. 457 4.6. Order of Delivery 459 The Info Package mechanism relies on the CSeq header field to detect 460 if an INFO request is received out of order. 462 If specific applications need additional mechanisms for order of 463 delivery, those mechanisms, and related procedures, must be specified 464 as part of the associated Info Package, and possible sequence numbers 465 etc must be defined as application data. 467 5. Formal INFO Method Definition 469 5.1. INFO Method 471 This document describes one new SIP method: INFO. This document 472 replaces the definition and registrations found in [RFC2976]. 474 This table expands on Tables 2 and 3 in [RFC3261]. 476 Header Where INFO 477 ------ ----- ---- 478 Accept R o 479 Accept-Encoding R o 480 Accept-Encoding 2xx o 481 Accept-Encoding 415 c 482 Accept-Language R o 483 Accept-Language 2xx o 484 Accept-Language 415 c 485 Alert-Info - 486 Allow R o 487 Allow 200 - 488 Allow 405 o 489 Authentication-Info 2xx o 490 Authorization R o 491 Call-ID c m 492 Call-Info o 493 Contact - 494 Content-Disposition o 495 Content-Encoding o 496 Content-Language o 497 Content-Length o 498 Content-Type * 499 CSeq c m 500 Date o 501 Error-Info 3xx-6xx o 502 Expires - 503 From c m 504 Geolocation R o 505 Max-Breadth R - 506 Max-Forwards R o 507 MIME-Version o 508 Min-Expires - 509 Organization o 510 Priority R - 511 Privacy R o 512 Proxy-Authenticate 407 o 513 Proxy-Authorization R o 514 Proxy-Require R o 515 Reason r o 516 Record-Route R o 517 Record-Route 2xx,18x o 518 Require o 519 Retry-After R - 520 Retry-After 404,480,486 o 521 Retry-After 503 o 522 Retry-After 600,603 o 523 Route R o 524 Security-Client R o 525 Security-Server 421,494 o 526 Security-Verify R o 527 Server r o 528 Subject R o 529 Supported R o 530 Supported 2xx o 531 Timestamp o 532 To c m (w/ Tag) 533 Unsupported 420 o 534 User-Agent o 535 Via m 536 Warning r o 537 WWW-Authenticate 401 m 538 WWW-Authenticate 407 o 540 Figure 1: Table 1: Summary of Header Fields 542 6. INFO Header Fields 544 6.1. General 546 This table expands on tables 2 and 3 in [RFC3261]. 548 Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR 549 ------------------------------------------------------------------------ 550 Info-Package R - - - - - - - m* - - - - - 551 Recv-Info R o - - o o o o - - o - - - 552 Recv-Info 2xx o - - o o - o - - o - - - 553 Recv-Info 1xx o - - o o - o - - o - - - 554 Recv-Info r o - - - o - o - - o - - - 556 * The Info-Package header field is MANDATORY for INFO requests 557 associated with Info Packages. The Info-Package header field is not 558 applicable for legacy usage INFO requests [RFC2976]. 560 Table 2: INFO-related Header Fields 562 6.2. Info-Package header field 564 This document adds Info-Package to the definition of the element 565 "message-header" in the SIP message grammar [RFC3261]. Section 4 566 describes the Info-Package header field usage. 568 For the purposes of matching Info Package types indicated in Recv- 569 Info with those in the Info-Package header field value, one compares 570 the Info-package-name portion of the Info-package-type portion of the 571 Info-Package header field octet-by-octet with that of the Recv-Info 572 header field value. That is, the Info Package name is case 573 sensitive. Info-package-param is not part of the comparison-checking 574 algorithm. 576 This document does not define values for Info-Package types. 577 Individual Info Package specifications define these values. Such 578 specifications MUST register the values with IANA. These values are 579 Specification Required [RFC5226]. 581 6.3. Recv-Info header field 583 This document adds Recv-Info to the definition of the element 584 "message-header" in the SIP message grammar [RFC3261]. Section 3 585 describes the Recv-Info header field usage. 587 7. Info Package Considerations 589 7.1. General 591 This section covers considerations to take into account when deciding 592 whether the usage of an Info Package is appropriate for transporting 593 of application information for a specific use-case. 595 7.2. Appropriateness of Info Package Usage 597 When designing an Info Package, for application level information 598 exchange, it is important to consider: is signaling, using INFO 599 requests, within a SIP dialog, an appropriate mechanism for the use- 600 case? Is it because it is the most reasonable and appropriate 601 choice, or merely because "it's easy"? Choosing an inappropriate 602 mechanism for a specific use-case can cause negative effects in SIP 603 networks where the mechanism is used. 605 7.3. Dialog Fate Sharing 607 As described in [RFC5057], an INFO request is always part of an 608 INVITE dialog usage. 610 One needs to consider the fate of the dialog usage of an INFO request 611 is rejected. In some cases it may be acceptable that the whole 612 dialog usage is terminated, while in other cases is is desirable to 613 maintain the dialog usage. 615 7.4. INFO Request Rate and Volume 617 There is no default throttling mechanism for INFO requests. Apart 618 from the SIP session establishment, the number of SIP messages 619 exchanged during the lifetime a normal SIP session is rather small. 621 Some applications, like sending of DTMF tones, can generate a burst 622 of up to 20 messages per second. Other applications, like constant 623 GPS location updates, could generate a high rate of INFO requests 624 during the lifetime of the invite dialog usage. 626 Furthermore, SIP messages tend to be relatively small, on the order 627 of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct 628 exchange of bulk data beyond these limits, especially if the headers 629 plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for 630 such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user 631 plane data transport mechanisms. 633 7.5. Alternative Mechanisms 635 7.5.1. Alternative SIP signaling plane mechanisms 637 7.5.1.1. General 639 This subsection describes some alternative mechanisms for 640 transporting application information on the SIP signaling plane, 641 using SIP messages. 643 7.5.1.2. SUBSCRIBE/NOTIFY 645 An alternative for application level interaction is to use 646 subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and 647 NOTIFY methods. Using that mechanism, a user agent requests state 648 information, such as key pad presses from a device to an application 649 server or key map images from an application server to a device. 651 Event Packages [RFC3265] perform the role of disambiguating the 652 context of a message for subscription-based events. The Info Package 653 mechanism provides similar functionality for application information 654 exchange using invite dialog usages [RFC5057]. 656 While an INFO request is always part of, and shares the fate of, an 657 existing invite dialog usage, a SUBSCRIBE request creates a new 658 session and a subscription dialog usage [RFC5057] which is separate, 659 and does not share the fate any other sessions. 661 The subscription-based mechanism can be used by SIP entities to 662 receive state information about SIP dialogs and sessions, without 663 requiring the entities to be part of the route set of those dialogs 664 and sessions. 666 As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies 667 and B2BUAs, the resource impact caused by the subscription sessions 668 needs to be considered. The number of subscription sessions per user 669 also needs to be considered. 671 As for any other SIP signaling plane based mechanism for transporting 672 application information, the SUBSCRIBE/NOTIFY messages can put a 673 significant burden on intermediate SIP entities which are part of the 674 dialog route set, but do not have any interest in the application 675 information transported between the end users. 677 7.5.1.3. MESSAGE 679 The MESSAGE method [RFC3428] defines one-time instant message 680 exchange, typically for sending MIME contents for rendering to the 681 ser. 683 7.5.2. Media Plane Mechanisms 685 7.5.2.1. General 687 In SIP, media plane channels associated with SIP dialogs are 688 established using SIP signaling, but the data exchanged on the media 689 plane channel does not traverse SIP signaling intermediates, so if 690 there will be a lot of information exchanged, and there is no need 691 for the SIP signaling intermediates routing to examine the 692 information, it is recommended to use a media plane mechanism, rather 693 than a SIP signaling based. 695 A low latency requirement for the exchange of information is one 696 strong indicator for using a media channel. Exchanging information 697 through the SIP routing network can introduce hundreds of 698 milliseconds of latency. 700 7.5.2.2. MRCPv2 702 One mechanism for media plane exchange of application data is MRCPv2 703 [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented 704 channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is 705 established. 707 7.5.2.3. MRSP 709 MSRP [RFC4975] defines session-based instant messaging as well as 710 bulk file transfer and other such large-volume uses. 712 7.5.3. Non-SIP related mechanisms 714 Another alternative is to use a totally externally signaled channel, 715 such as HTTP [RFC2616]. In this model, the user agent knows about a 716 rendezvous point to direct HTTP requests to for the transfer of 717 information. Examples include encoding of a prompt to retrieve in 718 the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target 719 in a VoiceXML [W3C.REC-voicexml21-20070619] script. 721 8. Syntax 723 8.1. General 725 This Section describes the syntax extensions required for the INFO 726 method. The previous sections describe the semantics. Note the 727 formal syntax definitions described in this document use the ABNF 728 format used in [RFC3261] and contain references to elements defined 729 therein. 731 8.2. ABNF 733 INFOm = %x49.4E.46.4F ; INFO in caps 734 extension-method = INFOm / token 736 Info-Package = "Info-Package" HCOLON Info-package-type 737 Recv-Info = "Recv-Info" HCOLON Info-package-list 738 Info-package-list = "nil" 739 / Info-package-type *( COMMA Info-package-type ) 740 Info-package-type = Info-package-name *( ";" Info-package-param) 741 Info-package-name = token 742 Info-package-param = generic-param 744 NOTE on the Recv-Info production: if the header field value is "nil", 745 the header field MUST NOT contain any other Info Packages, and the 746 SIP message MUST NOT contain more than one Recv-Info header field. 748 9. Legacy INFO Usage 750 9.1. General 752 A number of applications, standardized and proprietary, make use of 753 the INFO method as it was previously defined in [RFC2976], referred 754 to as "legacy INFO usage". 756 For backward compatibility purpose, this document does not deprecate 757 such usages, and does not mandate users to define Info Packages for 758 such usages. However, any new usage of INFO SHALL use the Info 759 Package mechanism defined in this specification. 761 9.2. Problems 763 While legacy INFO usage has been widely adopted for specific 764 application use cases, [RFC2976] did not define a mechanism for SIP 765 UAs to indicate for which types of applications and contexts they 766 support the INFO method. In addition, [RFC2976] did not provide a 767 mechanism to explicitly indicate the type of application and context 768 for which a specific INFO message is associated. 770 Example: If the Content-Type is "image/jpeg", the MIME-attached 771 content is a JPEG image. Still, there are many useful ways a UA can 772 render an image. The image could be a caller-id picture, a contact 773 icon, a photo for sharing, and so on. The sender does not know which 774 image to send to the receiver if the receiver supports an image 775 content type. Likewise, the receiver does not know the context of an 776 image the client is sending if the receiver supports receiving more 777 than one image content type. 779 Since legacy INFO usages do not have associated Info Packages, it is 780 not possible to use the Recv-Info and Info-Package header fields with 781 legacy INFO usages. That is, a UA cannot use the Recv-Info header 782 field to indicate for which legacy INFO usages it is willing to 783 receive INFO requests, and a UA cannot use the Info-Package header 784 field to indicate for which legacy INFO usage an INFO request is 785 associated with. 787 Due to the problems described above, legacy INFO usages often require 788 static configuration about for what type of applications and contexts 789 UAs support the INFO method, and the way they handle application 790 information transported in INFO messages. That has caused 791 interoperability problems in the industry. Therefore, a need for a 792 well defined and documented description of what the information sent 793 in the INFO is used for has been identified. This situation is 794 analogous to the context issue in Internet Mail [RFC3458]. 796 9.3. Co-existence with Info Package based INFO usage 798 As described in Section 4, an INFO request associated with an Info 799 Package always contains an Info-Package header field. A legacy INFO 800 request MUST NOT contain an Info-Package header field. 802 UAs are allowed to enable both legacy INFO usages and Info Package 803 usages as part of the same invite dialog usage. 805 See Appendix A for examples of existing legacy INFO usages. 807 10. Info Package Requirements 809 10.1. General 811 This Section provides guidance on how to define an Info Package, and 812 what information needs to be provided. 814 If an Info Package extends or modifies the behavior described in this 815 document, it MUST be described in the definition for that Info 816 Package. Info Package definitions should not repeat procedures 817 defined in this specification, unless needed for clarification or 818 emphasis purpose. 820 Info Packages MUST NOT weaken any behavior designated with "SHOULD" 821 or "MUST" in this specification. However, Info Packages MAY 822 strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" 823 strength if applications associated with the Info Package requires 824 it. 826 Info Package definitions SHALL address the issues defined in the 827 following subsections, or document why an issue is not applicable for 828 the specific Info Package. 830 10.2. Applicability 832 The Info Package specification MUST describe why the Info Package 833 mechanism, rather than some other mechanism, has been chosen for the 834 specific use-case to transfer application information between SIP 835 endpoints. Common reasons can be a requirement for SIP Proxies or 836 back-to-back User Agents (B2BUAs) to see the transported application 837 information (which would not be the case if the information was 838 transported on a media path), or that it is not seen feasible to 839 establish separate dialogs (subscription) in order to transport the 840 information. 842 Annex A provides more information, and describes alternative 843 mechanisms which one should consider for solving a specific use-case. 845 10.3. Info Package Name 847 The Info Package specification MUST define a for Info Package name 848 (e.g. "Info Package for X"). 850 The specification MUST also define the header field value (e.g. 851 "infoX") to be used to indicate support of this package in the Recv- 852 Info and Info-Package header fields. The header field value MUST 853 conform to the ABNF defined in Section 8.2. 855 The specification MUST also include the information that appears in 856 the IANA registration of the token. For information on registering 857 such types, see Section 9. 859 10.4. Info Package Parameters 861 The Info Package specification MAY define Info Package parameters 862 which can be used in the Recv-Info or Info-Package header fields, 863 together with the header field value representing the Info Package. 865 The specification MUST describe the syntax and semantics of the 866 parameters. It MUST be specified whether a specific parameter is 867 only applicable to the Recv-Info header, the Info-Package header, or 868 both. 870 Note that Info Package parameters are only applicable for the Info 871 Package(s) for which they have been explicitly defined. They MUST 872 NOT be used for other Info Packages. 874 NOTE: Info Package parameters defined for specific Info Packages may 875 share the name with parameters defined for other Info Packages, but 876 the parameter semantics are specific to the Info Package for which 877 they are defined. 879 10.5. SIP Option Tags 881 The Info Package specification MAY define SIP option tags, which can 882 be used as described in [RFC3261]. 884 SIP option tags MUST conform to the SIP Change Process 885 [I-D.peterson-rai-rfc3427bis]. 887 10.6. INFO Message Bodies 889 The Info Package specification MUST define what type of message body 890 parts are associated with the Info Package, and MUST refer to 891 specifications where the syntax, semantics and MIME type of the 892 message body parts are described. 894 If multiple body parts are used with an Info Package, the Info 895 Package specification MUST define whether there are special rules on 896 how the body parts are to be inserted in multipart body parts, and 897 what types of multipart to use. 899 10.7. Info Package Usage Restrictions 901 The Info Package specification MUST define whether a UA is allowed to 902 send overlapping (outstanding) INFO requests associated with the Info 903 Package, or whether the UA has to wait for the response for a 904 previous INFO request associated with the same Info Package. 906 The specification MUST define whether there are SIP level 907 restrictions in the usage of the Info Package. For example, an Info 908 Package may require support of other SIP extensions (e.g. reliable 909 provisional responses). 911 The specification MUST define whether there are restrictions on 912 indicating support of, or using, the Info Package together with other 913 Info Packages. 915 As the SIP stack may not be aware of Info Package specific 916 restrictions, it cannot be assumed that overlapping requests would be 917 rejected. As defined in Section 4.4, in most cases a 200 OK response 918 will be sent for the INFO request. The application logic associated 919 with the Info Package needs to handle situations which can occur due 920 to overlapping requests. 922 10.8. Rate of INFO Requests 924 The Info Package specification MUST specify a maximum rate at which 925 INFO requests associated with the specific Info Package can be 926 generated by a UA in a dialog. 928 The specification MAY define Info Package parameters to be used for 929 indicating or negotiating the INFO request rate. Alternatively the 930 rate information can be included in the application information 931 associated with the Info Package. 933 10.9. IANA Registrations 935 The Info Package specification MUST contain an IANA Considerations 936 section that includes definitions for the Info Package Name and, if 937 needed, supported MIME types. 939 10.10. Info Package Security Considerations 941 If the application information associated with the Info Package 942 requires certain level of security, the Info Package specification 943 MUST describe the mechanisms to be used in order to provide the 944 required security. 946 Otherwise, even if no additional security than what is provided for 947 the underlying SIP protocol is needed, this fact SHALL be stated in 948 the Info Package specification. 950 NOTE: In some cases, it may not be sufficient to mandate TLS in order 951 to secure the Info Package payload, since intermediaries will have 952 access to the payload, and beyond the first hop, there is no way to 953 assure subsequent hops will not forwards the payload in clear text. 954 The best way to ensure secure transport at the application level is 955 to have the security at the application level. One way of achieving 956 this is to use end-to-end security techniques such as S/MIME 957 [RFC3851]. 959 10.11. Application Procedures 961 The Info Package specification SHOULD contain a description of the 962 application procedures associated with the Info Package, or 963 alternatively refer to application procedures defined elsewhere. 965 10.12. Examples 967 It is recommended that Info Package specifications include 968 demonstrative message flow diagrams, paired with complete messages 969 and message descriptions. 971 Note that example flows are by definition informative, and do not 972 replace normative text 974 11. IANA Considerations 976 11.1. Update to Registration of SIP INFO Method 978 Please update the existing registration in the SIP Methods and 979 Response Codes registry under the SIP Parameters registry that 980 states: 982 Method: INFO 983 Reference: [RFC2976] 985 to: 987 Method: INFO 988 Reference: [RFCXXXX] 990 11.2. Registration of the Info-Package Header Field 992 Please add the following new SIP header field in the Header Fields 993 subregistry under the SIP Parameters registry. 995 Header Name: Info-Package 996 Compact Form: (none) 997 Reference: [RFCXXXX] 999 11.3. Registration of the Recv-Info Header Field 1001 Please add the following new SIP header field in the Header Fields 1002 subregistry under the SIP Parameters registry. 1004 Header Name: Recv-Info 1005 Compact Form: (none) 1006 Reference: [RFCXXXX] 1008 11.4. Creation of the Info Packages Registry 1010 Please create a subregistry in the SIP Parameters registry for Info 1011 Packages. This subregistry has a modified First Come First Served 1012 [RFC5226] policy. 1014 The following data elements populate the Info Package Registry. 1015 o Info Package Name: The Info Package Name is a case-sensitive 1016 token. In addition, IANA shall not register multiple Info Package 1017 names that have identical case-insensitive values. 1018 o Info Package Parameters: The Info Package Parameters are case- 1019 sensitive tokens. Info Package Parameters are only applicable to 1020 the Info Package for which they are defined, so the same Info 1021 Package Parameter Names may exist for different Info Packages. 1022 o Info Package Payload MIME Types: A list of zero or more registered 1023 MIME types from the MIME Type Registry. 1024 o Standards Status: Values are "Standards Track" or empty. See 1025 below for a discussion and rules on this field. 1026 o Reference: If there is a published specification describing the 1027 Info Package, place a reference to that specification in this 1028 column. See below for a discussion on this field. 1030 If there is a published specification, the registration must include 1031 a reference to such specification. The Standards Status field is an 1032 indicator of the level of community review for the Info Package 1033 specification. If the specification meets the requirements for 1034 Specification Required [RFC5226], the value for the Standards Status 1035 field is "Standards Track". Otherwise, the field is empty. 1037 This document uses the Info Package Name "nil" to represent "no Info 1038 Package present" and as such, IANA shall not honor a request to 1039 register the "nil" Info Package. 1041 The initial population of this table shall be: 1043 Name MIME Type Standards Status Reference 1044 nil Standards Track [RFCXXXX] 1046 11.5. Registration of the Info-Package Content-Disposition 1048 Please add the following new header field value to the Content- 1049 Disposition registry. 1050 Name: info-package 1051 Description: the body contains information associated with an Info Package 1052 Reference: RFCXXXX 1054 11.6. SIP Response Code 469 Registration 1056 Please register the following new response code in the Session 1057 Initiation Protocol Parameters - Response Codes registry. 1058 Response Code: 469 1059 Default Reason Phrase: Bad INFO Package 1060 Reference: RFCXXXX 1062 12. Examples 1064 12.1. Indication of which Info Packages UAs are willing to receive INFO 1065 requests within an invite dialog usage 1067 The UAC sends an INVITE request, where the UAC indicates that it is 1068 willing to receive Info Packages P and R. 1070 INVITE sip:bob@example.com SIP/2.0 1071 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 1072 Max-Forwards: 70 1073 To: Bob 1074 From: Alice ;tag=1928301774 1075 Call-ID: a84b4c76e66710@pc33.example.com 1076 CSeq: 314159 INVITE 1077 Recv-Info: P, R 1078 Contact: 1079 Content-Type: application/sdp 1080 Content-Length: ... 1082 ... 1084 The UAS sends a 200 OK response back to the UAC, where the UAS 1085 indicates that it is willing to receive Info Packages R and T. 1087 SIP/2.0 200 OK 1088 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 1089 To: Bob ;tag=a6c85cf 1090 From: Alice ;tag=1928301774 1091 Call-ID: a84b4c76e66710@pc33.example.com 1092 CSeq: 314159 INVITE 1093 Contact: 1094 Recv-Info: R, T 1095 Content-Type: application/sdp 1096 Content-Length: ... 1098 ... 1100 The UAC sends ACK. 1102 ACK sip:ngw1@a.example.com SIP/2.0 1103 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 1104 Max-Forwards: 70 1105 To: Bob ;tag=a6c85cf 1106 From: Alice ;tag=1928301774 1107 Call-ID: a84b4c76e66710@pc33.example.com 1108 CSeq: 314159 ACK 1109 Content-Length: 0 1111 12.2. INFO request with information associated with a simple Info 1112 Package 1114 Here Alice sends Bob a simple Info Package payload. 1116 INFO sip:alice@192.0.2.1 SIP/2.0 1117 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1118 To: Alice ;tag=1234567 1119 From: Bob ;tag=abcdefg 1120 Call-Id: 123456mcmxcix 1121 CSeq: 2 INFO 1122 Info-Package: foo 1123 Content-type: application/foo 1124 Content-Disposition: Info-Package 1125 Content-length: 24 1127 I am a foo message type 1129 12.3. Multipart INFO Example 1131 Other SIP extensions can sometimes add payload body parts into an 1132 INFO request, independent of the Info Package. In this case, the 1133 Info Package payload gets put into a Multipart MIME body, with a 1134 Content-Disposition header field that indicates which body part is 1135 associated with the Info Package. 1137 INFO sip:alice@192.0.2.1 SIP/2.0 1138 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 1139 To: Alice ;tag=1234567 1140 From: Bob ;tag=abcdefg 1141 Call-Id: 123456mcmxcix 1142 CSeq: 7 INFO 1143 Info-Package: foo 1144 mumble-extension: 1145 Content-Type: multipart/mixed;boundary="theboundary" 1146 Content-Length: ... 1148 --theboundary 1149 Content-Type: application/mumble 1150 Content-Id: abcd9999qq 1151 ... 1153 1155 --theboundary 1156 Content-Type: application/foo 1157 Content-Disposition: Info-Package 1158 Content-length: 24 1160 I am a foo message type 1161 --theboundary-- 1163 13. Security Considerations 1165 By eliminating multiple usages of INFO messages without adequate 1166 community review and by eliminating the possibility for rogue SIP UAs 1167 from confusing another UA by purposely sending unrelated INFO 1168 requests, we expect this document's clarification of the use of INFO 1169 to improve the security of the Internet. Whilst rogue UAs can still 1170 send unrelated INFO requests, this mechanism provides mechanisms for 1171 which the UAS and other security devices can filter for approved Info 1172 Packages. 1174 If the content of the Info Package payload is private, UAs will need 1175 to use end-to-end encryption, such as S/MIME, to prevent access to 1176 the content. This is particularly important as transport of INFO is 1177 likely not to be end-to-end, but through SIP proxies and back-to-back 1178 user agents (B2BUA's), which the user may not trust. 1180 The INFO request transports application level information. One 1181 implication of this is INFO messages may require a higher level of 1182 protection than the underlying SIP dialog signaling. In particular, 1183 if one does not protect the SIP signaling from eavesdropping or 1184 authentication and repudiation attacks, for example by using TLS 1185 transport, then the INFO request and its contents will be vulnerable, 1186 as well. Even with SIP/TLS, any SIP hop along the path from UAC to 1187 UAS can view, modify, or intercept INFO requests, as they can with 1188 any SIP request. This means some applications may require end-to-end 1189 encryption of the INFO payload, beyond, for example, hop-by-hop 1190 protection of the SIP signaling itself. Since the application 1191 dictates the level of security required, individual Info Packages 1192 have to enumerate these requirements. In any event, the Info Package 1193 mechanism described by this document provides the tools for such 1194 secure, end-to-end transport of application data. 1196 One interesting property of Info Package use is one can reuse the 1197 same digest-challenge mechanism used for INVITE based authentication 1198 for the INFO request. For example, one could use a quality-of- 1199 protection (qop) value of authentication with integrity (auth-int), 1200 to challenge the request and its body, and prevent intermediate 1201 devices from modifying the body. However this assumes the device 1202 which knows the credentials in order to perform the INVITE challenge 1203 is still in the path for the INFO, or that the far-end UAS knows such 1204 credentials. 1206 14. References 1208 14.1. Normative References 1210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1211 Requirement Levels", BCP 14, RFC 2119, March 1997. 1213 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1214 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1215 May 2008. 1217 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1218 A., Peterson, J., Sparks, R., Handley, M., and E. 1219 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1220 June 2002. 1222 [RFC5621] Camarillo, G., "Message Body Handling in the Session 1223 Initiation Protocol (SIP)", RFC 5621, September 2009. 1225 14.2. Informative References 1227 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1228 RFC 793, September 1981. 1230 [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, 1231 October 2000. 1233 [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, 1234 "Interworking between the Session Initiation Protocol 1235 (SIP) and QSIG", BCP 117, RFC 4497, May 2006. 1237 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1238 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1239 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1241 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1242 August 1980. 1244 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1245 RFC 4949, August 2007. 1247 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 1248 RFC 3080, March 2001. 1250 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1251 Extensions (S/MIME) Version 3.1 Message Specification", 1252 RFC 3851, July 2004. 1254 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1255 Camarillo, "Best Current Practices for Third Party Call 1256 Control (3pcc) in the Session Initiation Protocol (SIP)", 1257 BCP 85, RFC 3725, April 2004. 1259 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 1260 "Indicating User Agent Capabilities in the Session 1261 Initiation Protocol (SIP)", RFC 3840, August 2004. 1263 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1264 Preferences for the Session Initiation Protocol (SIP)", 1265 RFC 3841, August 2004. 1267 [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol 1268 for Telephones (SIP-T): Context and Architectures", 1269 BCP 63, RFC 3372, September 2002. 1271 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1272 Event Notification", RFC 3265, June 2002. 1274 [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message 1275 Context for Internet Mail", RFC 3458, January 2003. 1277 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1278 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1279 for Instant Messaging", RFC 3428, December 2002. 1281 [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the 1282 Session Initiation Protocol (SIP)", RFC 4028, April 2005. 1284 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1285 the Session Description Protocol (SDP)", RFC 4145, 1286 September 2005. 1288 [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network 1289 Media Services with SIP", RFC 4240, December 2005. 1291 [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol 1292 (SIP) Event Package for Key Press Stimulus (KPML)", 1293 RFC 4730, November 2006. 1295 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1296 RFC 4960, September 2007. 1298 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 1299 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 1301 [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server 1302 Control Markup Language (MSCML) and Protocol", RFC 5022, 1303 September 2007. 1305 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 1306 Initiation Protocol", RFC 5057, November 2007. 1308 [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 1309 Media Control", RFC 5168, March 2008. 1311 [I-D.peterson-rai-rfc3427bis] 1312 Peterson, J., Jennings, C., and R. Sparks, "Change Process 1313 for the Session Initiation Protocol (SIP)", 1314 draft-peterson-rai-rfc3427bis-03 (work in progress), 1315 September 2009. 1317 [W3C.REC-voicexml21-20070619] 1318 McGlashan, S., Lee, A., Carter, J., Porter, B., Auburn, 1319 R., Oshry, M., Rehor, K., Bodell, M., Burke, D., Baggia, 1320 P., Candell, E., and D. Burnett, "Voice Extensible Markup 1321 Language (VoiceXML) 2.1", World Wide Web Consortium 1322 Recommendation REC-voicexml21-20070619, June 2007, 1323 . 1325 [I-D.ietf-speechsc-mrcpv2] 1326 Shanmugham, S. and D. Burnett, "Media Resource Control 1327 Protocol Version 2 (MRCPv2)", 1328 draft-ietf-speechsc-mrcpv2-20 (work in progress), 1329 August 2009. 1331 [I-D.saleem-msml] 1332 Saleem, A. and G. Sharratt, "Media Server Markup Language 1333 (MSML)", draft-saleem-msml-09 (work in progress), 1334 July 2009. 1336 [Ecma-355] 1337 "Standard ECMA-355 Corporate Telecommunication Networks - 1338 Tunnelling of QSIG over SIP", ECMA http:// 1339 www.ecma-international.org/publications/standards/ 1340 Ecma-355.htm, June 2008. 1342 Appendix A. Legacy INFO Usages 1344 A.1. General 1346 This section provides examples of existing legacy INFO usages. This 1347 section is not meant to be a comprehensive catalog of legacy INFO 1348 usages, but it should give the reader a flavor for current legacy 1349 INFO usages. 1351 A.2. ISUP 1353 [RFC3372] specifies the encapsulation of ISUP in SIP message bodies. 1354 ITU-T and 3GPP have specified similar procedures. 1356 A.3. QSIG 1358 [Ecma-355] specifies the encapsulation of QSIG in SIP message bodies. 1360 A.4. MSCML 1362 [RFC5022] specifies how INFO is used as a transport mechanism by the 1363 MSCML protocol. MSCML uses an option-tag in the Require header field 1364 to ensure that the receiver understands the INFO content. 1366 A.5. MSML 1368 [I-D.saleem-msml] specifies how INFO us used as a transport mechanism 1369 by the MSML protocol. 1371 A.6. Video Fast Update 1373 Companies have been using INFO messages in order to request fast 1374 video update. Currently a standardized mechanism, based on RTCP, has 1375 been specified in [RFC5168] 1377 Appendix B. Acknowledgements 1379 The work on this document was influenced by the "INFO Considered 1380 Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and 1381 by the "Packaging and Negotiation of INFO Methods for the Session 1382 Initiation Protocol" draft (15 January 2003) written by Dean Willis. 1384 The following individuals have been involved in the work, and have 1385 provided input and feedback on this document: 1386 Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben 1387 Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris 1388 Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean 1389 Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon 1390 Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James 1391 Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan 1392 Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard 1393 Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael 1394 Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, 1395 Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore 1396 Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve 1397 Langstaff, Sumit Garg and Xavier Marjoum. 1399 John Elwell and Francois Audet helped with QSIG references. In 1400 addition, Francois Audet provided text for the revised abstract. 1401 Keith Drage provided comments and helped immensely with Figure 1. 1403 John Elwell and Robert Sparks provided valuable feedback during the 1404 WGLC process, in order to prepare this document for publication. 1406 Appendix C. Change Log 1408 [RFC EDITOR NOTE: Please remove this section when publishing] 1410 Changes from draft-ietf-sipcore-info-events-01 1411 o Further changes based on WGLC comments 1412 o Appending A moved into the main part of the document 1413 o Section name changed from "Modifications to SIP Change Process" to 1414 "Security Considerations" 1415 o "Syntax" section moved further up in the document 1416 o Clarification on usage of Info Package related message body parts, 1417 and the usage of the Content-Disposition header field with those 1418 body parts 1419 o Removed REFER and NOTIFY from the INFO Headers table 1420 o Clarified usage of the Recv-Info header field in the REGISTER and 1421 OPTIONS requests 1422 o Major re-write of the Introduction section 1423 o Text about legacy INFO and subscription-based events moved from 1424 the Introduction to the main part of the document 1425 o Wording about receiving Info-Packages has been replaced with 1426 wording about receiving INFO requests for Info-Packages 1427 o The text about the usage of message body, and body parts, 1428 associated with Info Packages, has been clarified 1430 Changes from draft-ietf-sip-info-events-04 1431 o Major re-write of the document, due to problems to implement WGLC 1432 comments into the existing text structure 1433 o Wording allignment 1434 o Clarification or roles 1436 Changes from draft-ietf-sip-info-events-03 1437 o Clarified Abstract language 1438 o All SIP dialogs are now refered to as sessions 1439 o Clarified the image example in the Introduction 1440 o Clarified the relationship (none) between SIP Event Packages and 1441 SIP Info Packages 1442 o Really, really clarified the protocol is NOT a negotiation but an 1443 advertisement 1444 o Split Section 3 into UAS and UAC behavior 1445 o Moved the example in section 3 into its own sub-section, and used 1446 full SIP header fields 1447 o Clarified forking behavior 1448 o Clarified language around when to send a body 1449 o Added 469 error response, instead of reusing 489 1450 o Clarified overlapping INFO method handling 1451 o Fixed table 1 to follow 3261, not 2543 1452 o Added REFER to the INFO Headers table 1453 o replaced token-nodot with token for Info-Package header field 1454 values 1455 o Clarified end-to-end security considerations 1456 o Info Package parameters are semi-colon delimited, not dot 1457 delimited 1459 Changes from -02 1460 o Applicability statement explicitly says we're backwards compatible 1461 o Explicitly state we work like UPDATE (both early and confirmed 1462 dialogs) 1463 o Agreed text for IANA Considerations package registry 1465 Changes from -01 1466 o One and only one Info Package per INFO 1467 o Removed Send-Info header field, greatly simplifying negotiation 1468 o Multiple body part identification through Content-Disposition: 1469 Info-Package 1470 o Note that forking INVITEs may result in multiple INFOs coming back 1471 to INVITE originator 1472 o Describe how a UAS can enforce strict adherence to this document 1473 o Remove CANCEL INFO faux pas 1474 o Better explained overlapping INFO issues and resolutions 1475 o Token names are now really case sensitive 1476 o Moved Info Package Considerations to an Appendix 1477 o Introduced stronger, yet more open, IANA registration process 1478 o Took a few more paragraphs from INFO Litmus to cover all bases. 1479 o Added RFC 5168 to legacy usages 1481 Changes from -00 1482 o Corrected ABNF. 1483 o Enabled sending of legacy INFO messages. Receiving legacy INFO 1484 messages was already here. 1485 o Negotiation is not Offer/Answer, it is Offer/Offer. 1486 o Created the explicit "nil" Info Package to indicate no info 1487 package. 1488 o Fixed CANCEL impacting future transactions. 1489 o Added Registrar behavior. 1490 o Added OPTIONS processing. 1491 o Clarified overlapping INFO method processing. 1492 o Described multiple INFO bodies in a single INFO method. 1493 o Took out Info-Package as a header field for responses to the INFO 1494 method. 1495 o Expanded on risks of using INFO and filled-in more on the 1496 alternatives 1497 o Moved definitions of INFO into the body of the text and cleaned up 1498 IANA Considerations section 1499 o Added legacy usages descriptions 1501 Authors' Addresses 1503 Eric W. Burger 1504 NeuStar, Inc. 1505 46000 Center Oak Plaza 1506 Sterling, VA 20166-6579 1507 USA 1509 Email: eburger@standardstrack.com 1510 URI: http://www.standardstrack.com 1512 Hadriel Kaplan 1513 Acme Packet 1514 71 Third Ave. 1515 Burlington, MA 01803 1516 USA 1518 Phone: 1519 Fax: 1520 Email: hkaplan@acmepacket.com 1521 URI: 1523 Christer Holmberg 1524 Ericsson 1525 Hirsalantie 11 1526 Jorvas, 02420 1527 Finland 1529 Phone: 1530 Fax: 1531 Email: christer.holmberg@ericsson.com 1532 URI: