--- 1/draft-ietf-sipcore-info-events-03.txt 2010-01-14 10:10:54.000000000 +0100 +++ 2/draft-ietf-sipcore-info-events-04.txt 2010-01-14 10:10:54.000000000 +0100 @@ -1,21 +1,21 @@ -SIPCORE E. Burger -Internet-Draft NeuStar, Inc. -Obsoletes: RFC 2976 H. Kaplan -(if approved) Acme Packet -Expires: June 5, 2010 C. Holmberg - Ericsson - December 2, 2009 +SIPCORE C. Holmberg +Internet-Draft Ericsson +Obsoletes: RFC 2976 E. Burger +(if approved) NeuStar, Inc. +Intended status: Standards Track H. Kaplan +Expires: July 18, 2010 Acme Packet + January 14, 2010 Session Initiation Protocol (SIP) INFO Method and Package Framework - draft-ietf-sipcore-info-events-03 + draft-ietf-sipcore-info-events-04 Abstract This document defines a new method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. @@ -41,122 +41,123 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 5, 2010. + This Internet-Draft will expire on July 18, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7 + 3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 8 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 4.4. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 12 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 + 6.2. Info-Package header field . . . . . . . . . . . . . . . . 15 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15 7. Info Package Considerations . . . . . . . . . . . . . . . . . 15 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15 7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15 7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16 7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17 7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 - 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 9.3. Co-existence with Info Package based INFO usage . . . . . 19 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Overal Description . . . . . . . . . . . . . . . . . . . 20 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 - 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 + 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 21 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 - 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21 + 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 22 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 - 10.10. Info Package Security Considerations . . . . . . . . . . 22 + 10.10. Info Package Security Considerations . . . . . . . . . . 23 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 11.2. Registration of the Info-Package Header Field . . . . . . 24 11.3. Registration of the Recv-Info Header Field . . . . . . . 24 11.4. Creation of the Info Packages Registry . . . . . . . . . 24 11.5. Registration of the Info-Package Content-Disposition . . 25 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Indication for which Info Packages UAs are willing to receive INFO requests . . . . . . . . . . . . . . . . . . 25 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 12.2. INFO request associated with Info Package . . . . . . . . 27 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 - 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 27 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 14.2. Informative References . . . . . . . . . . . . . . . . . 31 - Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 34 - A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 34 - A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 - Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 - Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 + 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 28 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 14.2. Informative References . . . . . . . . . . . . . . . . . 32 + Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 35 + A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 35 + A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 35 + Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 35 + Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction This document defines a new method, INFO, for the Session Initiation Protocol (SIP) [RFC3261]. The purpose of the INFO message is to carry application level information between endpoints, using the SIP dialog signaling path. Note that the INFO method is not used to update characteristics of a SIP dialog or session, but to allow the applications which use the @@ -185,25 +186,20 @@ NOTE: A UA can use an empty Recv-Info header field (a header field without a value) to indicate that it is not willing to receive INFO requests for any Info-Package, but to inform other UAs that it still supports the Info Package mechanism. When a UA sends an INFO request, it uses the Info-Package header field to indicate which Info Package is associated with the request. One particular INFO request can only be associated with a single Info Package. - This document obsoletes [RFC2976]. However, for backward - compatibility it specifies a "legacy" mode of usage of the INFO - method that is compatible with the usage previously defined in - [RFC2976], referred to as "legacy INFO Usage" in this document. - 2. Applicability This document defines a new method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. 3. The INFO Method @@ -215,46 +211,45 @@ A gives more details on the types of applications for which the use of INFO is appropriate. This section describes how a UA handles INFO requests and responses, as well as the message bodies included in INFO messages. 3.2. INFO Request 3.2.1. INFO Request Sender - An INFO request can be associated with an Info Package (see X), or - associated with a legacy INFO usage (see Y). + An INFO request can be associated with an Info Package (see + Section 4), or associated with a legacy INFO usage (see Section 9). - The construction of the INFO request is the same as any other request - within an existing invite dialog usage. A UA can send INFO requests - both within early and confirmed dialogs. + The construction of the INFO request is the same as any other non- + target refresh request within an existing invite dialog usage as + described in Section 12.2 of [RFC3261]. When a UA sends an INFO request associated with an Info Package, it MUST include an Info-Package header field that indicates which Info Package is associated with the request. A specific INFO request can be used only for a single Info Package. When a UA sends an INFO request associated with an legacy INFO usage there is no Info Package associated with the request, and the UA MUST NOT include an Info-Package header field in the request. The INFO request MUST NOT contain a Recv-Info header field. A UA can only indicate a set of Info Packages for which it is willing to receive INFO requests by using the SIP methods (and their responses) listed in Section 4. - A UA MUST NOT use the INFO method outside an invite dialog usage. - - UAs indicate, per-dialog basis, for which Info Packages they are - willing to receive INFO requests. The set of Info Packages cannot - automatically be used within other dialogs. + A UA MUST NOT send an INFO request outside an invite dialog usage and + MUST NOT send an INFO request for an Info Package inside an invite + dialog usage if the remote UA has not indicated willingness to + receive that Info-Package within that dialog. If a UA receives a 469 (Bad INFO Package) response to an INFO request, based on [RFC5057] the response represents a Transaction Only failure, and the UA MUST NOT terminate the invite dialog usage. Due to the possibility of forking, the UA whichs sends the initial INVITE reqest MUST be prepared to receive INFO requests from multiple remote UAs during the early dialog phase. In addition, the UA MUST be prepared to receive different Recv-Info header field values from different remote UAs. @@ -270,62 +265,69 @@ 3.2.2. INFO Request Receiver If a UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 (Bad INFO Package) response (see Section 11.6). In the terminology of Multiple Dialog Usages [RFC5057], this represents a Transaction Only failure, and does not terminate the invite dialog usage. - If a UA receives an INFO request associated with an Info Package, and - the message body part associated with the Info Package contains a - message body MIME type that the UA support, but which usage is not - defined for the specific Info Package, it is RECOMMENDED that the UA - sends a 415 (Unsupported Media Type) response. + If a UA receives an INFO request associated with an Info Package and + the message body part with Content-Disposition 'Info-Package' (see + Section 3.3.1) has a MIME type that the UA supports but not in the + context of that Info Package, it is RECOMMENDED that the UA send a + 415 (Unsupported Media Type) response. The UA MAY send other error responses, such as Request Failure (4xx), Server Failure (5xx) and Global Failure (6xx), in accordance with the error handling procedures in [RFC3261]. Otherwise, if the INFO request is syntactically correct and well structured, the UA MUST send a 200 (OK) response. NOTE: If the application needs to reject the information which it received in an INFO request, that needs to be done on the application level. Ie the application needs to trigger a new INFO request, which contains information that the previously received application data was not accepted. Individual Info Package specifications need to describe the details for such procedures. +3.2.3. SIP Proxies + + Proxies need no additional behavior beyond that described in + [RFC3261] to support INFO. + 3.3. INFO Message Body 3.3.1. INFO Request Message Body The purpose of the INFO request is to carry application level information between SIP UAs. The application information data is carried in the payload of the message body of the INFO request. NOTE: An INFO request assocated with an Info Package can also include information associated with the Info Package using Info-Package header field parameters. If an INFO request associated with an Info Package contains a message body part, the body part is identified by a Content-Disposition header field 'Info-Package' value. The body part can contain a single MIME type, or it can be a multipart [RFC5621] which contains other body parts associated with the Info Package. - UAs MUST conform to [RFC5621] to support multipart body parts. + UAs MUST support multipart body parts in accordance with [RFC5621]. - NOTE: Some SIP functions that are orthogonal to INFO can insert body - parts unrelated to the Info Package. + NOTE: An INFO request can also contain other body parts that are + meaningful within the context of an invite dialog usage but are not + specifically associated with the INFO method and the application + concerned. When a UA supports a specific Info-Package, the UA also support all message body MIME types associated with that Info-Package. However, in accordance with [RFC3261] the UA still indicates the supported MIME types using the Accept header. 3.3.2. INFO Response Message Body A UA MUST NOT include a message body associated with an Info Package in an INFO response. Message bodies associated with Info Packages @@ -363,22 +365,22 @@ This section describes how a UA handles Info Packages, how a UA uses the Recv-Info header field, and how the UA acts in re-INVITE rollback situations. 4.2.2. UA Procedures A UA which supports the Info Package mechanism MUST indicate, using the Revc-Info header field, the set of Info Packages for which it is willing to receive INFO requests. A UA can list multiple Info Packages in a single Recv-Info header field, and the UA can use - multiple Recv-Info header fields. A UA can an empty Recv-Info header - field, ie a header field without any header field values. + multiple Recv-Info header fields. A UA can use an empty Recv-Info + header field, ie a header field without any header field values. A UA provides its set of Info Packages for which it is willing to receive INFO requests during the dialog establishment. A UA can update the set of Info Packages during the invite dialog usage. If a UA is not willing to receive INFO requests for any Info Packages, during dialog establishment or later during the invite dialog usage, the UA MUST indicate this by including an empty Recv- Info header field. This informs other UAs that the UA still supports the Info Package mechanism. @@ -407,22 +409,22 @@ NOTE: When a UA sends a message which contains a Recv-Info header field with a new set of Info Packages for which the UA is willing to receive INFO requests the remote UA might, before it receives the message, send an INFO request based on the old set of Info Packages. In this case the receiver of the INFO requests rejects, and sends a 469 (Bad INFO Package) response to, the INFO request. If a UA indicates multiple Info Packages, which provide similar functionality, it is not possible to indicate a priority order of the - Info Packages, or that that the UA wishes to only receive INFO - request for one of the Info Packages. It is up to the application + Info Packages, or to indicate that the UA wishes to only receive INFO + requests for one of the Info Packages. It is up to the application logic associated with the Info Packages, and specific Info Package specifications, to describe application behavior in such cases. For backward compatibility purpose, even if a UA indicates support of the Info Package mechanism, it is still allowed to enable legacy INFO usages Appendix A. In addition, if a UA indicates support of the INFO method using the Allow header field [RFC3261], it does not implicitly indicate support of the Info Package mechanism. A UA MUST use the Recv-Info header field in order to indicate that it supports the Info Package mechanism. Likewise, even if a UA uses the Recv- @@ -547,22 +549,22 @@ From c m Geolocation R o Geolocation-Error r o Max-Breadth R - Max-Forwards R o MIME-Version o Min-Expires - Organization - Priority R - Privacy o - Proxy-Authenticate 401 m - Proxy-Authenticate 407 o + Proxy-Authenticate 401 o + Proxy-Authenticate 407 m Proxy-Authorization R o Proxy-Require R o Reason R o Record-Route R o Record-Route 2xx,18x o Referred-By R o Request-Disposition R o Require o Resource-Priority o Retry-After R - @@ -587,28 +589,37 @@ WWW-Authenticate 407 o Figure 1: Table 1: Summary of Header Fields 6. INFO Header Fields 6.1. General This table expands on tables 2 and 3 in [RFC3261]. -Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR ------------------------------------------------------------------------- -Info-Package R - - - - - - - m* - - - - - -Info-Package 469 - - - - - - - m* - - - - - -Recv-Info R - - - m m o o - - o - - - -Recv-Info 2xx - - - o** m - o***- - o***- - - -Recv-Info 1xx - - - o** - - - - - - - - - -Recv-Info r - - - o o - o - - o - - - + Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD + ------------------------------------------------------------------ + Info-Package R - - - - - - - m* - - + Info-Package 469 - - - - - - - m* - - + Recv-Info R - - - m m o o - - o + Recv-Info 2xx - - - o** m - o***- - o*** + Recv-Info 1xx - - - o** - - - - - - + Recv-Info r - - - o o - o - - o + + Header field where SUB NOT RFR + -------------------------------- + Info-Package R - - - + Info-Package 469 - - - + Recv-Info R - - - + Recv-Info 2xx - - - + Recv-Info 1xx - - - + Recv-Info r - - - The support and usage of the Info-Package and Recv-Info header fields is not applicalbe to UAs that only support legacy INFO usages. * Not applicalbe to INFO requests and responses associated with legacy INFO usages. ** Mandatory in at least one reliable 18x/2xx response, if sent, to the INVITE request, if the associated INVITE request contained a Recv-Info header field. *** Mandatory if the associated request contained a Recv-Info header field. Table 2: INFO-related Header Fields @@ -662,21 +673,21 @@ Some applications, like sending of DTMF tones, can generate a burst of up to 20 messages per second. Other applications, like constant GPS location updates, could generate a high rate of INFO requests during the lifetime of the invite dialog usage. Furthermore, SIP messages tend to be relatively small, on the order of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct exchange of bulk data beyond these limits, especially if the headers plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for - such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user + such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media plane data transport mechanisms. 7.4. Alternative Mechanisms 7.4.1. Alternative SIP signaling plane mechanisms 7.4.1.1. General This subsection describes some alternative mechanisms for transporting application information on the SIP signaling plane, @@ -723,58 +734,59 @@ ser. 7.4.2. Media Plane Mechanisms 7.4.2.1. General In SIP, media plane channels associated with SIP dialogs are established using SIP signaling, but the data exchanged on the media plane channel does not traverse SIP signaling intermediates, so if there will be a lot of information exchanged, and there is no need - for the SIP signaling intermediates routing to examine the - information, it is recommended to use a media plane mechanism, rather - than a SIP signaling based. + for the SIP signaling intermediaries to examine the information, it + is recommended to use a media plane mechanism, rather than a SIP + signaling based. A low latency requirement for the exchange of information is one strong indicator for using a media channel. Exchanging information through the SIP routing network can introduce hundreds of milliseconds of latency. 7.4.2.2. MRCPv2 One mechanism for media plane exchange of application data is MRCPv2 [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is established. 7.4.2.3. MRSP MSRP [RFC4975] defines session-based instant messaging as well as bulk file transfer and other such large-volume uses. 7.4.3. Non-SIP related mechanisms - Another alternative is to use a totally externally signaled channel, - such as HTTP [RFC2616]. In this model, the UA knows about a - rendezvous point to direct HTTP requests to for the transfer of - information. Examples include encoding of a prompt to retrieve in - the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target - in a VoiceXML [W3C.REC-voicexml21-20070619] script. + Another alternative is to use a a SIP-independent mechanism, such as + HTTP [RFC2616]. In this model, the UA knows about a rendezvous point + to direct HTTP requests to for the transfer of information. Examples + include encoding of a prompt to retrieve in the SIP Request URI in + [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- + voicexml21-20070619] script. 8. Syntax + 8.1. General This section describes the syntax extensions required for the INFO - method. The previous sections describe the semantics. Note the - formal syntax definitions described in this document use the ABNF - format used in [RFC3261] and contain references to elements defined - therein. + method, and for the Info-Package and Recv-Info header fields. The + previous sections describe the semantics. Note the formal syntax + definitions described in this document use the ABNF format used in + [RFC3261] and contain references to elements defined therein. 8.2. ABNF INFOm = %x49.4E.46.4F ; INFO in caps extension-method = INFOm / token Info-Package = "Info-Package" HCOLON Info-package-type Recv-Info = "Recv-Info" HCOLON [Info-package-list] Info-package-list = Info-package-type *( COMMA Info-package-type ) Info-package-type = Info-package-name *( SEMI Info-package-param) @@ -850,33 +862,33 @@ If, for an Info Package, there is a need to extend or modify the behavior described in this document, that behaviour MUST be described in the Info Package specification. It is bad practice for Info Package specifications to repeat procedures defined in this document, unless needed for clarification or emphasis purpose. Info Package specifications MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, Info Packages specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if applications - associated with the Info Package requires it. + associated with the Info Package require it. Info Package specifications MUST address the issues defined in the following subsections, or document why an issue is not applicable for the specific Info Package. Section 7.4 describes alternative mechanisms, which should be considered as part of the process for solving a specific use-case, - when for transporting application information. + when there is a need for transporting application information. 10.2. Overal Description - The Info Package specification MUST contain an overlap description of + The Info Package specification MUST contain an overall description of the Info Package: what type of information are carried in INFO requests associated with the Info Package, and for what type of applications and functionalities UAs can use the Info Package. If the Info Package is defined for a specific application, the Info Package specification MUST state which application UAs can use the Info Package with. 10.3. Applicability @@ -889,24 +901,23 @@ transported on a media path), or that it is not seen feasible to establish separate dialogs (subscription) in order to transport the information. Annex A provides more information, and describes alternative mechanisms which one should consider for solving a specific use-case. 10.4. Info Package Name The Info Package specification MUST define an Info Package name, - which UAs use as a header field value (e.g. "infoX") to be identify - the Info Package in the Recv-Info and Info-Package header fields. - The header field value MUST conform to the ABNF defined in - Section 8.2. + which UAs use as a header field value (e.g. "infoX") to identify the + Info Package in the Recv-Info and Info-Package header fields. The + header field value MUST conform to the ABNF defined in Section 8.2. The Info Package mechanism does not support package versioning. Specific Info Package message body payloads can contain version information, which is handled by the applications associated with the Info Package. However, such feature is outside the scope of the generic Info Package mechanism. NOTE: Even if an Info Package name contains version numbering (e.g. foo_v2), the Info Package mechanism does not distinguish a version number from the rest of the Info Package name. @@ -1085,21 +1096,22 @@ The initial population of this table shall be: Name Reference 11.5. Registration of the Info-Package Content-Disposition Please add the following new header field value to the Content- Disposition registry. Name: info-package -Description: the body contains information associated with an Info Package + Description: the body contains information associated with an + Info Package Reference: RFCXXXX 11.6. SIP Response Code 469 Registration Please register the following new response code in the Session Initiation Protocol Parameters - Response Codes registry. Response Code: 469 Default Reason Phrase: Bad INFO Package Reference: RFCXXXX @@ -1170,22 +1181,21 @@ CSeq: 314163 UPDATE Recv-Info: Contact: Content-Type: application/sdp Content-Length: ... ... The UAS sends a 200 (OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info - Packages R. - + Packages R, T. SIP/2.0 200 OK Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314163 INVITE Contact: Recv-Info: R, T Content-Type: application/sdp Content-Length: ... @@ -1451,23 +1461,23 @@ Media Control", RFC 5168, March 2008. [I-D.peterson-rai-rfc3427bis] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real- time Applications and Infrastructure Area", draft-peterson-rai-rfc3427bis-04 (work in progress), October 2009. [W3C.REC-voicexml21-20070619] - Lee, A., Porter, B., Oshry, M., Burnett, D., Rehor, K., - Auburn, R., Bodell, M., Burke, D., Baggia, P., Candell, - E., Carter, J., and S. McGlashan, "Voice Extensible Markup + Lee, A., Porter, B., McGlashan, S., Oshry, M., Auburn, R., + Rehor, K., Bodell, M., Burke, D., Baggia, P., Candell, E., + Burnett, D., and J. Carter, "Voice Extensible Markup Language (VoiceXML) 2.1", World Wide Web Consortium Recommendation REC-voicexml21-20070619, June 2007, . [I-D.ietf-speechsc-mrcpv2] Shanmugham, S. and D. Burnett, "Media Resource Control Protocol Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-20 (work in progress), August 2009. @@ -1536,32 +1546,36 @@ Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg and Xavier Marjoum. John Elwell and Francois Audet helped with QSIG references. In addition, Francois Audet provided text for the revised abstract. Keith Drage provided comments and helped immensely with Figure 1. - Brett Tate, John Elwell, Keith Drage and Robert Sparks provided - valuable feedback during the WGLC process, in order to prepare this - document for publication. + Arun Arunachalam, Brett Tate, John Elwell, Keith Drage and Robert + Sparks provided valuable feedback during the WGLC process, in order + to prepare this document for publication. Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided valuable input in order to sort out the message body part usage for Info Packages. Appendix C. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] + Changes from draft-ietf-sipcore-info-events-03 + o Further changes based on WGLC comments + o New section 3.2.3 added + Changes from draft-ietf-sipcore-info-events-02 o Further changes based on WGLC comments o Allignment with "specification" and "definition" terminology o Location switch of sections 3 and 4 o Corrections in header table o IANA Info Package registration input changed o Clarifiaction regarding which SIP messages can contain the Recv- Info header field o Recv-Info 'nil' value removed o Rules on usage of Recv-Info header clarified @@ -1650,44 +1664,45 @@ o Added Registrar behavior. o Added OPTIONS processing. o Clarified overlapping INFO method processing. o Described multiple INFO bodies in a single INFO method. o Took out Info-Package as a header field for responses to the INFO method. o Expanded on risks of using INFO and filled-in more on the alternatives o Moved definitions of INFO into the body of the text and cleaned up IANA Considerations section + o Added legacy usages descriptions Authors' Addresses + Christer Holmberg + Ericsson + Hirsalantie 11 + Jorvas, 02420 + Finland + + Phone: + Fax: + Email: christer.holmberg@ericsson.com + URI: + Eric W. Burger NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166-6579 USA Email: eburger@standardstrack.com URI: http://www.standardstrack.com Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA Phone: Fax: Email: hkaplan@acmepacket.com URI: - - Christer Holmberg - Ericsson - Hirsalantie 11 - Jorvas, 02420 - Finland - - Phone: - Fax: - Email: christer.holmberg@ericsson.com - URI: