SIPCORE E. Burger Internet-Draft NeuStar, Inc. Obsoletes: RFC 2976 H. Kaplan (if approved) Acme Packet Expires:April 26,June 5, 2010 C. Holmberg EricssonOctober 23,December 2, 2009 Session Initiation Protocol (SIP) INFO Method and Package Frameworkdraft-ietf-sipcore-info-events-02draft-ietf-sipcore-info-events-03 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. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terminology in this document conforms to the Internet Security Glossary [RFC4949]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 onApril 26,June 5, 2010. Copyright Notice Copyright (c) 2009 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 thisdocument (http://trustee.ietf.org/license-info).document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.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 theCode Components extracted from this documentalso specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred tomust include Simplified BSD License text as"legacy INFO Usage" in this document. Conventions Useddescribed inthis Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"Section 4.e of the Trust Legal Provisions and"OPTIONAL" in this documentareto be interpretedprovided without warranty as described inRFC 2119 [RFC2119]. The terminology in this document conforms totheInternet Security Glossary [RFC4949].BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 3.Info Package SupportThe INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.User Agent Behavior . .INFO Request . . . . . . . . . . . . . . . . .6 3.3. Package Versioning. . . . . 6 3.2.1. INFO Request Sender . . . . . . . . . . . . . .7 3.4. REGISTER Processing. . . 6 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 73.5. OPTIONS Processing3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 84. The3.3.1. INFOMethodRequest Message Body . . . . . . . . . . . . . . 8 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . .89 4.2.INFO RequestUser Agent Behavior . . . . . . . . . . . . . . . . . . . 9 4.2.1. General . . . . . . .8 4.3. INFO Request Message Body. . . . . . . . . . . . . . . . 94.4. INFO Response4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 4.2.3. Recv-Info header field rules . . . . .10 4.5. INFO Response Message Body. . . . . . . . 11 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 114.6. Order of Delivery4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 4.4. OPTIONS Processing .11. . . . . . . . . . . . . . . . . . 12 5. Formal INFO Method Definition . . . . . . . . . . . . . . . .1112 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . .1112 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . .1314 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . .1314 6.2. Info-Package header field . . . . . . . . . . . . . . . .1314 6.3. Recv-Info header field . . . . . . . . . . . . . . . . .1415 7. Info Package Considerations . . . . . . . . . . . . . . . . .1415 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . .1415 7.2. Appropriateness of Info Package Usage . . . . . . . . . .1415 7.3.Dialog Fate Sharing . . . . . . . . . . . . . . . . . . . 14 7.4.INFO Request Rate and Volume . . . . . . . . . . . . . .14 7.5.15 7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . .15 7.5.1.16 7.4.1. Alternative SIP signaling plane mechanisms . . . . . .15 7.5.2.16 7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . .16 7.5.3.17 7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . .1718 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . .1718 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . .1718 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . .1718 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 9.3. Co-existence with Info Package based INFO usage . . . . .1819 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Overal Description . . . . . . . . . . . . . . . . . . . 20 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . .19 10.3.20 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . .19 10.4.20 10.5. Info Package Parameters . . . . . . . . . . . . . . . . .20 10.5.21 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . .20 10.6.21 10.7. INFO MessageBodies . .Body Parts . . . . . . . . . . . . . . . . .20 10.7.21 10.8. Info Package Usage Restrictions . . . . . . . . . . . . .20 10.8.22 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . .21 10.9. IANA Registrations . . . . . . . . . . . . . . . . . . . 2122 10.10. Info Package Security Considerations . . . . . . . . . .2122 10.11.Application ProceduresImplementation Details . . . . . . . . . . . . . . . . .2223 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . .2223 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .2223 11.1. Update to Registration of SIP INFO Method . . . . . . . .2223 11.2. Registration of the Info-Package Header Field . . . . . .2224 11.3. Registration of the Recv-Info Header Field . . . . . . .2324 11.4. Creation of the Info Packages Registry . . . . . . . . .2324 11.5. Registration of the Info-Package Content-Disposition . .2425 11.6. SIP Response Code 469 Registration . . . . . . . . . . .2425 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .2425 12.1. Indicationoffor which Info Packages UAs are willing to receive INFO requestswithin an invite dialog usage. . .24. . . . . . . . . . . . . . . 25 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 12.2. INFO requestwith informationassociated witha simpleInfo Package . . . . . . . . 27 12.2.1. Single payload . . . . . . . . . . .25 12.3.. . . . . . . . . 27 12.2.2. Multipart INFOExample. . . . . . . . . . . . . . . . .25. . . 27 13. Security Considerations . . . . . . . . . . . . . . . . . . .2630 14. References . . . . . . . . . . . . . . . . . . . . . . . . . .2731 14.1. Normative References . . . . . . . . . . . . . . . . . .2731 14.2. Informative References . . . . . . . . . . . . . . . . .2831 Appendix A. Legacy INFOUsagesUsage . . . . . . . . . . . . . . . . .30. 34 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . .3034 A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . .3034 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . .3034 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . .3034 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . .3134 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . .3134 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . .3134 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . .3135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .3337 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 SIP session to exchange information (whichmaymight update the state of those applications). Use of the INFO method does not constitute a separate dialog usage. INFO messages are always part of, and share the fate of, an invite dialog usage [RFC5057]. INFO messages cannot be sent as part of other dialog usages, or outside an existing dialog. This document also defines an Info Package mechanism. An Info Package specification defines the content and semantics of the information carried in an INFO message associated with the Info Package. The Info Package mechanism also provides a way for UAs to indicate for which Info Packages they are willing to receive INFOrequests. The document defines how therequests, and which Info Package a specific INFOmethodrequest isused, new SIP header fields forassociated with. A UA uses theINFO method, and howRecv-Info header field, on a per-dialog basis, totransport payload information associated with anindicate for which InfoPackage usingPackages it is willing to receive INFO requests.Use of the INFO method does not constitute a separate dialog usage. INFO messages are always part of, and share the fate of, an invite dialog usage [RFC5057]. INFO messages cannot be sent as part of other dialog usages. A UA uses the Recv-Info header field, on a per-dialog basis, to indicate for which Info Packages it is willing to receive INFO requests. A UA can indicate an initial setA UA can indicate an initial set of Info Packages during dialog establishment and can indicate a new set during the lifetime of the invite dialog usage. NOTE: A UA can usethean empty Recv-Info header fieldwith(a header field without a'nil' valuevalue) 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.Info Package SupportThe INFO Method 3.1. GeneralThis section describes howThe INFO method provides a mechanism for transporting application level information that can further enhance a SIPUAs indicateapplication. Annex A gives more details on the types of applications for whichInfo Packages they are willing to receivethe use of INFOrequests. 3.2. User Agent Behavior Ais appropriate. This section describes how a UAwhich supportshandles 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 Packagemechanism MUST indicate, using(see X), or associated with a legacy INFO usage (see Y). The construction of theRevc-Info header field,INFO request is theset ofsame as any other request within an existing invite dialog usage. A UA can send INFO requests both within early and confirmed dialogs. When a UA sends an INFO request associated with an InfoPackages for whichPackage, it MUST include an Info-Package header field that indicates which Info Package iswilling to receive INFOassociated with the request. AUAspecific INFO request canlist multiple Info Packages inbe used only for a singleRecv-Info header field, and the UA can use multiple Recv-Info header fields. The indication of Info Packages can take place during the dialog establishment, and during a target refresh. This includes INVITE, UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx only). Note that the UAC is not required to indicate its set ofInfoPackages in the initial INVITE request. IfPackage. When a UAis not willing tosends an INFOrequests for anyrequest associated with an legacy INFO usage there is no InfoPackages, during dialog establishment or later duringPackage associated with theinvite dialog usage,request, and the UA MUSTindicate this by including a Recv-InfoNOT include an Info-Package header fieldwith a 'nil' value. This informs other UAs that the UA still supports the Info Package mechanism. Example: If a UA has previously indicated Info Packages 'foo' and 'bar', and the UA during the lifetime ofin theinvite dialog usage wants to indicate that it does not want to receiverequest. The INFOrequests for any Info Packages anymore, the UA sends a target refreshrequestwithMUST NOT contain a Recv-Info headerfield withfield. A UA can only indicate aheader valueset of'nil'. Once a UA has indicated thatInfo Packages for which it is willing to receive INFO requestsfor a specific Info Package, and a dialog has been established,by using theUA MUST be prepared to receive INFO request associated with that Info Package.SIP methods (and their responses) listed in Section 4. A UA MUST NOTsend anuse the INFOrequest associated withmethod outside an invite dialog usage. UAs indicate, per-dialog basis, for which InfoPackage until it has received an indication that the remote UA isPackages they are willing to receive INFOrequests for thatrequests. The set of InfoPackage, and a dialog has been established with the remote UA.Packages cannot automatically be used within other dialogs. If a UAindicates multiple Info Packages, which provide similar functionality, it is not possiblereceives a 469 (Bad INFO Package) response toindicatean INFO request, based on [RFC5057] the response represents apriority orderTransaction Only failure, and the UA MUST NOT terminate the invite dialog usage. Due to the possibility of forking, theInfo Packages, or that thatUA 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 UAwishesMUST be prepared toonlyreceive different Recv-Info header field values from different remote UAs. NOTE: If the UAS (receiver of the initial INVITE request) sends an INFO requestfor one ofjust after it has sent theInfo Packages. It is upresponse which creates the dialog, the UAS needs to be prepared that theapplication logic associated withINFO request can reach theInfo Packages,UAC before the dialog creating response, andspecific Info Package descriptionsmight therefore be rejected by the UAC. In addition, an INFO request might be rejected due todescribe application behavior in such cases. For backward compatibility purpose, evena race condition, if a UAindicates support ofsends the INFO request at the same time as the remote UA sends a new set of InfoPackage mechanism,Packages for which it isstill allowedwilling toenable legacyreceive INFOusages Section 9. This document does not definerequests. 3.2.2. INFO Request Receiver If aSIP option tag [RFC3261] for the Info Package mechanism. However, an Info Package specification can defineUA receives anoption-tagINFO request associated withthe specific Info Package, as described in Section 10.5. For backward compatibility, if a UA indicates support of the INFO method using the Allow header field [RFC3261], it does not implicitly indicate support of thean Info Packagemechanism. A UA MUST use the Recv-Info header field in order to indicatethatit supportstheInfo Package mechanism. Likewise, even if aUAuses the Recv-Info header fieldhas not indicated willingness toindicate that it supports the Info Package mechanism, in additionreceive, the UA MUSTstill also explicitly indicate support of thesend a 469 (Bad INFOmethod usingPackage) response (see Section 11.6). In theAllow header field. 3.3. Package Versioning The Info Package mechanismterminology of Multiple Dialog Usages [RFC5057], this represents a Transaction Only failure, and does notsupport package versioning. Specific Info Package payloads MAY contain version information, which is handled byterminate theapplicationsinvite dialog usage. If a UA receives an INFO request associated withthean Info Package,but that is outsideand thescope ofmessage body part associated with the Info Packagemechanism. NOTE: Even if an Info Package namecontainsversion numbering (e.g. foo_v2), the Info Package mechanism does not distinguishaversion number from the rest ofmessage body MIME type that theInfo Package name. 3.4. REGISTER Processing This document allows a UA to insert a Recv-Info header field in a REGISTER request. However, aUASHALL NOT include a header valuesupport, but which usage is not defined fora specific Info Package unlessthe specific InfoPackage specification describes howPackage, it is RECOMMENDED that theheader field value shall be interpretedUA sends a 415 (Unsupported Media Type) response. The UA MAY send other error responses, such as Request Failure (4xx), Server Failure (5xx) andused byGlobal Failure (6xx), in accordance with theregistrar, e.g.error handling procedures inorder to determine request targets. NOTE: Rather than using[RFC3261]. Otherwise, if theRecv-Info header field in order to determineINFO requesttargets, itisrecommended to use more appropriate mechanisms, e.g. based on [RFC3840]. 3.5. OPTIONS Processing If asyntactically correct and well structured, the UAsends an OPTIONS request, orMUST send aresponse,200 (OK) response. NOTE: If theUA SHALL include Recv-Info header fieldapplication needs to reject the information which it received in an INFO request, that needs to be done on themessage, and listapplication level. Ie theInfo Packages that it supportsapplication needs toreceive. NOTE: As for any other capability and extension, fortrigger aspecific dialog UAs need to indicatenew INFO request, which contains information that the previously received application data was not accepted. Individual InfoPackages they are willingPackage specifications need toreceive within that dialog. 4. The INFO Method 4.1. General This section describesdescribe theUA handling ofdetails for such procedures. 3.3. INFOrequests and responses, and message bodies carried inMessage Body 3.3.1. INFOmessages.Request Message Body The purpose of the INFOmethod provides additional,request is to carry application level informationthat can further enhance abetween SIPapplication. Annex A gives more details onUAs. The application information data is carried in thetypespayload ofapplication for whichtheusagemessage body of the INFOis seen as appropriate. 4.2. INFO Request When a UA sends anrequest. NOTE: An INFO requestassociatedassocated with an InfoPackage, it MUST include an Info-Package header field that indicates which InfoPackageiscan also include information associated with therequest. A specificInfo Package using Info-Package header field parameters. If an INFO requestcan be used only for a singleassociated with an InfoPackage. ForPackage contains aspecific dialog,message body part, the body part is identified by aUA MUST NOT send INFO requestsContent-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 InfoPackagesPackage. UAs MUST conform to [RFC5621] to support multipart body parts. NOTE: Some SIP functions that are orthogonal to INFO can insert body parts unrelated to theremoteInfo Package. When a UAhas not indicatedsupports a specific Info-Package, the UA also support all message body MIME types associated with thatit is willing to receive.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 UAcan sendMUST NOT include a message body associated with an Info Package in an INFOrequestsresponse. Message bodies associated witha legacyInfo Packages MUST only be sent in INFOusage Section 9. In such case thererequests. A UA MAY include a message body which isno Info Packagenot associated withthe usage, and thean Info Package in an INFOrequestresponse. 3.4. Order of Delivery The Info Package mechanism does notcontain an Info-Package header field. In addition, the UA cannot usedefine a delivery order mechanism. Info Packages can rely on theRecv-InfoCSeq header field toindicate whether it is willing to receive INFO requests associated with that legacy INFO usage. The INFO method MUST NOT be used outsidedetect if aninvite dialog usage. TheINFOmethod has no lifetime beyond its transaction or usagerequest is received out ofits own. UAs indicate, per-dialog basis,order. If specific applications need additional mechanisms forwhich Info Packages theyorder of delivery, those mechanisms, and related procedures, arewilling to receive INFO requests. The setspecified as part of the associated InfoPackages cannot automaticallyPackage, and possible sequence numbers etc must beused within other dialogs. Due todefined as application data. 4. Info Packages 4.1. General An Info Package specification defines thepossibilitycontent and semantics offorking, a UAC which, duringtheearly dialog phase indicates that it is willing to receiveinformation carried in an INFOrequestsmessage associated with an Info Package. The Info Package mechanism provides a way forone or moreUAs to indicate for which Info PackagesMUST be preparedthey are willing to receive INFOrequests associated with thoserequests, and which InfoPackages from multiple remote UAs. Note that each remotePackage a specific INFO request is associated with. 4.2. User Agent Behavior 4.2.1. General This section describes how a UAcan indicatehandles Info Packages, how adifferentUA 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 whichthey areit is willing to receive INFOrequest. The construction of the INFO request is the same as any other request within an existing invite dialog usage.requests. A UA cansend INFO requests both within early and confirmed dialogs. The INFO request MUST NOT containlist multiple Info Packages in a single Recv-Info headerfield. Thefield, and the UA canonly indicateuse multiple Recv-Info header fields. A UA can 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 requestsby usingduring theSIP methods (and their responses) listed in Section 3. 4.3. INFO Request Message Body The purposedialog establishment. A UA can update the set of Info Packages during theINFO requestinvite dialog usage. If a UA is not willing tocarry application level information between SIP UAs. The application data associated with anreceive INFO requests for any InfoPackage is carried as payload inPackages, during dialog establishment or later during themessage body ofinvite dialog usage, theINFO request, using one or more body parts. Info Package specificationsUA MUSTdescribeindicate this by including an empty Recv- Info header field. This informs other UAs that theapplication level information associated withUA still supports the InfoPackage. Each body part MUST havePackage mechanism. Example: If aMIME type value,UA has previously indicated Info Packages 'foo' andthe syntax'bar' in a Recv-Info header field, andcontentthe UA during the lifetime of thebody part, defined. Each body part, when associatedinvite dialog usage wants to indicate that it does not want to receive INFO requests for any Info Packages anymore, the UA sends a message with an empty Recv-Info header field. Once a UA has sent a set of InfoPackage, MUST havePackages, the set is valid until the UA sends aContent-Disposition header field withnew set, or an'Info-Package' value assigned, in orderempty Recv-Info header field. Once a UA has indicated that it is willing to receive INFO requests for a specific Info Package, and a dialog has been established, the UA MUST beable distinguish body partsprepared to receive INFO request associated withthethat Info Packagefrom other body parts. NOTE: Some SIP functionsuntil the UA indicates thatare orthogonalit is no longer willing to receive INFOmay insert body parts unrelated to the Info Package. Body partsrequests associated withspecific MIME types may sometimes have specific Content-Disposition header field values defined for them.that Info Package. Forexample, for body parts witha'text/plain' MIMEspecific dialog usage, aContent- Disposition header fieldUA MUST NOT send an INFO request associated witha 'render' valuean Info Package until it has received an indication that the remote UA isoften assigned. However, when a body part inwilling to receive INFO requests for that Info Package, or after the UA has received an indication that the remote UA is no longer willing to receive INFOmessage isrequests associated withanthat InfoPackage, it MUST always havePackage. NOTE: When aContent-DispositionUA 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-Package' value assigned. TheINFO request based on the old set of InfoPackage specification defines how applications processPackages. In this case thebody part contents.receiver of the INFO requests rejects, and sends a 469 (Bad INFO Package) response to, the INFO request. If aSIP message body containsUA indicates multiplebody parts, multipart body parts [RFC5621] are usedInfo Packages, which provide similar functionality, it is not possible toseparate them. If all body parts withinindicate amultipart body part arepriority 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 logic associated with the InfoPackage,Packages, and specific Info Package specifications, to describe application behavior in such cases. For backward compatibility purpose, even if a UA indicates support of themultipart body part SHALL haveInfo Package mechanism, it is still allowed to enable legacy INFO usages Appendix A. In addition, if aContent-DispositionUA indicates support of the INFO method using the Allow header fieldwith an 'Info-Package' value assigned to it. However, each body part within[RFC3261], it does not implicitly indicate support of themultipart body partInfo Package mechanism. A UA MUSTstill have a Content-Dispositionuse the Recv-Info header fieldwith an 'Info-Package' value assigned to them,in order toavoidindicate that it supports theparser assigns a default Content-Disposition header value to the body part. NOTE: According to [RFC5621], body parts withinInfo Package mechanism. Likewise, even if amultipart are not implicitly assignedUA uses theContent-DispositionRecv- Info header fieldvalueto indicate that it supports the Info Package mechanism, in addition the UA still indicates support of themultipart body part which they belong to.INFO method using the Allow header. This document does not define a SIP option tag [RFC3261] for the Info Packagespecific rules on how body parts associated with Info Packages are to be inserted into multipart body parts, and what type of multiparts are used. Ifmechanism. However, an Info Packagerequires special rules regarding the usage of multipart body parts, thespecificationfor thatcan define an option-tag associated with the specific InfoPackage MUST specify such rules. UAs MUST conform to [RFC5621] to support multipart body parts. IfPackage, as described in Section 10.6. 4.2.3. Recv-Info header field rules The text below defines rules on when a UAindicates that itiswillingrequired toreceiveinclude aspecific Info Package, the UA naturally also supports any associated message body part MIME type associated with the Info Package. However,Recv-Info header field inadditionSIP messages. Section 6.1 lists the SIP methods, for which a UAMUST still indicate support of those MIME types in the Acceptcan insert a Recv-Info headerfield, according to the proceduresfield in[RFC3261]. NOTE: To avoid corner cases with legacy INFO usage, the Info-Packagerequests 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 isusednot willing toindicate thereceive INFO requests asscoiated with any InfoPackage name, rather than to usePackage. - The receiver of aContent-Dispositionrequest which contains a Recv-Info header field MUST include a Recv-Info header fieldparameterinordera reliable 18x/2xx response toindicatethename. 4.4. INFO Response If a UA receives an INFOrequest,associated with an Info-Package that the UA has indicated willingness to receive, andeven if theINFOrequest containsdata associated with that Info-Package,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 MUSTsendNOT include a200 OK response. IfRecv-Info header field in aUA receives an INFO request for legacy usage, for which no Info- Package isresponse if the associated(the INFOrequestdoesdid not containan Info- Packagea Recv-Info headerfield),field. NOTE: Different from theUA MUST send a 200 OK response. The UAS MAY send other responses, such as Request Failure (4xx), Server Failure (5xx) and Global Failure (6xx) as appropriaterules for generating SDP answers, therequest. Ifreceiver of aUA receives an INFOrequestassociated with anwhich contains a set of InfoPackage that the UA hasPackages is notindicated willingnessrestricted toreceive, the UA MUST sendgenerate its own set of Info Packages as a469 Bad INFOsubset of the Info Packageresponse Section 11.6. Inset received in theterminologyInfo Package header field ofMultiple Dialog Usages [RFC5057], this representsthe request. NOTE: Similar to SDP answers, the receiver can include the same Recv- Info header field value in multiple responses (18x/2xx) for the same INVITE/re-INVITE transaction, but the receiver is not allowed to include aTransaction Only failure. IfRecv-Info header field value which is different from aUA receives an INFO requestvalue thatdoes not match any existing invite dialog usage,theUA MUST sendreceiver has already included in a481 Call Leg/Transaction Does Not Exist response.response for the same transaction. 4.2.4. Info Package fallback rules If the receiver of aUA receives an INFOrequestthat carrieswhich contains amessage body thatRecv-Info header field rejects theUA does not support,request, both the sender andsupportreceiver of themessage body is required in the Content-Disposition header field, the UArequest MUSTsend a 415 Unsupported Media Type response. If supportroll back to the set of Info Packages which was used before themessage body is optional,request was sent. This also applies to theUA MUST send a 200 OK response even ifcase where theUA does not supportreceiver of an INVITE/re-INVITE request has included a Recv-Info header field in a provisional response, but later rejects themessage body. 4.5. INFO Response Message Bodyrequest. NOTE: The dialog state rollback rules for InfoPackage mechanismPackages might differ from the rules for other types of dialog state information (SDP, target, etc). 4.3. REGISTER Processing This document allows aSIP stackUA togenerateinsert aresponse to an INFO request without application interaction. AsRecv-Info header field in aresult, Info Packages cannot requireREGISTER request. However, amessage body in INFO responses, require different response codes, or otherwise requireUA SHALL NOT include a header value for a specific Info Package unless theresponse tospecific Info Package specification describes how theINFO request to contain application information. Ifheader field value shall be interpreted and used by theapplication needs to send informationregistrar, e.g. inthe other direction, it can send a new INFOorder to determine requestwhich containstargets. Rather than using the Recv-Info header field in order to determine request targets, it is recommended to use more appropriate mechanisms, e.g. based on [RFC3840]. However, this document does not define a feature tag for theinformation. 4.6. Order of Delivery TheInfo Package mechanism, or a mechanismrelies onto define feature tags for specific Info Packages. 4.4. OPTIONS Processing If a UA sends an OPTIONS request, or a response, theCSeqUA SHALL include Recv-Info header fieldto detect if an INFO request is received out of order. If specific applications need additional mechanisms for order of delivery, those mechanisms,in the message, andrelated procedures, must be specified as part oflist theassociatedInfoPackage,Packages that it supports to receive. NOTE: As for any other capability andpossible sequence numbers etc must be defined as application data.extension, for a specific dialog UAs need to indicate which Info Packages they are willing to receive within that dialog. 5. Formal INFO Method Definition 5.1. INFO Method This document describes one new SIP method: INFO. This document replaces the definition and registrations found in [RFC2976]. This table expands on Tables 2 and 3 in [RFC3261]. Header Where INFO ------ ----- ---- Accept R o Accept 415 o Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx o Accept-Language 415co Accept-Resource-Priority 2xx,417 o Alert-Info - Allow R o Allow200 - Allow405 m Allow r o Authentication-Info 2xx o Authorization R o Call-ID c m Call-Info o Contact - Content-Disposition o Content-Encoding o Content-Language o Content-Length o Content-Type * CSeq c m Date o Error-Info 3xx-6xx o Expires - From c m Geolocation R o Geolocation-Error r o Max-Breadth R - Max-Forwards R o MIME-Version o Min-Expires - Organizationo- Priority R - PrivacyRo Proxy-Authenticate 401 m Proxy-Authenticate 407 o Proxy-Authorization R o Proxy-Require R o ReasonrR 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 - Retry-After404,480,486404,413,480,486 o Retry-After503500,503 o Retry-After 600,603 o Route R o Security-Client R o Security-Server 421,494 o Security-Verify R o Server r o Subject R o Supported R o Supported 2xx o Timestamp o To c m (w/ Tag) Unsupported 420 o User-Agent o Via m Warning r o WWW-Authenticate 401 m 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 Ro- -o o- m m o o - - o - - - Recv-Info 2xxo --o o-o- o** m -oo***- - o***- - - Recv-Info 1xxo- -o o-oo** - - - - - -o- - - Recv-Info ro- - - o o - o - - o - - -*The support and usage of the Info-Package and Recv-Info headerfieldfields isMANDATORY fornot applicalbe to UAs that only support legacy INFO usages. * Not applicalbe to INFO requests and responses associated withInfo Packages. The Info-Package header field is not applicable forlegacyusageINFOrequests [RFC2976].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 6.2. Info-Package header field This document adds Info-Package to the definition of the element "message-header" in the SIP message grammar [RFC3261]. Section43 describes the Info-Package header field usage. For the purposes of matching Info Package types indicated in Recv- Info with those in the Info-Package header field value, one compares the Info-package-name portion of the Info-package-type portion of the Info-Package header field octet-by-octet with that of the Recv-Info header field value. That is, the Info Package name is case sensitive. Info-package-param is not part of the comparison-checking algorithm. This document does not define values for Info-Package types. Individual Info Package specifications definethese values. Such specifications MUST register the values with IANA. These values are Specification Required [RFC5226].these values. 6.3. Recv-Info header field This document adds Recv-Info to the definition of the element "message-header" in the SIP message grammar [RFC3261]. Section34 describes the Recv-Info header field usage. 7. Info Package Considerations 7.1. General This section covers considerations to take into account when deciding whether the usage of an Info Package is appropriate for transporting of application information for a specific use-case. 7.2. Appropriateness of Info Package Usage When designing an Info Package, for application level information exchange, it is important to consider: is signaling, using INFO requests, within a SIP dialog, an appropriate mechanism for the use- case? Is it because it is the most reasonable and appropriate choice, or merely because "it's easy"? Choosing an inappropriate mechanism for a specific use-case can cause negative effects in SIP networks where the mechanism is used. 7.3.Dialog Fate Sharing As described in [RFC5057], an INFO request is always part of an INVITE dialog usage. One needs to consider the fate of the dialog usage of an INFO request is rejected. In some cases it may be acceptable that the whole dialog usage is terminated, while in other cases is is desirable to maintain the dialog usage. 7.4.INFO Request Rate and Volume There is no default throttling mechanism for INFO requests. Apart from the SIP session establishment, the number of SIP messages exchanged during the lifetime a normal SIP session is rather small. 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 plane data transport mechanisms.7.5.7.4. Alternative Mechanisms7.5.1.7.4.1. Alternative SIP signaling plane mechanisms7.5.1.1.7.4.1.1. General This subsection describes some alternative mechanisms for transporting application information on the SIP signaling plane, using SIP messages.7.5.1.2.7.4.1.2. SUBSCRIBE/NOTIFY An alternative for application level interaction is to use subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and NOTIFY methods. Using that mechanism, auser agentUA requests state information, such as key pad presses from a device to an application server or key map images from an application server to a device. Event Packages [RFC3265] perform the role of disambiguating the context of a message for subscription-based events. The Info Package mechanism provides similar functionality for application information exchange using invite dialog usages [RFC5057]. While an INFO request is always part of, and shares the fate of, an existing invite dialog usage, a SUBSCRIBE request creates anew session and a subscriptionseparate dialog usage[RFC5057] which is separate,[RFC5057], anddoes not share the fate any other sessions.is normally sent outside an existing dialog usage. The subscription-based mechanism can be used by SIP entities to receive state information about SIP dialogs and sessions, without requiring the entities to be part of the route set of those dialogs and sessions. As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies and B2BUAs, the resource impact caused by the subscriptionsessionsdialogs needs to be considered. The number of subscriptionsessionsdialogs per user also needs to be considered. As for any other SIP signaling plane based mechanism for transporting application information, the SUBSCRIBE/NOTIFY messages can put a significant burden on intermediate SIP entities which are part of the dialog route set, but do not have any interest in the application information transported between the end users.7.5.1.3.7.4.1.3. MESSAGE The MESSAGE method [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for rendering to the ser.7.5.2.7.4.2. Media Plane Mechanisms7.5.2.1.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. 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.5.2.2.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.5.2.3.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.5.3.7.4.3. Non-SIP related mechanisms Another alternative is to use a totally externally signaled channel, such as HTTP [RFC2616]. In this model, theuser agentUA 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 ThisSectionsection 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. 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" HCOLONInfo-package-list[Info-package-list] Info-package-list ="nil" /Info-package-type *( COMMA Info-package-type ) Info-package-type = Info-package-name *(";"SEMI Info-package-param) Info-package-name = token Info-package-param = generic-paramNOTE on the Recv-Info production: if the header field value is "nil", the header field MUST NOT contain any other Info Packages, and the SIP message MUST NOT contain more than one Recv-Info header field.9. Legacy INFO Usage 9.1. General A number of applications, standardized and proprietary, make use of the INFO method as it was previously defined in [RFC2976], referred to as "legacy INFO usage". For backward compatibility purpose, this document does not deprecate such usages, and does not mandate users to define Info Packages for such usages. However, any new usage of INFO SHALL use the Info Package mechanism defined in this specification. 9.2. Problems While legacy INFO usage has been widely adopted for specific application use cases, [RFC2976] did not define a mechanism for SIP UAs to indicate for which types of applications and contexts they support the INFO method. In addition, [RFC2976] did not provide a mechanism to explicitly indicate the type of application and context for which a specific INFO message is associated. Example: If the Content-Type is "image/jpeg", the MIME-attached content is a JPEG image. Still, there are many useful ways a UA can render an image. The image could be a caller-id picture, a contact icon, a photo for sharing, and so on. The sender does not know which image to send to the receiver if the receiver supports an image content type. Likewise, the receiver does not know the context of an image the client is sending if the receiver supports receiving more than one image content type. Since legacy INFO usages do not have associated Info Packages, it is not possible to use the Recv-Info and Info-Package header fields with legacy INFO usages. That is, a UA cannot use the Recv-Info header field to indicate for which legacy INFO usages it is willing to receive INFO requests, and a UA cannot use the Info-Package header field to indicate for which legacy INFO usage an INFO request is associated with. Due to the problems described above, legacy INFO usages often require static configuration about for what type of applications and contexts UAs support the INFO method, and the way they handle application information transported in INFO messages. That has caused interoperability problems in the industry. Therefore, a need for a well defined and documented description of what the information sent in the INFO is used for has been identified. This situation is analogous to the context issue in Internet Mail [RFC3458]. 9.3. Co-existence with Info Package based INFO usage As described in Section4,3, an INFO request associated with an Info Package always contains an Info-Package header field. Alegacy INFO requestUA MUST NOTcontaininsert an Info-Package headerfield.field in a legacy INFO request. UAs are allowed to enable both legacy INFO usages and Info Package usages as part of the same invite dialog usage. See Appendix A for examples of existing legacy INFO usages. 10. Info Package Requirements 10.1. General ThisSectionsection provides guidance on how to define an Info Package, and what information needs tobe provided. Ifexist in an Info Packageextendsspecification. If, for an Info Package, there is a need to extend ormodifiesmodify the behavior described in this document,itthat behaviour MUST be described in thedefinition for thatInfoPackage.Package specification. It is bad practice for Info Packagedefinitions should notspecifications to repeat procedures defined in thisspecification,document, unless needed for clarification or emphasis purpose. InfoPackagesPackage 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 applicationsassociated withassociated with the Info Package requires 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. 10.2. Overal Description The Info Package specification MUST contain an overlap 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 InfoPackage requires it.Package. If the Info Packagedefinitions SHALL address the issues defined in the following subsections, or document why an issueisnot applicabledefined forthea specific application, the InfoPackage. 10.2.Package specification MUST state which application UAs can use the Info Package with. 10.3. Applicability The Info Package specification MUST describe why the Info Package mechanism, rather than some other mechanism, has been chosen for the specific use-case to transfer application information between SIP endpoints. Common reasons can be a requirement for SIP Proxies or back-to-backUser Agentsuser agents (B2BUAs) to see the transported application information (which would not be the case if the information was 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.3.10.4. Info Package Name The Info Package specification MUST definea foran Info Packagename (e.g. "Info Package for X"). The specification MUST also define thename, which UAs use as a header field value (e.g. "infoX") to beused to indicate support of this package inidentify theRecv-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. Thespecification MUST also includeInfo Package mechanism does not support package versioning. Specific Info Package message body payloads can contain version information, which is handled by theinformation that appears inapplications associated with theIANA registrationInfo Package. However, such feature is outside the scope of thetoken. For information on registering such types, seegeneric 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. The IANA registration requirements for Info Package names are defined in Section9. 10.4.10.5. 10.5. Info Package Parameters The Info Package specification MAY define Info Packageparametersparameters, which can be used in the Recv-Info or Info-Package header fields, together with the header field valuerepresentingwhich indicates the InfoPackage.Package name (see Section 10.4. The Info Package specification MUSTdescribedefine the syntax and semantics of the defined parameters.ItIn addition, the specification MUSTbe specifieddefine whether a specific parameter is only applicable to theRecv-Info header,Recv- Info header field, the Info-Packageheader,header field, or both.Note thatBy default, an Info Packageparameters areparameter is only applicable for the InfoPackage(s)Package for whichthey havethe parameter has been explicitly defined.They MUST NOT be used for other Info Packages.NOTE: Info Package parameters defined for specific Info Packagesmaycan share the name with parameters defined for other Info Packages, but the parameter semantics are specific to the Info Package for which they are defined.10.5.10.6. SIP Option Tags The Info Package specification MAY define SIP option tags, which can be used as described in [RFC3261].SIPThe registration requirements for option tagsMUST conform to the SIP Change Processare defined in [I-D.peterson-rai-rfc3427bis].10.6.10.7. INFO MessageBodiesBody Parts The Info Package specification MUST definewhat type ofwhich message bodypartspart MIME types are associated with the InfoPackage, andPackage. The specification MUSTrefer to specifications whereeither define those body parts, which include the syntax, semantics and MIME type of themessageeach bodyparts are described.part, or refer to other documents which define the body parts. If multiple message bodypartspart MIME types areusedassociated with an Info Package, the Info Package specification MUST define whetherthere are special rules on how the body parts areUAs need tobe inserted inuse multipart bodyparts, and what types of multipartparts in order touse. 10.7.include multiple body parts in a single INFO request. 10.8. Info Package Usage RestrictionsTheIf there are restrictions on how UAs can use an Info Package, the Info Package specification MUSTdefinedocument such restrictions. There can be restrictions related to whethera UA isUAs are allowed to send overlapping (outstanding) INFO requests associated with the Info Package, or whether the UA has to wait for the response for a previous INFO request associated with the same Info Package.The specification MUST define whether there are SIP levelThere can also be restrictionsin the usage of the Info Package. For example, an Info Package may requirerelated to whether UAs need to supportofand use other SIP extensions(e.g. reliable provisional responses). The specification MUST define whetherand capabilities when they use the Info Package, and if there are restrictionson indicating support of, or using,related to how UAs can use theInfo PackageInfo-Package together with other Info Packages. As the SIP stackmaymight not be aware of Info Package specific restrictions, it cannot be assumed that overlapping requests would be rejected. As defined in Section4.4, in most cases3.2.2, UAs will normally send a 200OK(OK) responsewill be sent for theto an INFO request. The application logic associated with the Info Package needs to handle situationswhich can occur due to overlapping requests. 10.8.where UAs do not follow restrictions associated with the Info Package. 10.9. Rate of INFO RequestsThe Info Package specification MUST specifyIf there is a maximum or minumum rate at which UAs can send INFO requests associated with thespecificInfo Packagecan be generated by a UA inwithin adialog. Thedialog, the Info Package specification MUST document the rate values. If the rates can vary, the Info Package specification MAY define Info Package parametersto be used for indicatingthat UAs can use to indicate ornegotiatingnegotiate theINFO request rate.rates. Alternatively the rate information can beincluded inpart of the application data information associated with the Info Package.10.9. IANA Registrations The Info Package specification MUST contain an IANA Considerations section that includes definitions for the Info Package Name and, if needed, supported MIME types.10.10. Info Package Security Considerations If the application information carried in INFO requests associated with the Info Package requires certain level of security, the Info Package specification MUST describe the mechanisms that UAs need tobe useduse in order to provide the required security.Otherwise, even if noIf the Info Package specification does not require any additionalsecuritysecurity, other than whatis provided forthe underlying SIP protocolis needed, this fact SHALLprovides, it MUST be stated in the Info Package specification. NOTE: In some cases, it may not be sufficient to mandate TLS in order to secure the Info Package payload, since intermediaries will have access to the payload, and beyond the first hop, there is no way to assure subsequent hops will not forwards the payload in clear text. The best way to ensure secure transport at the application level is to have the security at the application level. One way of achieving this is to use end-to-end security techniques such as S/MIME [RFC3851]. 10.11.Application Procedures TheImplementation Details It is strongly RECOMMENDED that the Info Package specificationSHOULD contain a description ofdefines theapplication procedures associated withprocedure how implementors shall implement and use the Info Package, oralternativelyrefer toapplication procedures defined elsewhere.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. 10.12. Examples It isrecommendedRECOMMENDED that the Info Packagespecifications includespecification provides demonstrative message flow diagrams, paired with complete messages and message descriptions. Note that example flows are by definition informative, and do not replace normativetexttext. 11. IANA Considerations 11.1. Update to Registration of SIP INFO Method Please update the existing registration in the SIP Methods and Response Codes registry under the SIP Parameters registry that states: Method: INFO Reference: [RFC2976] to: Method: INFO Reference: [RFCXXXX] 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 Please add the following new SIP header field in the Header Fields subregistry under the SIP Parameters registry. Header Name: Recv-InfoCompact Form: (none) Reference: [RFCXXXX] 11.4. Creation of the Info Packages Registry Please create a subregistry in the SIP Parameters registry for Info Packages. This subregistry has a modified First Come First Served [RFC5226] policy. The following data elements populate the Info Package Registry. o Info Package Name: The Info Package Name is a case-sensitive token. In addition, IANA shall not register multiple Info Package names that have identical case-insensitive values. o Info Package Parameters: The Info Package Parameters are case- sensitive tokens. Info Package Parameters are only applicable to the Info Package for which they are defined, so the same Info Package Parameter Names may exist for different Info Packages. o Info Package Payload MIME Types: A list of zero or more registered MIME types from the MIME Type Registry. o Standards Status: Values are "Standards Track" or empty. See below for a discussion and rules on this field. oCompact Form: (none) Reference:If there is a published specification describing[RFCXXXX] 11.4. Creation of the InfoPackage, placePackages Registry Please create areference to that specificationsubregistry inthis column. See belowthe SIP Parameters registry fora discussionInfo Packages. Based onthis field. If there[RFC5226], IANA assigns an expert in order to review an Info Package which isa published specification, the registration must include a referencetosuch specification.be registered. TheStandards Status fieldInfo Package specification isan indicator ofprovided to thelevel of community review forreviewer, who ensures that the Info Packagespecification. Ifis described in a proper way. The reviewer does not consider thespecification meetsapplicability of therequirementsInfo Package forSpecification Required [RFC5226],thevalueusage forthe Standards Status field is "Standards Track". Otherwise, the fieldwhich it isempty. This document usesdefined. The following data elements populate the Info PackageName "nil" to represent "noRegistry. o Info Packagepresent" and as such,Name: The Info Package Name is a case insensitive token. In addition, IANA shall nothonor a request toregister multiple Info Package names that have identical case-insensitive values. o Reference: A reference to a specification which describes the"nil"Info Package. The initial population of this table shall be: NameMIME Type Standards StatusReferencenil Standards Track [RFCXXXX]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 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 12. Examples 12.1. Indicationoffor which Info Packages UAs are willing to receive INFO requestswithin12.1.1. Initial INVITE request The UAC sends an initial INVITE request, where the UAC indicates that it is willing to receive INFO requests for Info Packages P and R. INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 INVITE Recv-Info: P, R Contact: <sip:alice@pc33.example.com> 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 and T. SIP/2.0 200 OK Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 INVITE Contact: <sip:bob@pc33.example.com> Recv-Info: R, T Content-Type: application/sdp Content-Length: ... ... The UAC sends aninvite dialog usageACK request. ACK sip:bob@pc33.example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 Max-Forwards: 70 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 ACK Content-Length: 0 12.1.2. Target refresh The UAC sends anINVITE request,UPDATE request within the invite dialog usage, where the UAC indicates (using an empty Recv-Info header field) that it is not willing to receive INFO requests for any InfoPackages P and R. INVITE sip:bob@example.comPackages. UPDATE sip:bob@pc33.example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Max-Forwards: 70 To: Bob<sip:bob@example.com><sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq:314159 INVITE314163 UPDATE Recv-Info:P, RContact: <sip:alice@pc33.example.com> Content-Type: application/sdp Content-Length: ... ... The UAS sends a 200OK(OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info PackagesR and T.R. SIP/2.0 200 OK Via: SIP/2.0/TCPpc33.example.com;branch=z9hG4bK776;received=192.0.2.1pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq:314159314163 INVITE Contact: <sip:alice@pc33.example.com> Recv-Info: R, T Content-Type: application/sdp Content-Length: ... ... 12.2. INFO request associated with Info Package 12.2.1. Single payload TheUACUA sendsACK. ACK sip:ngw1@a.example.coman INFO request associated with Info Package foo. INFO sip:alice@pc33.example.com SIP/2.0 Via:SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 Max-Forwards: 70SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774Call-ID:Call-Id: a84b4c76e66710@pc33.example.com CSeq:314159 ACK Content-Length: 0 12.2.314333 INFOrequestInfo-Package: foo Content-type: application/foo Content-Disposition: Info-Package Content-length: 24 I am a foo message type 12.2.2. Multipart INFO 12.2.2.1. Non-Info Package body part SIP extensions can sometimes add body part payloads into an INFO request, independent of the Info Package. In this case, the Info Package payload gets put into a Multipart MIME body, with a Content- Disposition header field that indicates which body part is associated with the Info Package. INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314400 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Length: ... --theboundary Content-Type: application/mumble ... <mumble stuff> --theboundary Content-Type: application/foo-x Content-Disposition: Info-Package Content-length: 59 I am a foo-x message type, and I belong to Info Package foo --theboundary-- 12.2.2.2. Info Package with multiple body parts inside multipart body part Multiple body part payloads can be associated with a single Info Package. In this case, the body parts are put into a Multipart MIME body, withinformationa Content-Disposition header field that indicates which body part is associated witha simple Info Package Here Alice sends Bob a simplethe InfoPackage payload.Package. INFOsip:alice@192.0.2.1sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id:123456mcmxcixa84b4c76e66710@pc33.example.com CSeq:2314423 INFO Info-Package: fooContent-type: application/fooContent-Type: multipart/mixed;boundary="theboundary" Content-Disposition: Info-Package Content-Length: ... --theboundary Content-Type: application/foo-x Content-length:2459 I am a foo-x message type, and I belong to Info Package foo <mumble stuff> --theboundary Content-Type: application/foo-y Content-length: 59 I am a foo-y messagetype 12.3. Multipart INFO Example Other SIP extensions can sometimes add payloadtype, and I belong to Info Package foo --theboundary-- 12.2.2.3. Info Package with single bodyparts into an INFO request, independent ofpart inside multipart body part The body part payload associated with the InfoPackage.Package can have a Content-Disposition header field value other than "Info-Package". In this case, theInfo Package payload getsbody part is put into a Multipart MIME body, with a Content-Disposition header field that indicates which body part is associated with the Info Package. INFOsip:alice@192.0.2.1sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id:123456mcmxcixa84b4c76e66710@pc33.example.com CSeq:7314423 INFO Info-Package: foomumble-extension: <cid:abcd9999qq>Content-Type: multipart/mixed;boundary="theboundary" Content-Disposition: Info-Package Content-Length: ... --theboundary Content-Type:application/mumble Content-Id: abcd9999qq ... <mumble stuff> --theboundary Content-Type: application/fooapplication/foo-x Content-Disposition:Info-Packageicon Content-length:2459 I am afoofoo-x messagetypetype, and I belong to Info Package foo --theboundary-- 13. Security Considerations By eliminating multiple usages of INFO messages without adequate community review and by eliminating the possibility for rogue SIP UAs from confusing another UA by purposely sending unrelated INFO requests, we expect this document's clarification of the use of INFO to improve the security of the Internet. Whilst rogue UAs can still send unrelated INFO requests, this mechanism provides mechanisms for which the UAS and other security devices can filter for approved Info Packages. If the content of the Info Package payload is private, UAs will need to use end-to-end encryption, such as S/MIME, to prevent access to the content. This is particularly important as transport of INFO is likely not to be end-to-end, but through SIP proxies and back-to-back user agents (B2BUA's), which the user may not trust. The INFO request transports application level information. One implication of this is INFO messages may require a higher level of protection than the underlying SIP dialog signaling. In particular, if one does not protect the SIP signaling from eavesdropping or authentication and repudiation attacks, for example by using TLS transport, then the INFO request and its contents will be vulnerable, as well. Even with SIP/TLS, any SIP hop along the path from UAC to UAS can view, modify, or intercept INFO requests, as they can with any SIP request. This means some applications may require end-to-end encryption of the INFO payload, beyond, for example, hop-by-hop protection of the SIP signaling itself. Since the application dictates the level of security required, individual Info Packages have to enumerate these requirements. In any event, the Info Package mechanism described by this document provides the tools for such secure, end-to-end transport of application data. One interesting property of Info Package use is one can reuse the same digest-challenge mechanism used for INVITE based authentication for the INFO request. For example, one could use a quality-of- protection (qop) value of authentication with integrity (auth-int), to challenge the request and its body, and prevent intermediate devices from modifying the body. However this assumes the device which knows the credentials in order to perform the INVITE challenge is still in the path for the INFO, or that the far-end UAS knows such credentials. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009. 14.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.[RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, "Interworking between the Session Initiation Protocol (SIP) and QSIG", BCP 117, RFC 4497, May 2006.[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005. [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007. [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007. [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for 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)", draft-peterson-rai-rfc3427bis-03(SIP) and the Real- time Applications and Infrastructure Area", draft-peterson-rai-rfc3427bis-04 (work in progress),SeptemberOctober 2009. [W3C.REC-voicexml21-20070619]McGlashan, S.,Lee, A.,Carter, J.,Porter, B.,Auburn, R.,Oshry, M., Burnett, D., Rehor, K., Auburn, R., Bodell, M., Burke, D., Baggia, P., Candell, E., Carter, J., andD. Burnett,S. McGlashan, "Voice Extensible Markup Language (VoiceXML) 2.1", World Wide Web Consortium Recommendation REC-voicexml21-20070619, June 2007, <http://www.w3.org/TR/2007/REC-voicexml21-20070619>. [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. [I-D.saleem-msml] Saleem, A. and G. Sharratt, "Media Server Markup Language (MSML)", draft-saleem-msml-09 (work in progress), July 2009. [Ecma-355] "Standard ECMA-355 Corporate Telecommunication Networks - Tunnelling of QSIG over SIP", ECMA http:// www.ecma-international.org/publications/standards/ Ecma-355.htm, June 2008. Appendix A. Legacy INFOUsagesUsage A.1. General This section provides examples of existing legacy INFO usages.ThisThe section is not meant to be a comprehensive catalog of legacy INFO usages, but it should give the reader a flavor for current legacy INFO usages. A.2. ISUP [RFC3372] specifies the encapsulation of ISUP in SIP message bodies. ITU-T and 3GPP have specified similar procedures. A.3. QSIG [Ecma-355] specifies the encapsulation of QSIG in SIP message bodies. A.4. MSCML [RFC5022] specifies how INFO is used as a transport mechanism by the MSCML protocol. MSCML uses an option-tag in the Require header field to ensure that the receiver understands the INFO content. A.5. MSML [I-D.saleem-msml] specifies how INFO us used as a transport mechanism by the MSML protocol. A.6. Video Fast Update Companies have been using INFO messages in order to request fast video update. Currently a standardized mechanism, based on RTCP, has been specified in [RFC5168] Appendix B. Acknowledgements The work on this document was influenced by the "INFO Considered Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and by the "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol" draft (15 January 2003) written by Dean Willis. The following individuals have been involved in the work, and have provided input and feedback on this document: Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard 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, JohnElwellElwell, 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-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 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 "Security Considerations" o "Syntax" section moved further up in the document o Clarification on usage of Info Package related message body parts, and the usage of the Content-Disposition header field with those body parts o Removed REFER and NOTIFY from the INFO Headers table o Clarified usage of the Recv-Info header field in the REGISTER and OPTIONS requests o Major re-write of the Introduction section 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 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 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 o Added 469 error response, instead of reusing 489 o Clarified overlapping INFO method handling o Fixed table 1 to follow 3261, not 2543 o Added REFER to the INFO Headers table o replaced token-nodot with token for Info-Package header field values o Clarified end-to-end security considerations o Info Package parameters are semi-colon delimited, not dot delimited Changes from -02 o Applicability statement explicitly says we're backwards compatible o Explicitly state we work like UPDATE (both early and confirmed dialogs) o Agreed text for IANA Considerations package registry Changes from -01 o One and only one Info Package per INFO o Removed Send-Info header field, greatly simplifying negotiation o Multiple body part identification through Content-Disposition: Info-Package o Note that forking INVITEs may result in multiple INFOs coming back to INVITE originator o Describe how a UAS can enforce strict adherence to this document o Remove CANCEL INFO faux pas o Better explained overlapping INFO issues and resolutions o Token names are now really case sensitive o Moved Info Package Considerations to an Appendix o Introduced stronger, yet more open, IANA registration process o Took a few more paragraphs from INFO Litmus to cover all bases. o Added RFC 5168 to legacy usages Changes from -00 o Corrected ABNF. o Enabled sending of legacy INFO messages. Receiving legacy INFO messages was already here. o Negotiation is not Offer/Answer, it is Offer/Offer. o Created the explicit "nil" Info Package to indicate no info package. o Fixed CANCEL impacting future transactions. 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 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: