--- 1/draft-ietf-sipcore-info-events-05.txt 2010-01-29 14:10:53.000000000 +0100 +++ 2/draft-ietf-sipcore-info-events-06.txt 2010-01-29 14:10:53.000000000 +0100 @@ -1,21 +1,21 @@ SIPCORE C. Holmberg Internet-Draft Ericsson Obsoletes: RFC 2976 E. Burger (if approved) NeuStar, Inc. Intended status: Standards Track H. Kaplan -Expires: July 22, 2010 Acme Packet - January 18, 2010 +Expires: August 2, 2010 Acme Packet + January 29, 2010 Session Initiation Protocol (SIP) INFO Method and Package Framework - draft-ietf-sipcore-info-events-05 + draft-ietf-sipcore-info-events-06 Abstract This document defines a 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,21 +41,21 @@ 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 July 22, 2010. + This Internet-Draft will expire on August 2, 2010. Copyright Notice 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 @@ -103,37 +103,37 @@ 7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 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.2. Overall Description . . . . . . . . . . . . . . . . . . . 20 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 10.10. Info Package Security Considerations . . . . . . . . . . 22 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.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 . . 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 @@ -240,41 +240,41 @@ 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. + Due to the possibility of forking, the UA which sends the initial + INVITE request 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. NOTE: If the UAS (receiver of the initial INVITE request) sends an INFO request just after it has sent the response which creates the dialog, the UAS needs to be prepared that the INFO request can reach the UAC before the dialog creating response, and might therefore be rejected by the UAC. In addition, an INFO request might be rejected due to a race condition, if a UA sends the INFO request at the same time as the remote UA sends a new set of Info Packages for which it is willing to receive INFO requests. 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), which contains a - Recv-Info Header field with Info Packages for which the UA is willing + Recv-Info header field with Info Packages for which the UA is willing to receive INFO requests. The UA MUST NOT use the response to update the set of Info Packages, but simply to indicate the current set. 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 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 @@ -300,23 +300,23 @@ [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. + NOTE: An INFO request associated 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 support multipart body parts in accordance with [RFC5621]. NOTE: An INFO request can also contain other body parts that are @@ -443,21 +443,21 @@ 4.2.3. Recv-Info header field rules The text below defines rules on when a UA is required to include a Recv-Info header field in SIP messages. Section 6.1 lists the SIP methods, for which a UA can insert a Recv-Info header field in requests and responses. - The sender of an initial INVITE request MUST include a Recv-Info header field in the initial INVITE request, even if the sender is not - willing to receive INFO requests asscoiated with any Info Package. + willing to receive INFO requests associated with any Info Package. - The receiver of a request which contains a Recv-Info header field MUST include a Recv-Info header field in a reliable 18x/2xx response to the request, even if the request contains an empty Recv-Info header field, and even if the header field value of the receiver has not changed since the previous time it sent a Recv-Info header field. - A UA MUST NOT include a Recv-Info header field in a response if the associated request did not contain a Recv-Info header field. @@ -602,23 +602,23 @@ Info-Package R - - - Recv-Info R - - - Recv-Info 2xx - - - Recv-Info 1xx - - - Recv-Info 469 - - - Recv-Info r - - - Table 2: INFO-related Header Fields The support and usage of the Info-Package and Recv-Info header fields - is not applicalbe to UAs that only support legacy INFO usages. + is not applicable to UAs that only support legacy INFO usages. - * Not applicalbe to INFO requests and responses associated with + * Not applicable 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. 6.2. Info-Package header field @@ -754,21 +754,21 @@ 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 a SIP-independent mechanism, such as + Another alternative is to use 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 @@ -851,40 +851,40 @@ See Appendix A for examples of existing legacy INFO usages. 10. Info Package Requirements 10.1. General This section provides guidance on how to define an Info Package, and what information needs to exist in an Info Package specification. If, for an Info Package, there is a need to extend or modify the - behavior described in this document, that behaviour MUST be described + behavior described in this document, that behavior 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 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 there is a need for transporting application information. -10.2. Overal Description +10.2. Overall Description 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. @@ -979,21 +979,21 @@ As the SIP stack might not be aware of Info Package specific restrictions, it cannot be assumed that overlapping requests would be rejected. As defined in Section 3.2.2, UAs will normally send a 200 (OK) response to an INFO request. The application logic associated with the Info Package needs to handle situations where UAs do not follow restrictions associated with the Info Package. 10.9. Rate of INFO Requests - If there is a maximum or minumum rate at which UAs can send INFO + If there is a maximum or minimum rate at which UAs can send INFO requests associated with the Info Package within a dialog, the Info Package specification MUST document the rate values. If the rates can vary, the Info Package specification MAY define Info Package parameters that UAs can use to indicate or negotiate the rates. Alternatively the rate information can be part of the application data information associated with the Info Package. 10.10. Info Package Security Considerations @@ -1018,21 +1018,21 @@ 10.11. Implementation Details It is strongly RECOMMENDED that the Info Package specification defines the procedure how implementors shall implement and use the Info Package, or refer to other locations where implementors can find that information. NOTE: Sometimes Info Package designer might choose to not reveal the details of an Info Package. However, in order to allow multiple implementations to support the Info Package, Info Package designers - are stronly encouraged to provide the implementation details. + are strongly encouraged to provide the implementation details. 10.12. Examples It is RECOMMENDED that the Info Package specification provides demonstrative message flow diagrams, paired with complete messages and message descriptions. Note that example flows are by definition informative, and do not replace normative text. @@ -1045,48 +1045,56 @@ states: Method: INFO Reference: [RFC2976] to: Method: INFO Reference: [RFCXXXX] -11.2. Registration of the Info-Package Header Field +11.2. Registration of the Info-Package header field Please add the following new SIP header field in the Header Fields subregistry under the SIP Parameters registry. Header Name: Info-Package Compact Form: (none) Reference: [RFCXXXX] -11.3. Registration of the Recv-Info Header Field +11.3. Registration of the Recv-Info header field Please add the following new SIP header field in the Header Fields subregistry under the SIP Parameters registry. Header Name: Recv-Info Compact Form: (none) Reference: [RFCXXXX] 11.4. Creation of the Info Packages Registry Please create a subregistry in the SIP Parameters registry for Info Packages. - The registration policy for the registry is Specification Required - [RFC5226]. + Note to the reviewer: - The reviewer does not consider the applicability of the Info Package - for the usage for which it is defined. + The policy for review of Info Packages is "Specification Required", + as defined in [RFC5226]. This policy was selected because Info + Packages re-use an existing mechanism for transport of arbitrary + session-associated data within SIP, and therefore new Info Packages + do not require the more extensive review required by specifications + that make fundamental protocol changes. However, the reviewer is + expected to verify that each Info Package registration is in fact + consistent with this definition. Changes to the SIP protocol and + state machine are outside of the allowable scope for an Info Package + and are governed by other procedures including + [I-D.peterson-rai-rfc3427bis] and its successors, if any. The following data elements populate the Info Package Registry. o Info Package Name: The Info Package Name is a case insensitive token. In addition, IANA shall not register multiple Info Package names that have identical case-insensitive values. o Reference: A reference to a specification which describes the Info Package. The initial population of this table shall be: @@ -1464,23 +1472,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] - Oshry, M., Rehor, K., Bodell, M., Burke, D., Auburn, R., - Baggia, P., McGlashan, S., Candell, E., Burnett, D., - Carter, J., Lee, A., and B. Porter, "Voice Extensible + Candell, E., Burnett, D., Carter, J., Auburn, R., + McGlashan, S., Lee, A., Porter, B., Oshry, M., Rehor, K., + Bodell, M., Burke, D., and P. Baggia, "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. @@ -1561,37 +1569,42 @@ 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-05 + o Further changes based on WGLC comments + o Editorial changes + o IANA registry procedures clarified + Changes from draft-ietf-sipcore-info-events-04 o Further changes based on WGLC comments o OPTIONS processing removed o Clarification of Recv-Info header field in INFO 469 response added o IANA registry procedures clarified 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 alignment 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- + o Clarification 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 o Recv-Info fallback rules added o Additional examples added Changes from draft-ietf-sipcore-info-events-01 o Further changes based on WGLC comments o Appending A moved into the main part of the document o Section name changed from "Modifications to SIP Change Process" to @@ -1607,26 +1620,26 @@ o Text about legacy INFO and subscription-based events moved from the Introduction to the main part of the document o Wording about receiving Info-Packages has been replaced with wording about receiving INFO requests for Info-Packages o The text about the usage of message body, and body parts, associated with Info Packages, has been clarified Changes from draft-ietf-sip-info-events-04 o Major re-write of the document, due to problems to implement WGLC comments into the existing text structure - o Wording allignment + o Wording alignment o Clarification or roles Changes from draft-ietf-sip-info-events-03 o Clarified Abstract language - o All SIP dialogs are now refered to as sessions + o All SIP dialogs are now referred to as sessions o Clarified the image example in the Introduction o Clarified the relationship (none) between SIP Event Packages and SIP Info Packages o Really, really clarified the protocol is NOT a negotiation but an advertisement o Split Section 3 into UAS and UAC behavior o Moved the example in section 3 into its own sub-section, and used full SIP header fields o Clarified forking behavior o Clarified language around when to send a body