SIPCORE                                                        E. Burger
Internet-Draft                                             NeuStar, Inc.
Obsoletes: RFC 2976                                            H. Kaplan
(if approved)                                                Acme Packet
Intended status: Standards Track                             C. Holmberg
Expires: January 6, April 2, 2010                                       C. Holmberg
                                                                Ericsson
                                                            July 5,
                                                      September 29, 2009

  Session Initiation Protocol (SIP) INFO Method and Package Framework
                   draft-ietf-sipcore-info-events-00
                   draft-ietf-sipcore-info-events-01

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 on January 6, April 2, 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document provides new semantics for the SIP INFO method of RFC
   2976.  These new semantics defined here are fully backwards
   compatible with the old semantics.  Core to the new semantics is a
   mechanism for defining, negotiating indicating support of, and exchanging Info
   Packages that use the INFO method.  Applications that need to
   exchange session-
   related application information within a SIP INVITE-created session, also known
   as application level information, invite usage dialog
   (RFC 5057), can use these INFO requests. Info Packages.  This
   draft addresses issues and open items from document replaces RFC
   2976 and replaces it. but still allows existing legacy INFO usages as defined in RFC
   2976.

Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "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].

   Be aware this document strictly follows RFC 3261 [RFC3261] for the
   definition of the terms User Agent Server (UAS) and User Agent Client
   (UAC).  Specifically, the UAC issues a SIP request and the UAS
   responds.  This terminology may be confusing when one combines the
   INFO case with the INVITE case.  For an INVITE, the initiator of the
   session is the UAC and the target of the session is the UAS.
   However, it is possible for the target UA of the session, the UAS of
   the INVITE transaction, to send an INFO to the initiating UA of the
   session, the UAC of the INVITE transaction.  From the perspective of
   the INFO, the target UA of the session (INVITE UAS) is, in fact, the
   UAC (sender) of the INFO request.  Likewise, from the perspective of
   the INFO, the initiating UA of the session (INVITE UAC) is the UAS
   (recipient) of the INFO request.  Since this document strictly
   follows RFC 3261, we refer to the UA that issues the INVITE as the
   "initiating UA" and the UA that responds to the INVITE as the "target
   UA" to remove any confusion.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Info Package Behavior Support . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  UAS Behavior  General  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  UAC  User Agent Behavior  . . . . . . . . . . . . . . . . . . .  7
     3.3.  Package Versioning . . . .  8
     3.3.  Package Versions . . . . . . . . . . . . . . . .  8
     3.4.  REGISTER Processing  . . . . .  9
     3.4.  Advertisement Example . . . . . . . . . . . . . .  8
     3.5.  OPTIONS Processing . . . . 10
   4.  The INFO Method Request . . . . . . . . . . . . . . . .  8
     3.6.  Example  . . . 11
     4.1.  INFO Requests . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  8
   4.  The INFO Request Body Method  . . . . . . . . . . . . . . . . . . . . 12
     4.3.  Responses to the . . .  9
     4.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  INFO Request Method . . . . . . . . . . . 13
     4.4.  Routing Behavior . . . . . . . . . . . . 10
     4.3.  INFO Request Message Body  . . . . . . . . . . . 14
     4.5.  Behavior of Registrars . . . . . 11
     4.4.  INFO Response  . . . . . . . . . . . . . 14
     4.6.  OPTIONS Processing . . . . . . . . . 12
     4.5.  INFO Response Message Body . . . . . . . . . . . 14
     4.7. . . . . . 12
     4.6.  Order of Delivery  . . . . . . . . . . . . . . . . . . . . 15 12
   5.  Formal INFO Method Definition  . . . . . . . . . . . . . . . . 15 13
     5.1.  INFO Method  . . . . . . . . . . . . . . . . . . . . . . . 15 13
     5.2.  INFO Headers . . . Header Fields . . . . . . . . . . . . . . . . . . . . 17 14
       5.2.1.  Info-Package header field  . . . . . . . . . . . . . . . . . 17 15
       5.2.2.  Recv-Info header field . . . . . . . . . . . . . . . . . . . 18 15
   6.  Legacy Uses of INFO Usage  . . . . . . . . . . . . . . . . . . . . . 18 . 15
   7.  Info Package Requirements  . . . . . . . . . . . . . . . . . . 19 16
     7.1.  Applicability  General  . . . . . . . . . . . . . . . . . . . . . . 19 . . . 16
     7.2.  Info Package Name  Applicability  . . . . . . . . . . . . . . . . . . . . 19 . . 16
     7.3.  Info Package Parameters Name  . . . . . . . . . . . . . . . . . 19 . . . 17
     7.4.  Info Package Tags Parameters  . . . . . . . . . . . . . . . . . 17
     7.5.  SIP Option Tags  . . . . 19
     7.5.  INFO Bodies . . . . . . . . . . . . . . . . . 17
     7.6.  INFO Message Bodies  . . . . . . 20
     7.6.  UAC generation of INFO requests . . . . . . . . . . . . . 20 17
     7.7.  UAS processing of INFO requests  Info Package Usage Restrictions  . . . . . . . . . . . . . 20 17
     7.8.  Rate of INFO Requests  . . . . . . . . . . . . . . . . . . 21 18
     7.9.  IANA Registrations . . . . . . . . . . . . . . . . . . . . 21 18
     7.10. Security Considerations  . . . . . . . . . . . . . . . . . 21 18
     7.11. Application Procedures . . . . . . . . . . . . . . . . . . 19
     7.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 21 19
   8.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 19
     8.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.2.  ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22 20
     9.1.  Update to Registration of SIP INFO Method  . . . . . . . . 22 20
     9.2.  Registration of the Info-Package Header Field  . . . . . . 22 20
     9.3.  Registration of the Recv-Info Header Field . . . . . . . . 23 20
     9.4.  Creation of the Info Packages Registry . . . . . . . . . . 23 20
     9.5.  Registration of the Info-Package Content-Disposition . . . 24 21
     9.6.  SIP Response Code 469 Registration . . . . . . . . . . . . 24 21
   10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 21
     10.1. Simple Info Package  . . . . . . . . . . . . . . . . . . . 24 21
     10.2. Multipart INFO Example . . . . . . . . . . . . . . . . . . 24 22
   11. Modifications to SIP Change Process  . . . . . . . . . . . . . 25 23
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     13.1. 24
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     13.2. 24
     12.2. Informative References . . . . . . . . . . . . . . . . . . 27 25
   Appendix A.  Info Package Considerations . . . . . . . . . . . . . 29 27
     A.1.  Appropriateness of Usage  General  . . . . . . . . . . . . . . . . . 29
     A.2.  Dialog Fate-Sharing  . . . . . . . . . 27
     A.2.  Appropriateness of Info Package Usage  . . . . . . . . . . 30 27
     A.3.  Messaging Rates and Volume . . . . . . . . . . .  Dialog Fate Sharing  . . . . . 30
     A.4.  Is there a better alternative? . . . . . . . . . . . . . . 30
     A.5.  Alternatives for Common 27
     A.4.  INFO Use . . . . . . . . . . . . . 32
       A.5.1.  State Updates  . . . . . . . . . . . . . . . . . . . . 32
       A.5.2.  User Stimulus: Touch Tones Request Rate and Others  . . . . . . . . 32
       A.5.3.  Direct Signaling Channel Volume . . . . . . . . . . . . . . . 33
       A.5.4.  Proxy-Aware Signaling 27
     A.5.  Alternative Mechanisms . . . . . . . . . . . . . . . . 33
       A.5.5.  Dialog Probe . . 28
       A.5.1.  Alternative SIP signaling plane mechanisms . . . . . . 28
       A.5.2.  Media Plane Mechanisms . . . . . . . . . . . . . 33
       A.5.6.  Malicious Indicator . . . 29
       A.5.3.  Non-SIP related mechanisms . . . . . . . . . . . . . . 34 29
   Appendix B.  Legacy INFO Usages  . . . . . . . . . . . . . . . . . 34 29
     B.1.  ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 30
     B.2.  QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 30
     B.3.  MSCML  . . . . . . . . . . . . . . . . . . . . . . . . . . 35 30
     B.4.  MSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 30
     B.5.  Video Fast Update  . . . . . . . . . . . . . . . . . . . . 35 30
   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 35 30
   Appendix D.  Change Log  . . . . . . . . . . . . . . . . . . . . . 36 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 33

1.  Introduction

   The SIP protocol

   [RFC3261] defines session control messages used a mechanism to setup and tear down a SIP controlled session.  In addition, a sessions.  A
   SIP User Agent (UA) can use the re-INVITE and UPDATE methods during a
   session to change the characteristics of the session.  Most often,
   this is to change the properties of session, including media flows related to the
   session
   properties, target information or properties related to update the SIP
   session timer mechanism [RFC4028].

   The purpose of the INFO message [RFC2976] is to carry application
   level information
   along between endpoints, using the SIP session signaling
   path.  Note that the INFO method does is not change used to update
   characteristics of the SIP session state.  It may, however, change application state for session, but to allow the applications using
   which use the SIP session. session to exchange information.

   While the INFO method has been widely adopted for specific
   application use cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither
   defined does
   not define a negotiation mechanism nor mechanisms for SIP UAs to indicate what usages of INFO
   they support.  In addition, [RFC2976] does not provide a means by which mechanism to
   explicitly indicate the type of application information contained in for which the INFO
   message.  This led to problems associated with static configuration.
   message is used.  In addition, the industry realized there was a potential for
   interoperability problems due to undefined content syntax and
   semantics.  This draft addresses these deficiencies and provides a
   framework for explicit negotiation of capabilities and content
   context using "Info Packages".

   The INFO method as defined by RFC 2976 did not provide any context
   for the information the request carried.  While some cases it may sometimes can be
   clear what the content is based on the Content-Type, this is only
   true where there is only one contextual usage of determined by the content-type.
   For example, if INFO
   message body content, but not in a general way.

   Example: If the Content-Type is "image/jpeg", the MIME-attached
   content is a JPEG image.  However,  Still, there are many useful ways a UAS UA can
   render an image.  Said differently, there are different contexts
   for an image in SIP.  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.  Thus, we

   Due to the problems described above, the usage of INFO often requires
   static configuration about what INFO usages the UAs support, and the
   way the handle application information transported in INFO messages.
   That has caused a big risk interoperability problems in the industry,
   due to undefined content syntax, semantics and UA support of the INFO
   messages.  Therefore, there is a need for a well defined and
   documented statement description of what the information sent in the INFO is
   used for.  This situation is identical to the context issue in
   Internet Mail [RFC3458].  RFC 3458 goes into this

   This document defines a mechanism, using Info Packages, which
   provides the possibility for UAs to indicate what INFO usages they
   support, and other issues to define content syntax and semantics for the data
   transported in the INFO messages.  The mechanism allows existing
   legacy INFO usages as defined in RFC 2976.  New INFO usages MUST use
   the mechanism defined in detail. this document.

   Event Packages [RFC3265] perform the role of disambiguating the
   context of a message for subscription-based events.  This document  The Info Package
   mechanisms provides a similar framework functionality for INVITE-based application level information exchange.  However,
   exchange using invite dialog usages [RFC5057].

   Note that while the mechanism described here is Info Packages may be similar to subscription-based
   events, there is no formal relationship between this mechanism and
   the subscription mechanism.  In
   particular, when a UAC issues a SUBSCRIBE, it creates a dialog usage.

   The Info Package mechanism defined here creates neither does not create a separate subscription dialog nor a subscription usage within an existing session.  Instead,
   it uses the INVITE method and its responses to indicate supported
   Info Packages usage.
   INFO messages are always part of, and share the fate of, an invite
   dialog usage.  INFO method to convey the Info Packages.

   Each UA enumerates which Info Packages it can receive.  If a first UA
   indicates it message can receive a package not be sent as part of other dialog
   usages, and they can not be sent outside an existing session.

   If a second UA can send the
   package, supports the second UA can send INFO methods containing Info Package mechanism it indicates, using the payload
   for that package.  The
   Recv-Info header indicates field which packages a UA Info Packages it is willing to receive.  The Info-Package header indicates which
   package receive,
   on a particular INFO method request belongs to.  There is per-session basis.  A UA can indicate a
   reserved new set of Info Package, "nil", which indicates Packages
   at any time during the lifetime of the invite dialog usage of the
   session.  A UA conforms can use a "nil" value to this
   document, but does indicate that it is not wish
   willing to receive any Info Packages.  This enables
   other UAs that conform to this document to detect legacy UAs.  A
   legacy UA will not include a Recv-Info header in their SIP session
   establishment or modification requests.  Conversely, Packages at a UA certain moment, but that
   the UA still supports the Info Packages will have Package mechanism.

   When a Recv-Info header. UA sends an INFO request, it uses the Info-Package header
   field to indicate which Info Package is associated with the request.

   Section 3 describes the mechanism to indicate support of Info Package advertisement in detail.

   This document does not describe any specific Info Package type
   extensions.  One must extend this protocol by other documents, herein
   referred to as "Info Packages".
   Packages.

   Section 7 4 describes guidelines for
   creating these extensions.

   The INFO method does not change the state usage of SIP calls or the
   parameters INFO messages.

   Section 6 describes legacy usage of the sessions SIP initiates.  It merely sends optional
   application layer information, generally related to the session.

   Applications need INFO, as defined in [RFC2976].

   Section 7 describes guidelines on how to be aware that application level information
   transported by the INFO method constitutes mid-session signaling.
   These messages traverse the post-session-setup SIP signaling path. define Info Packages.  This is the path taken by SIP re-INVITEs, BYEs, and other SIP
   requests within an individual session.  SIP proxy servers will
   receive,
   document does not define any specific Info Packages.

   Annex A provides guidelines and potentially act on, mid-session signaling information.
   Application designers need issues to understand this can be a feature, as consider when deciding if
   usage of Info Packages is the User Agents are exchanging information that elements in the
   SIP signaling path need to be aware of.  Conversely, this can be a
   problem, as messages these network elements have no interest in can
   also put most appropriate mechanism for a significant burden on those element's ability to process
   other traffic.  Moreover, such network elements may not be able to
   read end-to-end encrypted INFO bodies.
   specific use-case.

2.  Applicability

   This document replaces the SIP INFO method document extends [RFC2976] to include explicit negotiation of supported Info Packages a mechanism to in SIP
   messages explicitly indicate the INVITE
   transaction supported Info Packages, and indication of the to
   explicitly indicate what Info Package to use by using a new
   header field in the is associated with an INFO
   request.  As described in Section 4.1, the  The mechanism described here is backwards backward compatible with legacy, RFC
   2976 INFO mechanisms.

3.  Info Package Behavior

   As stated in the Conventions section, the term UAC refers to the UAC
   (sender) legacy usage of the INFO method
   INFO, as defined in [RFC2976], and UAS refers to the recipient of the allows such usage.  New INFO method.  "Initiating UA" refers to the sender of an initial
   INVITE to establish a session and "target UA" refers to
   usages MUST use the recipient
   of that INVITE request. mechanism defined in this document.

3.  Info Package Support

3.1.  UAS  General

   This section describes how SIP UAs indicate which Info Packages they
   are willing to receive.

3.2.  User Agent Behavior

   A UAS supporting this document UA which supports the Info Package mechanism MUST advertise indicate the set
   of Info Packages it is willing to receive receive, using the Revc-Info header
   field.  A UA can list multiple Info Packages in a single Recv-Info header(s) in dialog
   usage requests
   header field, and responses for the UA can use multiple Recv-Info header fields.

   The indication of Info Packages can take place during the session establishment or
   establishment, and during a target refresh.  This includes INVITE,
   UPDATE, PRACK, ACK, and their non-
   failure non-failure responses (101-199 and 2xx
   only).  Note that the UAC is not required to indicate its set of Info
   Packages in the initial INVITE request.

   Once a UAS indicates support for an Info Package by sending UA has indicated that it is willing to to receive a Recv- specific
   Info header with one or more package names, Package, and a dialog has been established, the UAS UA MUST be
   prepared to receive an INFO containing request associated with that package.  Note this may occur
   before dialog negotiation completes.

   Recall the UAC of Info Package.

   A UA MUST NOT send INFO request associated with Info Packages until
   it has received an INVITE may choose indication of which Info Packages the remote UA is
   willing to receive (be receive.

   If a UAS for) INFO
   methods.  This UA may chose indicates that it is willing to receive of multiple Info
   Packages, which provide similar functionality, it is not possible to offer any packages in the initial
   INVITE and subsequently advertise packages from
   indicate that the target UA's
   subsequent responses, in order to support third-party call control
   [RFC3725].

   A UAS lists multiple packages by enumerating the package name(s),
   separated by commas, as values for the Recv-Info header in the
   session establishment exchange.  A UAS may also list multiple
   packages by including multiple Recv-Info headers.  The UAS may also
   combine multiple Recv-Info headers with one or more packages in each
   header value.  If the UAS prefers UA wishes to receive one package over
   another, the UAS MUST list the preferred Info Package lexically
   earlier in the message.  That is, by listing it earlier in a list
   within a given Recv-Info header or listing it in a previous Recv-Info
   header in a given message.  The UAS MUST NOT list a package more than
   once.  This order is only a hint to the UAC, as there is no
   meaningful way of enforcing the use one of a preferred package at the
   UAC.

   There them.  It is an important issue to consider when the UAS advertises
   support for multiple packages that one might interpret up to be similar
   or equivalent.  The UAC has no method of knowing whether the UAS
   would like
   the UAC to send a single INFO request application logic associated with the preferred
   package or for the UAC Info Packages, and specific
   Info Package descriptions to send multiple INFO requests with the same
   or similar information.  The describe application behavior is entirely up to the UAC and
   the rules specified by the package definitions. in such
   cases.

   If a UAS does UA is not wish willing to receive any Info Packages, during session
   establishment or later during the UAS session, the UA MUST indicate this
   by including one and only one a Recv-Info header field with the a header value of 'nil'.
   This enables the UAC other UAs to discern detect that the difference between UA still supports the Info
   Package mechanism.

   Example: If a UAS that understands UA has previously indicated support of Info Packages but
   foo and bar, and the UA during the session wants to indicate that it
   does not wish want to receive any
   from a legacy UAS that does not understand Info Packages.  A UAC
   conforming to this document can always send or receive legacy INFO
   usages without packages.

   Info Package capability advertisement occurs within Packages anymore, the context UA sends a
   target refresh request with a Recv-Info header field with a header
   value of 'nil'.

   For backward compatibility purpose, even if a
   session negotiation exchange.  The UA indicates support
   the Info Package capability set
   received by the UAC within the last exchange mechanism, it is the one the UAC will
   use to chose Info Packages from.  Also note that due to glare, an
   INFO request may be in flight prior still allowed to the UAC receiving an updated
   capability set removing enable legacy
   usages of INFO.

   This document does not define a given Info Package.  Thus, SIP option tag [RFC3261] for the UAS MUST be
   prepared to handle an INFO request with an Info
   Package payload with
   a newly delisted mechanism.  However, Info Package.  Proper handling does include
   rejecting the request Package specifications MAY define
   option-tags associated with a 469.  See the specific Info Package, as described
   in Section 4.3 for more on this
   topic.

3.2.  UAC Behavior

   A UAC MUST NOT send INFO requests 7.5.

   Note that, for backward compatibility purpose, if a given UA indicates
   support of the INFO package until method, it does not implicitly indicate support
   of the Info Package mechanism.  A UA MUST use the
   UAC receives an "INVITE dialog usage" request or response (for
   session establishment or target refresh) with a Recv-Info header
   listing
   field to indicate support of the given Info Package.

   At any time during an "INVITE dialog usage" request or response, Package mechanism.  Likewise,
   even if a
   UAS sends one or more Recv-Info headers, UA uses the UAC MUST replace Recv-Info header field to indicate that it
   support the old
   set of supported Info Packages with Package mechanism, in addition the collection UA MUST still
   also explicitly indicate support of Info Packages
   enumerated by the current message.

   If the UAS does not send any Recv-Info headers in a message, then the
   list of supported INFO method.

3.3.  Package Versioning

   The Info Packages Package mechanism does not change.

   A UAC MUST cease sending INFO requests for a given INFO support package when
   the UAC receives an "INVITE dialog usage" request or response (for
   session establishment or target refresh) that does not versioning.
   Specific Info Package payloads MAY contain a
   Recv-Info header listing version information, which
   is handled by the given Info Package.  Note applications associated wit the UAC MUST
   be prepared to receive a 469 response (Section 4.3) at any time, even
   if Info Package, but
   that is outside the UAS advertised it could receive scope of the Info Package.  This
   situation can occur Package framework.

   Note: Even if an Info Package name contains version numbering (e.g.
   foo_v2), the UAC sends the INFO request at the same
   time Info Package mechanism does not distinguish a version
   number from the UAS advertises it no longer supports rest of the Info Package name.

3.4.  REGISTER Processing

   When a UA registers, it SHALL include Recv-Info header field in
   question.

   If the UAC receives
   REGISTER request, and list the Info Packages that it supports.  The
   registrar MAY later use the information e.g. for forking decisions.

3.5.  OPTIONS Processing

   If a UA sends an OPTIONS request, or a response, the UA SHALL include
   Recv-Info header with field in the value 'nil', message, and list the UAC Info Packages
   that it supports.

   A UA MUST NOT send any INFO methods that contain requests with Info Packages. Packages based on the
   information the UA received in an OPTIONS request.  The UAS may advertise support for multiple Info Packages.  If some of
   these packages have similar or equivalent functionality and the Packages
   MUST be negotiated for each session.

3.6.  Example

   The UAC
   supports multiple such packages, sends an INVITE request, where the UAC SHOULD chose indicates that it is
   willing to send Info
   Package payload(s) from the receive Info Package listed lexically earlier in
   the last Recv-Info advertisement the UAC received from the UAS.  This
   document cannot make this protocol action 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 must strength, as the
   concept of "similar or equivalent" is highly Info Package specific.

   INFO itself does not necessitate the use of Require or Proxy-Require
   headers.  There is no token defined for "Supported" headers.  If
   necessary, clients may probe for 200 OK response back to the support of this version of INFO
   using UAC, where the OPTIONS request defined in SIP [RFC3261].  One could
   envision a particular Info Package implementation UAS
   indicates that relied on
   either of these headers.  See Section 7 for more on this issue.

   The presence of the Recv-Info header in a message is sufficient to
   indicate support for this version of INFO.  The "methods" parameter
   for Contact [RFC3841] it is not sufficient willing to determine if the endpoints
   support Info Packages, as the INFO method supported might be the
   obsolete RFC 2976 [RFC2976] version.

   For Info Packages, this draft does not provide a means of requiring
   support for a specific receive Info Package.  If 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:alice@pc33.example.com>
  Recv-Info: R, T
  Content-Type: application/sdp
  Content-Length: ...

  ...

   Since the UAS does not indicate support for an Info Package that the UAC requires, and P, the UAC
   requires decides to
   indicate in the use of ACK request that package, the UAC can use any supported
   RFC3261 [RFC3261] method it is only willing to terminate the session.

   A UAC MAY send a legacy INFO [RFC2976] method at any time.

3.3. receive Info
   Package Versions

   The protocol mechanism described herein does not provide for a
   package versioning mechanism.  This is for two reasons.  The first is
   that if an Info Package has a capability for forward and backward
   compatibility in the Info Package payload, then that compatibility
   comes from the application level semantics of the information.  This
   means it is the responsibility of the application to handle such
   compatibility and not the INFO framework.  For example, one could use
   XML versioning techniques in the payload to indicate versions of R, which the
   Info Package.

   The second reason we do not have a package versioning system is not
   all payloads have sufficient capability to carry payload versions.

   In this situation, it is highly unlikely payloads will be backwards
   compatible.  That is, what one really is defining is a new Info
   Package.  This is more especially so when one considers User Agents
   can advertise package UAS also indicated support but cannot advertise package version
   support.  Even if we did allow for package versioning, as a parameter
   to the Recv-Info header value, for example, it is lexically
   equivalent to having a new Info Package.

   UACs MUST NOT depend on any lexical parsing of the Info Package name
   for versioning, such as "fooV1" and "fooV2" or "foo.1" and "foo.2".

3.4.  Advertisement Example

   Here is an INVITE.  The initiating UA advertises the following.

   INVITE sip:bob@example.com of.

   ACK sip:ngw1@a.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 INVITE 314163 ACK
   Recv-Info: P, R
   Contact: <sip:alice@pc33.example.com>
   Content-Type: application/sdp
   Content-Length: ...

   ... 0

4.  The INFO Method
4.1.  General

   This means section describes how the initiating UA is willing to receive from handling of INFO requests and
   responses, and message bodies carried in INFO messages.  It also
   describes how an UA can indicate support of Info Packages
   P in OPTIONS
   requests and R.

   In this next message, the target UA responds with during registration.

   The INFO method provides additional, application level information
   that can further enhance a 200 OK:
  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:alice@pc33.example.com>
  Recv-Info: R, T
  Content-Type: application/sdp
  Content-Length: ...

  ...

   This indicates SIP application.  Annex A gives more
   details on the target UA types of application for which the usage of INFO is willing to receive from Info Packages
   R and T.

   The initiating UA then confirms in an ACK,
   seen as shown.

   ACK sip:ngw1@a.example.com SIP/2.0
   Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
   To: Bob <sip:bob@example.com>;tag=a6c85cf
   From: Alice <sip:alice@example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.example.com
   CSeq: 314163 ACK
   Recv-Info: R
   Content-Length: 0 appropriate.

   The target UA can now send from package R to the initiating UA.
   Moreover, rules and procedures in this example, the target UA Section apply to implementations and
   applications which support this.  Existing implementations of, and
   applications using, [RFC2976], may not send from package P,
   as P no longer is in follow the initiating UA's Info Package set.

4.  The INFO Method Request

4.1.  INFO Requests

   The INFO method provides additional, application level information
   that can further enhance a SIP application.  It is important to note
   there are some types rules in this
   Section.  Because of application information for which using backward compatibility purpose such cases MUST
   NOT be regarded as error behavior, or wrong protocol usage, but
   simply part of legacy INFO
   messages are inappropriate.  See Appendix usage.

4.2.  INFO Request

   A for a discussion of this.

   The UAC UA MUST include the a Info-Package header field field, which indicates the
   Info Package contained in the request, when it sends an INFO request
   carrying an Info Package.  The Info-Package header field
   value in an  An INFO request MUST can contain only a single
   Info Package token.
   That Info Package token Package.  A UA MUST match one of the NOT send INFO requests associated with Info
   Packages for which the UAS remote entity has not indicated support willingness
   (using the Recv-Info header filed) to receive for during the negotiation described in Section 3.

   The UAC session.

   A UA MAY send an INFO in a legacy usage context.  See Appendix B
   for examples of legacy usages.  In general, a legacy usage is where such case there
   is no Info-Package header.  In this case, if the UAS has never
   offered a Recv-Info header or never offered a Recv-Info header Info Package associated with a
   package of a similar function to the legacy INFO usage, and the UAC MAY
   send an INFO without request
   does not contain an Info-Package header field and a body
   appropriate to field.  In addition, the
   support of the said legacy usage.

   A UAC MUST NOT use usage has not been negotiated using the Recv-
   Info header field.  See Appendix B for examples of legacy usages.

   The INFO method MUST NOT be used outside an INVITE dialog usage.  The
   INFO method has no lifetime or usage of its own, as it is
   inexorably linked to that of the INVITE.  When the INVITE-created own.  Supported Info
   Packages are negotiated on a per session terminates, that signals the termination of basis, and the negotiated
   Info Packages.  A UAS that negotiation
   result MUST NOT be used for other sessions.  If a UA receives an INFO message after
   request outside an existing dialog, the INVITE
   dialog usage terminates UA MUST respond response with a 481
   Call Does Not Exist.

   The session identifiers defined in RFC 3261 [RFC3261] must match
   those of the provisional or final responses Exist error response.

   Due to the INVITE.  As possibility of forking, a
   result, INFO requests cannot fork.  The UAC may send INFO requests
   once which during the UAS has sent early
   dialog phase indicates support of one or more Info Packages (using
   the Recv-Info header field value, indicating
   what the UAS supports.

   The converse is not true during initial session establishment.  The
   initiating UA of the first INVITE field) MUST be prepared to receive
   multiple INFO requests, as requests
   from multiple remote entities.  Note that different remote entities
   can indicate different sets of Info Packages which they are willing
   to receive.

   The construction of the first INVITE may fork.  Since session
   negotiation has not completed, and we allow early INFO requests,
   multiple target UAs may respond.  This initial session establishment
   phase is the only time the UAS need be prepared to receive multiple
   INFO requests, as one would expect there may be messages from non-
   authoritative forked dialogs prior to their termination.

   The construction of the INFO request request is the same as any other request
   within an existing INVITE-initiated session. INVITE dialog usage.  A UAC MAY UA can send an INFO
   request on requests
   both an on early and confirmed session. dialogs.

   The INFO request MUST NOT carry contain a Recv-Info header. header field.  The UAC UA
   can only
   negotiate indicate the Info Packages that it is willing to receive
   using the procedures of messages listed in Section 3.

   The signaling path for the INFO method is the signaling path
   established as a result of the session setup.  This can be direct
   signaling between the calling and called user agents or a signaling
   path involving SIP proxy servers that were involved in the call setup
   and added themselves to the Record-Route header on the initial INVITE
   message.

4.2.

4.3.  INFO Request Message Body

   The purpose of the INFO request is to carry application level
   information between SIP user agents. UAs.  The INFO message body application data associated with an
   Info Package SHOULD
   carry this information, unless be carried as a payload in the message headers carry body of
   the INFO request, unless the information of interest.  Note this is not an invitation to invent can be retrieved from a SIP headers for
   header field.

   Info Package specifications MUST describe the purposes of application level
   information
   exchange.  Rather, one could envision circumstances where existing
   SIP headers already convey the information the application has
   interest in.

   If associated with the Info Package defines Package.  Message body payloads
   MUST have a payload, and the package specification MIME type value defined.

   If a UA indicates that it is appropriate willing to include receive a payload with the request,
   the UAC MUST include the payload with specific Info
   Package, it means that the UA also supports any associated message
   body MIME type specified by associated with the Info Package.

   If  However, the Info Package definition directs UA
   MUST still indicate support of those MIME types also in the UAC Accept
   header filed, according to send a request
   without a payload, the UAC MUST send the INFO request without a body. procedures in [RFC3261].

   Some SIP extensions, which are orthogonal to INFO, may MAY insert body
   parts unrelated to the INFO payload.  User Agents Info Package.  UAs MUST conform to RFC
   3261 [RFC3261]
   as updated by body-handling [I-D.ietf-sip-body-handling] to support
   multipart MIME handling.  If there are bodies unrelated to
   the Info Package, and the Info Package also has a payload, the UAC
   MUST bundle these elements into a multipart MIME body.  In this case,
   the UAS needs a means to unambiguously identify the

   Each message body part
   belonging to the Info Package.  To do this, the UAC MUST identify the
   Info Package payload MIME (or body part with a Content-Disposition of
   'Info-Package'.

   If in the payload case of an Info Package is already a multipart MIME body,
   the UAC MIME) MUST identify the payload with
   contain a Content-Disposition of header with an 'Info-Package' header
   value, in the headers for the appropriate MIME body part.

   If there is no payload in the INFO request unrelated order to in an easy way distinguish payloads associated
   with the Info Package and the payload of from other payloads.

   If the Info Package whole message body is not a multipart MIME,
   the UAC MUST identify the message, at the SIP header level, associated with a
   Content-Disposition of 'Info-Package'.

   If there is no payload for the Info Package, they UAC MAY omit the UA
   MUST insert a Content-Disposition header.

      NOTE: We could be lazy and even save 33 octets by allowing header with an 'Info-Package'
   header value in the UAC
      to construct a non-multipart MIME payload without a Content-
      Disposition header.  However, mandating SIP part of the presence makes parsing
      considerably easier, and it message.  In that case, if
   multipart MIME is easier used, the UA does not need to have it required now than
      run into a problem later. insert an 'Info-
   Package' header value for the individual body parts.

   NOTE: One could offer that To avoid corner cases with legacy INFO usage, the Info-Package
   header field is redundant,
      as we could have used to indicate the Info Package name be name, rather than
   to use a Content-Disposition header field parameter for Content-
      Disposition.  However, there could be corner cases with legacy
      INFO usage that makes this a poor choice.

4.3.  Responses in order to
   indicate the name.

4.4.  INFO Request Method Response

   If a UAS UA receives an INFO request, it MUST send a final response.  A
   UAS MUST send a 200 OK response for an INFO request with no message
   body and no Info-Package header if the UAS received the INFO request
   on an existing session.  This protocol action supports legacy use of
   INFO as a keep-alive mechanism.

   If the UAS receives an INFO request associated with an Info-Package
   that the UAS
   advertised with a Recv-Info in the last session state update UA has indicated willingness to receive, and the
   body of the INFO
   request is an appropriate MIME type for the Info
   Package, contains data associated with that Info-Package, the UAS UA MUST
   send a 200 OK response.

   If the INFO request contains a body the server does not understand
   then, in the absence of Info Package associated processing rules for
   the body, including the absence of UA receives an Info-Package header, the server
   MUST respond with a 415 Unsupported Media Type message.

   If the INFO request indicates request, associated with an Info Package type
   that the server does UA has not understand, then indicated willingness to receive, the server UA MUST respond with
   send a 469 Bad INFO
   Package. Package response.  In the terminology of Multiple
   Dialog Usages [RFC5057], this represents a Transaction Only failure.

   If a server UA receives an INFO request with a body it understands, but
   the request has for legacy usage, for which no Info-Package header, the UAS MAY use Info-
   Package is associated (the INFO request does not contain an Info-
   Package header filed), the body as
   it sees fit. UA must send a 200 OK response.

   If the UAS accepts the a UA receives an INFO request, which does not match any existing
   INVITE dialog usage, the UAS UA MUST
   respond to the INFO request with a 200 OK.  This enables legacy use
   of INFO.  If the UAS needs to enforce strict compliance with the
   current INFO framework described here, the UAS MUST reject the
   request with a 469.

   The UAS MUST send send a 481 Call Leg/Transaction Does
   Not Exist response.

   If a UA receives an INFO request, which carries a message body that
   the UA does not support, and support of the message body is required
   in the Content-Disposition header field, the UA MUST send a 415
   Unsupported Media Type response.  If support of the message body is
   optional, the UA MUST send a 200 OK response even if the INFO request UA does not match any existing INVITE-initiated
   session.
   support the message body.

   The UAS MAY send other responses, such as Request Failure (4xx),
   Server Failure (5xx) and Global Failure (6xx) as appropriate for the
   request.

4.4.  Routing Behavior

   Unless stated otherwise, the protocol rules for

4.5.  INFO Response Message Body

   The response to the INFO request
   governing is normally generated by the usage of tags, Route and Record-Route, retransmission
   and reliability, CSeq incrementing and message formatting follow
   those in RFC 3261 [RFC3261] as defined for SIP
   stack before the BYE request.

   The INFO message Info Package application data has been provided to
   the application associated with the Info Package.  Therefore, an Info
   Package MUST NOT change define the state inclusion of the SIP session.  Of
   course, outside the INFO machinery specific failure responses as
   documented a message body in an INFO
   response.

   If the SIP dialog usages document [RFC5057], may cause application that received the
   INVITE session information needs to terminate.

4.5.  Behavior of Registrars

   Registrars receiving a REGISTER request that includes Recv-Info
   headers MAY store such send some
   information and use it for routing purposes.
   How in the registrar uses this information is beyond other direction, it MUST trigger a new INFO
   request, rather than using the scope response of this
   document.

4.6.  OPTIONS Processing

   A UAC, the sender received INFO request.

4.6.  Order of the OPTIONS request, SHOULD include Recv-Info
   headers, populated appropriately for the packages the UAC supports. Delivery

   The UAS SHOULD include its set of Recv-Info packages.  These
   strictures are of "should" strength because local policy might
   restrict the advertisement of full capabilities, the UA may know the
   best choice of equivalent packages to list from local configuration,
   and so on.

   The UAS and UAC MUST NOT consider Info Package framework relies on the OPTIONS request CSeq header field to be part of a
   capabilities negotiation.  The OPTIONS detect
   if an INFO request is purely a probe.
   For the UAC or UAS to renegotiate package support, they must use the
   procedures described in Section 3.

4.7.  Order received out of Delivery

   The INFO method does not define order.

   If specific applications need additional mechanisms for ensuring in-order
   delivery for overlapping INFO requests.  That is, the UAC can send
   another INFO request before receiving a transaction response from the
   UAS to a prior INFO request.  While the UAC will increment the CSeq
   header upon the transmission order of
   delivery, those mechanisms, and related procedures, MUST be specified
   as part of new INFO messages, the UAS cannot use
   the CSeq to determine the associated Info Package, and possible sequence of numbers
   etc MUST be defined as application data.

5.  Formal INFO information.  All a UAS
   can determine is the UAC sent one Method Definition

5.1.  INFO message after another. Method

   This
   is due to the fact that there could be gaps in the INFO message CSeq
   count caused by a user agent sending re-INVITES or other document describes one new SIP
   messages.

   It is up to method: INFO.  This document
   replaces the individual Info Package definition to specify what
   happens when there are overlapping INFO requests.  However, since it
   is legal SIP to have overlapping requests, the application must be
   able to handle the reception of overlapping requests.  Overlapping
   requests can occur even if the particular instance of an application
   (Info Package) does not allow it, as the mechanism described here is
   package-agnostic.  Thus, the Info Package needs to define the
   appropriate response.  This is more especially so given the UAC could
   send from multiple Info Packages.  Some of those packages may allow
   overlapping INFO requests, while others do not.  In this situation,
   it would be hard to tell if the non-overlapping packages were being
   violated or not.

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]. and registrations found in [RFC2976].

   This table expands on Tables 2 and 3 in [RFC3261].

     Header                    Where    INFO
     ------                    -----    ----
     Accept                      R       o
     Accept-Encoding             R       o
     Accept-Encoding            2xx      o
     Accept-Encoding            415      c
     Accept-Language             R       o
     Accept-Language            2xx      o
     Accept-Language            415      c
     Alert-Info                          -
     Allow                       R       o
     Allow                      200      -
     Allow                      405      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
     Max-Breadth                 R       -
     Max-Forwards                R       o
     MIME-Version                        o
     Min-Expires                         -
     Organization                        o
     Priority                    R       -
     Privacy                     R       o
     Proxy-Authenticate         407      o
     Proxy-Authorization         R       o
     Proxy-Require               R       o
     Reason                      r       o
     Record-Route                R       o
     Record-Route             2xx,18x    o
     Require                             o
     Retry-After                 R       -
     Retry-After            404,480,486  o
     Retry-After                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

5.2.  INFO Headers Header Fields

   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      -   -   -   -   -   -   -   o*   m*  -   -   -   -   -
Recv-Info      R      o   -   -   o   o   o   o   -   -   o   -   -   -   o   o
Recv-Info      2xx    o   -   -   o   o   -   o   -   -   o   -   -   o   -
Recv-Info      1xx    o   -   -   o   o   -   o   -   -   o   -   -   -
Recv-Info      r      o   -   -   -   o   -   o   -   -   o   -   -   -

   * The Info-Package header field is MANDATORY for INFO messages sent using requests
   associated with Info
   Packages as described in this document. Packages.  The Info-Package header field is OPTIONAL not
   applicable for legacy (RFC2976) usage INFO messages. requests [RFC2976].

                    Table 2: INFO-related Header Fields

5.2.1.  Info-Package header field

   This document adds Info-Package to the definition of the element
   "message-header" in the SIP message grammar.  Section 4 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  Info-package-param is not part of the comparison-checking
   algorithm.

   This document does not define values for Info-Package types.
   Individual Info Packages Package specifications define these values.  Such documents
   specifications MUST register such the values with IANA.  These values are
   Specification Required [RFC5226].

5.2.2.  Recv-Info header field

   This document adds Recv-Info to the definition of the element
   "general-header" in the SIP [RFC3261] message grammar.  Section 3
   describes the Recv-Info header field usage.

6.  Legacy Uses of INFO

   Several RFC-defined Usage

   A number of applications, standardized and other standards-defined uses proprietary, make use of RFC 2976
   INFO
   [RFC2976] exist and are in use, as well messages as numerous proprietary uses.
   Appendix B describes some of these usages.  By definition,
   identifying such uses has relied on either static local configuration
   or implicit context determination based on the body Content-Type or
   Content-Disposition value or some proprietary mechanism.  This draft
   cannot forbid nor avoid such uses, since local configuration can
   always override standardized mechanisms.

   To maintain backward compatibility with defined in [RFC2976], without defined Info Packages
   the extant standardized uses
   of INFO, and a server MAY interpret an possibility to use SIP to indicate what INFO request with no "Info-
   Package" header as being of such legacy usages UAs are
   willing to use.

   It should be noted that  For backward compatibility purpose, this document
   does not deprecate such legacy use will usage, and does not "break" mandate to define Info
   Packages for existing usages.  However, any new usage of INFO SHALL
   use the Info Package mechanism defined in this draft.  For example, if a UA supports SIP-T
   [RFC3372], it does so based on static local configuration or based on
   acceptance of the application/isup body.  If it adds support for this
   draft's Info Package negotiation mechanism, the local configuration
   still applies, and the UA will send/receive specification.

   Since legacy INFO messages based on
   SIP-T regardless of the Info Package negotiation.  It will also be
   able usages to send/receive INFO messages based on the not have associated Info Packages Packages, it
   negotiated.  If, at some future time, an Info Package is defined for
   SIP-T, the UA can indicate such in
   not possible to use the negotiation, Recv-Info and again local
   configuration would supersede if need be.  The Info-Package header fields for
   legacy INFO usages.  That is, a UA would can not lose use the
   ability Recv-Info header
   filed to use SIP-T with indicate for which legacy devices.  Rather, usages it would gain the
   ability is willing to use it with devices which support this draft receive
   INFO requests, and with
   which it did a UA can not have such local configuration set, and could avoid
   failures related use the Info-Package header to unsupported bodies.

   It
   indicate for which legacy INFO usage an INFO request is the hope of this draft's authors that vendors that implement
   proprietary associated
   with.

   NOTE: For legacy INFO uses submit their mechanisms as usages, static configuration is often used to
   define what specific legacy INFO usages UAs support.

   An INFO request associated with an Info Package
   extension documents, MUST contain a Info-
   Package header field.  An INFO request without an Info-Package header
   field MUST NOT contain an Info-Package header field, and follow the request
   SHALL be interpreted as being a legacy INFO usage request.

   UAs are allowed to enable both legacy INFO usages and Info Package negotiation
   mechanism defined in this draft.
   usages as part of the same session.

7.  Info Package Requirements

7.1.  General

   This Section provides guidance on how to define an Info Packages SHOULD NOT reiterate any of Package, and
   what information needs to be provided.

   If an Info Package extends or modifies the behavior described in this
   document, unless required for clarity or emphasis.  However,
   such packages it MUST describe be described in the behavior definition for that extends or modifies the
   behavior described Info
   Package.  Info Package definitions SHOULD NOT repeat procedures
   defined in this document. specification, unless needed for clarification or
   emphasis purpose.

   Info Packages MUST NOT weaken any behavior designated with "SHOULD"
   or "MUST" in this document. specification.  However, Info Packages MAY
   strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST"
   strength if applications associated with the application Info Package requires
   it.

   In addition to the normal sections expected in standards-track RFCs
   and SIP extension documents, authors of

   Info Packages need to Package definitions SHALL address
   each of the issues detailed defined in the
   following subsections, whenever
   applicable.

7.1. unless an issue is not applicable for the
   specific Info Package.

7.2.  Applicability

   This section, which

   The Info Package specification MUST be present, describes describe why any of the Info Package
   mechanism, rather than some other
   established user-to-user data transfer protocols are not appropriate mechanism, has been chosen for the given Info Package.
   specific use-case to transfer application information between SIP
   endpoints.  Common reasons can be a requirement for SIP Proxies or
   back-to-back User Agents (B2BUAs) to see the transport application level
   information, or that it is seen unfeasible to establish separate
   dialogs (subscription) for transporting the information.  Consideration in this section MUST
   describe what happens if

   Annex A provides more information, and describes alternative
   mechanisms which one or both endpoints encrypt should consider for solving the payload.

7.2. specific use-
   case.

7.3.  Info Package Name

   This section, which

   The Info Package specification MUST be present, defines define an Info Package name.

   The specification MUST also define the token name that
   designates header field value to be used
   to indicate support of this package in the Info Package. Recv-Info and Info-Package
   header fields.  The name header field value MUST conform to the token ABNF
   production described
   defined in Section 8.  It 8.2.

   The specification MUST also include the information that appears in
   the IANA registration of the token.  For information on registering
   such types, see Section 9.

7.3. **9.

7.4.  Info Package Parameters

   If

   The Info Package specification MAY define Info Package parameters
   which can be used in the "Info-Package" Recv-Info or Info-Package header allows parameters to modify fields,
   together with the behavior
   of header field value representing the Info Package, this section Package.

   The specification MUST clearly define describe the syntax and semantics of such parameters.

7.4.  Info Package Tags

   If useful for the Info Package to have SIP option tags, this
   parameters.  It MUST be specified whether a specific parameter is the
   place
   only applicable to define the tag. Recv-Info header, the Info-Package header, or
   both.

   Note that if the Info Package defines a SIP
   option tag, parameters are only applicable for the Info
   Package(s) for which they have been explicitly defined.  If used for
   other Info Packages they MUST be discarded.

7.5.  SIP Option Tags

   The Info Package must specification MAY define SIP option tags, which can
   be used as described in [RFC3261].

   SIP option tags MUST conform to the SIP Change Process [RFC3427].

7.5.

7.6.  INFO Message Bodies

   Each

   The Info Package specification MUST define what type or types of bodies message
   bodies, if any, are
   expected in INFO requests.  Such packages associated with the Info Package, and MUST specify or cite
   detailed refer
   to specifications for where the syntax and syntax, semantics associated with
   such a body.

   The UAS MUST enumerate every and MIME type associated with the Info
   Packages advertised in the UAS' Recv-Info header of the UAS is willing
   to receive.  If a UAC sends a
   message body that includes something not
   enumerated by the UAS, this is a protocol error and the UAS MUST
   respond appropriately.

7.6.  UAC generation of INFO requests

   Each described.

7.7.  Info Package Usage Restrictions

   The Info Package specification MUST describe the process by which define whether a UA generates
   and sends an INFO request.  This includes detailed information about
   what events cause the UA is allowed to
   send an INFO request.

   If the Info Package does not allow overlapping (outstanding) INFO
   requests, requests associated with the Info Package MUST disclose this in
   Package, or whether the section
   describing UA generation of INFO requests.  Note the generic protocol
   machinery of the INFO method has no way of enforcing such to wait for the response for a
   requirement.  Section 7.7 describes this situation.

7.7.  UAS processing of
   previous INFO requests

   The Info Package MAY describe request associated with the process followed by same Info Package.

   The specification MUST define whether there SIP level restrictions in
   the UA upon
   receipt usage of the Info Package.  For example, an INFO request.  Since INFO does not change SIP state,
   and Info Package may not even change application state,
   require support of other SIP extensions (e.g. reliable provisional
   responses).

   The specification MUST define whether there may be no useful
   guidance required in are restrictions on
   indicating support of, or using, the Info Package specification for UA
   processing. together with other
   Info Packages.

   If the info Info Package does not permit overlapping INFO requests, it is
   important to note the issuance of restrictions are violated (i.e. if overlapping INFO
   requests is an
   application-layer protocol failure and are not an INFO method failure.
   Therefore, in the event a UAC issues overlapping INFO requests allowed for an Info Package, but a UA still receives
   overlapping requests), the UAS UA MUST NOT return an error response as a result
   of reject such requests.  Instead
   the overlapping INFO request.  Of course, if there are other
   problems application logic associated with the request that results in a failure, the UAC issues
   the appropriate response code.  This section of the Info Package
   specification MUST describe the application level response to
   overlapping INFO requests.  Examples include a new INFO request back
   to the offending UAC indicating an application error, ignoring the
   overlapping request and processing it to the UAS' best effort, or
   terminating the entire SIP session. handle
   such situations.

7.8.  Rate of INFO Requests

   Each

   The Info Package specification MUST define a requirement of MUST strength which
   defines an absolute maximum on the rate at which an INFO
   requests associated with the specific Info Package of a
   given type can generate INFO messages be generated
   by a UA in a session.

   If possible, a package MUST dialog.

   The specification MAY define a throttle mechanism that allows
   UAs Info Package parameters to further limit be used for
   indicating or negotiating the rate of INFO messages. request rate.  Alternatively the
   rate information can be included in the application information
   associated with the Info Package.

7.9.  IANA Registrations

   The Info Package specification MUST have contain an IANA Considerations
   section that includes definitions for the Info Package Name and, if
   needed, supported MIME types.

7.10.  Security Considerations

   The INFO mechanism transports

   If the application information associated with the Info Package
   requires certain level information.  One
   implication of this is INFO messages may require a higher level of
   protection than the underlying SIP-based session signaling.  If the
   application transports sensitive information, such as credit card
   numbers, health history, personal identifiers, and so on, security, the Info Package specification
   MUST document describe the mechanisms to be used in order to provide the
   required security.

   Otherwise, even if no additional security procedures that exceed than what is provided for
   the default
   procedures presented underlying SIP protocol is needed, it SHALL be stated in this document. the Info
   Package specification.

   NOTE: In most circumstances, some cases, it is may not be sufficient for a package to attempt to mandate TLS for the
   signaling channel in order
   to secure the data carried by the INFO.
   Intermediaries Info Package payload, since intermediaries will have
   access to the payload and past the first hop, there is no way to
   assure subsequent hops will not transmit forwards the payload in clear text.
   The only best way to ensure secure transport at the application level is
   to have the security at the application level.  The most common
   method of achieving this is to use end-to-end security techniques
   such as S/MIME [RFC3851].  If

7.11.  Application Procedures

   The Info Package specification SHOULD contain a description of the
   application
   demands this level of security, procedures associated with the Info Package definition MUST
   indicate such.

7.11. Package, or
   alternatively refer to application procedures defined elsewhere.

7.12.  Examples

   We RECOMMEND

   It is RECOMMENDED that Info Packages Package specifications include several
   demonstrative message flow
   diagrams diagrams, paired with several typical, syntactically correct, and complete messages.

   Documents describing Info Packages MUST clearly indicate the examples
   are informative messages
   and not normative, with instructions message descriptions.

   Note that
   implementers refer to the main example flows are by definition informative, and MUST NOT
   replace normative text of the document for exact
   protocol details.

8.  Syntax

8.1.  General

   This section Section describes the syntax extensions required for the INFO
   method.  The previous sections describe the semantics.  Note the
   formal syntax definitions described in this document use the ABNF
   format used in SIP [RFC3261] and contain references to elements defined
   therein.

8.2.  ABNF

   INFOm               = %x49.4E.46.4F ; INFO in caps
   extension-method    = INFOm / token

   Info-Package        =  "Info-Package" HCOLON Info-package-type
   Recv-Info           =  "Recv-Info" HCOLON Info-package-list
   Info-package-list   =  "nil"
                       / Info-package-type *( COMMA Info-package-type )
   Info-package-type   =  Info-package-name *( ";" Info-package-param)
   Info-package-name   =  token
   Info-package-param  =  token  generic-param

   NOTE on the Recv-Info production: if the header field value is "nil", there can be
   one
   the header field MUST NOT contain any other Info Packages, and only the
   SIP message MUST NOT contain more than one Recv-Info header in the SIP message. field.

9.  IANA Considerations

9.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]

9.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]

9.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]

9.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.
   o  Reference: If there is a published specification describing the
      Info Package, place a reference to that specification in this
      column.  See below for a discussion on this field.

   If there is a published specification, the registration MUST include
   a reference to such specification.  The Standards Status field is an
   indicator of the level of community review for the Info Package
   specification.  If the specification meets the requirements for
   Specification Required [RFC5226], the value for the Standards Status
   field is "Standards Track".  Otherwise, the field is empty.

   This document uses the Info Package Name "nil" to represent "no Info
   Package present" and as such, IANA shall not honor a request to
   register the "nil" Info Package.

   The initial population of this table shall be:

   Name         MIME Type                Standards Status      Reference
   nil                                    Standards Track      [RFCXXXX]

9.5.  Registration of the Info-Package Content-Disposition

   Please add the following registration to the Content-Disposition
   registry.  The description suitable for the IANA registry is as
   follows.

   The payload of the message carrying this Content-Disposition header
   field value is the payload of an Info Package.

9.6.  SIP Response Code 469 Registration

   Please register the 469 response code in the Session Initiation
   Protocol Parameters - Response Codes registry as follows.
   Response Code: 469
   Default Reason Phrase: Bad INFO Package
   Reference: RFCXXXX

10.  Examples

10.1.  Simple Info Package

   Here Alice sends Bob a simple Info Package payload.

   INFO sip:alice@192.0.2.1 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: 123456mcmxcix
   CSeq: 2 INFO
   Contact: <sip:bob@192.0.2.2>
   Info-Package: foo
   Content-type: application/foo
   Content-Disposition: Info-Package
   Content-length: 24

   I am a foo message type

10.2.  Multipart INFO Example

   Other SIP extensions can put payloads into an INFO method,
   independent of the Info Package.  In this case, the Info Package
   payload gets put into a Multipart MIME body, with the content
   disposition indicating which body belongs to the Info Package.  Since
   there is one and only one Info Package payload in the message, we
   only need to tag which body part goes with the Info Package.

   INFO sip:alice@192.0.2.1 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: 123456mcmxcix
   CSeq: 7 INFO
   Contact: <sip:bob@192.0.2.2>
   Info-Package: foo
   mumble-extension: <cid:abcd9999qq>
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Length: ...

   --theboundary
   Content-Type: application/mumble
   Content-Id: abcd9999qq
   ...

   <mumble stuff>

   --theboundary
   Content-Type: application/foo
   Content-Disposition: Info-Package
   Content-length: 24

   I am a foo message type
   --theboundary--

11.  Modifications to SIP Change Process

   This document updates RFC 3427 [RFC3427] to add a process for
   registering new Info Packages.  The process for registering new Info
   Packages follows the process outlined in Section 4.3 of RFC 3427 for
   the registration of SIP Event Packages.  Namely, the registration of
   a new SIP Info Package requires the DISPATCH chairs to assign an
   individual to perform expert review of the proposal if the work is
   not a RAI work item in itself.

12.  Security Considerations

   By eliminating multiple uses of INFO messages without adequate
   community review and by eliminating the possibility for rogue SIP
   User Agents UAs
   from confusing another User Agent by purposely sending unrelated INFO messages,
   requests, we expect this document's clarification of the use of INFO
   to improve the security of the Internet.  Whilst rogue UACs UAs can still
   send unrelated INFO messages, requests, this framework 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, User Agents
   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 mechanism transports application level information.  One
   implication of this is INFO messages may require a higher level of
   protection than the underlying SIP-based session 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 Framework 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 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.

13.

12.  References

13.1.

12.1.  Normative References

   [I-D.ietf-sip-body-handling]
              Camarillo, G., "Message Body Handling in the Session
              Initiation Protocol (SIP)",
              draft-ietf-sip-body-handling-06 (work in progress),
              March 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, 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.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section

   [I-D.ietf-sip-body-handling]
              Camarillo, G., "Message Body Handling in RFCs", BCP 26, RFC 5226,
              May 2008.

13.2.  Informative References

   [I-D.ietf-speechsc-mrcpv2]
              Shanmugham, S. and D. Burnett, "Media Resource Control the Session
              Initiation Protocol Version 2 (MRCPv2)",
              draft-ietf-speechsc-mrcpv2-19 (work in progress),
              June 2009.

   [I-D.saleem-msml]
              Sharratt, G. and A. Saleem, "Media Server Markup Language
              (MSML)", draft-saleem-msml-08 (SIP)",
              draft-ietf-sip-body-handling-06 (work in progress),
              February
              March 2009.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

12.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.

   [RFC2976]  Donovan, S., "The SIP INFO Method",

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 2976,
              October 2000. 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.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

   [RFC3372]  Vemuri, A. and J.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification",
              RFC 3851, July 2004.

   [RFC3725]  Rosenberg, J., Peterson, "Session J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol
              for Telephones (SIP-T): Context and Architectures", (SIP)",
              BCP 63, 85, RFC 3372, September 2002. 3725, April 2004.

   [RFC3427]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
              and B. Rosen, "Change Process for the Session Initiation
              Protocol (SIP)", BCP 67, RFC 3427, December 2002.

   [RFC3428]  Campbell, B.,

   [RFC3841]  Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [RFC3372]  Vemuri, A. and J. Peterson, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", Telephones (SIP-T): Context and Architectures",
              BCP 63, RFC 3428, December 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.

   [RFC3725]

   [RFC3428]  Campbell, B., Rosenberg, J., Peterson, J., Schulzrinne, H., Huitema, C.,
              and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session D. Gurle, "Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, April 2004.

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences (SIP) Extension
              for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
              Extensions (S/MIME) Version 3.1 Message Specification", Instant Messaging", RFC 3851, July 2004. 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.

   [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.

   [RFC4730]  Burger, E. and M. Dolly, "A Session Initiation Protocol
              (SIP) Event Package for Key Press Stimulus (KPML)",
              RFC 4730, November 2006.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

   [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.

   [W3C.REC-voicexml21-20070619]
              Porter, B., McGlashan, S., Lee, A., Burnett, D., Carter,
              J., Oshry, M., Bodell, M., Baggia, P., Rehor, K., Burke,
              D., Candell, E., and R. Auburn, "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>.

Appendix

   [I-D.ietf-speechsc-mrcpv2]
              Shanmugham, S. and D. Burnett, "Media Resource Control
              Protocol Version 2 (MRCPv2)",
              draft-ietf-speechsc-mrcpv2-19 (work in progress),
              June 2009.

   [I-D.saleem-msml]
              Sharratt, G. and A.  Info Package Considerations

   This section covers several issues that one should take into
   consideration when proposing new Info Packages.

A.1.  Appropriateness of Usage

   When designing an Info Package using the method described in this
   document for application level information exchange, it is important
   to consider: is INFO and, more importantly, is signaling within a SIP
   session, an appropriate mechanism for the problem set?  Is it because
   it is the most reasonable and appropriate choice, or merely because
   "it's easy"?

   These are difficult issues to consider, especially when presented
   with real-world deadlines and implementation cost issues.  However,
   choosing to use INFO for inappropriate uses *will* lead to issues in
   the real world, not the least of which are certain types of
   middleboxes which will remove the device from the network if it is
   found to cause damage to other SIP nodes.

   Therefore, the following sections provide consideration guidelines
   and alternatives to INFO use.

A.2.  Dialog Fate-Sharing

   INFO, by design, is a method within an INVITE dialog usage.  RFC 5057
   [RFC5057] enumerates the problems with using dialogs for multiple
   usages, and we strongly urge the reader to review RFC 5057.  The most
   relevant issue is a failure of transmission or processing of an INFO
   request may render the INVITE session terminated, depending on the
   type of failure.  Prior to RFC 5057, it was not clear if the INFO
   usage was a separate usage or not.  RFC 5057 clarifies the INFO
   method is always part of the INVITE usage.

   Some uses of INFO can tolerate this fate sharing of the INFO message
   over the entire session.  For example, in the SIP-T usage, it may be
   acceptable for a call to fail, or to tear down the call, if one
   cannot deliver the associated SS7 information.  The same is usually
   true for DTMF.  However, it may not be acceptable for a call to fail
   if, for example, a DTMF buffer overflows.  Then again, for some
   services, that may be the exact desired behavior.

A.3.  Messaging Rates and Volume

   There is no throttling mechanism for INFO.  Consider that most call
   signaling occurs on the order of 7-10 messages per 3 minutes,
   although with a burst of 5-7 messages in one second during call
   setup.  DTMF tones occur in bursts at a rate of up to 20 messages per
   second.  This is a considerably higher rate than for call signaling.
   Sending constant GPS location updates, on the other hand, would incur
   an undue burden on SIP Proxies along the path.

   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 MSRP [RFC4975], COMEDIA [RFC4145], or HTTP
   [RFC2616].

A.4.  Is there a better alternative?

   The first alternative for application level interaction is SIP
   Events, also known as SUBSCRIBE/NOTIFY [RFC3265].  In this model, a
   user agent 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.  The SUBSCRIBE creates a new session that does
   not share the fate of the related INVITE-initiated session.
   Moreover, using the SUBSCRIBE model enables multiple applications to
   receive state updates.  These applications can be outside the media
   path and potentially outside the INVITE-initiated session's proxy
   path.  In fact, SIUBSCRIBE/NOTIFY is your only option if you need to
   exchange data outside a communications session.

   SUBSCRIBE/NOTIFY messages pass through the SIP signaling
   infrastructure, such as SIP Proxies and B2BUAs.  Application
   designers need to understand this can be a feature, as when the User
   Agents are exchanging information that elements in the SIP signaling
   path need to be aware of.  Conversely, this can be a problem, as
   messages these network elements have no interest in can put a
   significant burden on those element's ability to process other
   traffic.  Moreover, such network elements may not be able to read
   end-to-end encrypted SUBSCRIBE or NOTIFY bodies.

   Implementers do need to be aware the price of having a protocol that
   works in all cases, can scale, can easily load balance, and will not
   mysteriously fail a session in the event of state synchronization
   failure does come at a cost.  Session establishment is a minimum of
   two messages in addition to the INVITE session establishment.  If the
   SUBSCRIBE application is co-resident with the INVITE application, the
   application will have to manage two SIP sessions instead of one.
   Tracking the application level state dominates memory and processing
   for some applications, and as such, the doubling of SIP sessions is
   not an issue.  However, for other applications, this may be an issue.

   The MESSAGE method [RFC3428] defines one-time instant message
   exchange, typically for sending MIME contents for rendering to the
   user.

   Another model for application level information exchange is to
   establish a communication channel in the media plane.  One model for
   this is MRCPv2 [I-D.ietf-speechsc-mrcpv2].  Here, the INVITE-
   initiated session establishes a separate reliable, connection-
   oriented channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream.
   One uses SIP to locate the remote endpoint, but uses a direct
   connection for the UUI.  One then can create whatever protocol one
   wishes, whether from scratch (as in MRCPv2) or using a substrate such
   as BEEP [RFC3080].

   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.  In addition, if there will be a lot of
   information exchanged, and there is no need for the SIP routing
   network to examine the information, one should use a separate media
   channel.

   Another model is to use a totally externally signaled channel, such
   as HTTP [RFC2616].  In this model, the user agent 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 RFC 4240 [RFC4240] or the encoding of a SUBMIT
   target in a VoiceXML [W3C.REC-voicexml21-20070619] script.

   MSRP [RFC4975] defines session-based instant messaging as well as
   bulk file transfer and other such large-volume uses.  It is part of
   an INVITE-based session, similar to other media.  Unlike INFO, MSRP
   follows a direct media path, rather than through the network elements
   composing the SIP signaling path.

   A common reason people in the past used INFO for application level
   information exchange is the negotiation is very lightweight compared
   to SUBSCRIBE/NOTIFY.  This is more especially so if it is not certain
   if there will be application level information exchange.  The
   SUBSCRIBE/NOTIFY machinery requires the user agents to exchange rich
   capabilities and maintain state for additional SIP sessions.
   However, this is a weak argument if there is a high likelihood of
   application level information exchange.  In this case, we recommend
   the use of a more robust application level information exchange
   protocol.

A.5.  Alternatives for Common INFO Use

   What alternatives to INFO are there for UA-to-UA application session
   signaling?  As noted above, there are three broad classes of session
   signaling available.  The choice depends on the circumstances.
   Following is a list of situations that have used INFO in the past.
   o  State updates
   o  User stimulus
   o  Direct signaling channel
   o  Proxy-aware signaling
   o  Dialog probe

A.5.1.  State Updates

   This is the broad class of one User Agent updating another with
   changes Saleem, "Media Server Markup Language
              (MSML)", draft-saleem-msml-08 (work in state.  The design goal of the SUBSCRIBE/NOTIFY [RFC3265]
   event framework is to meet just this need.

A.5.2.  User Stimulus: Touch Tones and Others progress),
              February 2009.

Appendix A.  Info Package Considerations

A.1.  General

   This is section covers considerations to take into account when deciding
   whether the class usage of the user entering stimulus at one User Agent,
   and the User Agent an Info Package is appropriate for transporting that stimulus to the other.  A key
   thing
   of application information for a specific use-case.

A.2.  Appropriateness of Info Package Usage

   When designing an Info Package, for application level information
   exchange, it is important to realize consider: is key presses on signaling, using INFO
   requests, within a SIP session, an appropriate mechanism for the telephone keypad use-
   case?  Is it because it is user
   stimulus.  Thus, the most reasonable and appropriate
   choice, or merely because "it's easy"?  Choosing an inappropriate
   mechanism to use here is KPML
   [RFC4730].

A.5.3.  Direct Signaling Channel

   State updates and user stimulus tend to have relatively few messages
   per session.  Sometimes, User Agents need to exchange a relatively
   high number of messages.  In addition, User Agents may have a need for a relatively low-latency exchange of messages.  In this latter
   case, specific use-case can cause negative effects in SIP
   networks where the User Agent may not be able mechanism is used.

A.3.  Dialog Fate Sharing

   As described in [RFC5057], an INFO request is always part of an
   INVITE dialog usage.

   One needs to tolerate consider the latency
   introduced by intermediate proxies.  Likewise, fate of the intermediate
   proxies may have no interest in processing all dialog usage of that data.

   In this case, establishing a separate, direct control channel, as in
   MSRP [RFC4975] or MRCPv2 [I-D.ietf-speechsc-mrcpv2] an INFO request
   is appropriate. rejected.  In addition, not every situation requires a SIP solution.  Some
   signaling is really just one-shot to third-party endpoints.  That
   situation some cases it may better be handled using an appropriate protocol, such
   as HTTP [RFC2616].

A.5.4.  Proxy-Aware Signaling

   Sometimes, one does want proxies to be in acceptable that the signaling path for UA-
   to-UA application signaling.  In this case, whole
   dialog useage is terminated, while in other cases is is desirable to
   maintain the use of a SIP request dialog usage.

A.4.  INFO Request Rate and Volume

   There is appropriate.  To date, there are no mechanisms default throttling mechanism for completely
   disambiguating INFO requests.  For example, one could create a
   registry of INFO packages.  The definition of the package would
   define the contexts for  Apart
   from the various MIME Content-Types, as well as session establishment, the context number of the request itself.  However, SIP messages exchanged
   during a package normal SIP session is rather small.

   Some applications, like sending of DTMF tones, can have
   multiple content types.  Moreover, having the context, or package
   identifier, at 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 whole session.

   Furthermore, SIP level precludes bundling multiple contexts
   responding in messages tend to be relatively small, on the same INFO request.  For example, a User Agent might
   want order
   of 500 Bytes to bundle two different responses in 32K Bytes.  SIP is a multipart/mixed MIME poor mechanism for direct
   exchange of bulk data beyond these limits, especially if the headers
   plus body
   type.

   Because there is no difference in either exceed the protocol machinery UDP MTU [RFC0768].  Appropriate mechanisms for
   such traffic include HTTP [RFC2616], MSRP [RFC4975], or
   registration process due to these factors, we will not create an INFO
   framework.  If one needs a other user
   plane data transport mechanisms.

A.5.  Alternative Mechanisms

A.5.1.  Alternative SIP User Agent-to-SIP User Agent signaling plane mechanisms

A.5.1.1.  General

   This subsection describes some alternative mechanisms for
   transporting application session information on the SIP signaling transport protocol that touches all
   Record-Route proxies in a path, one MUST create a new plane,
   using SIP method as
   described in Section 27.4 of RFC 3261 [RFC3261].

A.5.5.  Dialog Probe

   Some implementations in the wild use INFO to probe if an INVITE-
   initiated session is alive.  While this works, it messages.

A.5.1.2.  SUBSCRIBE/NOTIFY

   An alternative for application level interaction is NOT RECOMMENDED. SIP Events, also
   known as SUBSCRIBE/NOTIFY [RFC3265].  In particular, RFC 4028 [RFC4028] describes how this model, a user agent
   requests state information, such as key pad presses from a device to ensure
   an INVITE-
   initiated session is alive.

A.5.6.  Malicious Indicator

   Take the case of Malicious Indicator.  This is where application server or key map images from an application server to
   a subscriber
   receives device.

   A SUBSCRIBE requests creates a call, realizes it is new session, and a malicious call (threatening, SPIT,
   etc.).  They then press the SPIT button (or press *xx), subscription dialog
   usage [RFC5057], which tells
   their service provider to mark is separate, and does not share the UAC as a bad actor.  One might fate any
   other sessions.

   The subscription mechanism can be
   tempted used by SIP entities to think that INFO would be a great option for this service.
   It follows receive
   state information about SIP sessions, without requiring the return path entities
   to be part of the INVITE, route set of those sessions.

   As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies
   and so the INFO will hit
   the caller's inbound proxy, which it can learn B2BUAs, the caller is
   (statistically) a bad actor.  That way resource impact caused by the inbound proxy can do stuff
   like notify law enforcement, add a vote subscription sessions
   needs to "this is a SPIT source,"
   or other useful action.

   However, consider a few issues.  First, since INFO lives exclusively
   within an established session, there is no way be considred.  The number of subscription sessions per user
   also needs to assert this message
   after the call completes.  Second, this be considered.

   As for any other SIP signaling plane based mechanism relies for transporting
   application information, the SUBSCRIBE/NOTIFY messages can put a
   significant burden on an active
   service provider topology.  If there is no proxy intermediate SIP entities which are part of the
   session route set, but do not have any interest in the chain that
   will eat application
   information transported between the end users.

A.5.1.3.  MESSAGE

   The MESSAGE method [RFC3428] defines one-time instant message
   exchange, typically for sending MIME contents for rendering to the
   user.

A.5.2.  Media Plane Mechanisms

A.5.2.1.  General

   In SIP, media plane channels associated with SIP sessions are
   established using SIP signaling, but the INFO, data exchanged on the caller media
   plane channel does not traverse SIP signaling intermediates, so if
   there will see the "this is be a bad guy"
   message, which may have consequences in the real world.  Third, lot of information exchanged, and there is no a'priori way need
   for the UAS SIP signaling intermediates routing to know whether it can issue examine the INFO.
   The caller certainly will not advertise, "please tell me if I am bad,
   particularly I know in advance that I *am* a bad actor."

   One approach
   information, it is for the service provider's proxy recommended to SUBSCRIBE use a media plane mechanism, rather
   than a SIP signaling based.

   A low latency requirement for the
   SPIT event at the UAS.  At this point, life exchange of information is good, interoperable,
   and works across networks.  This enables events after one
   strong indicator for using a media channel.  Exchanging information
   through the session SIP routing network can introduce hundreds of
   milliseconds of latency.

A.5.2.2.  MRCPv2

   One mechanism for media plane exchange of application data is
   torn down, MRCPv2
   [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented
   channel, such as presumably the SPIT event will refer not to, "this
   session," which does not exist, but to "that session identifier,"
   which exists (and a TCP [RFC0793] or SCTP [RFC4960] stream is theoretically unique) forever.
   established.

A.5.2.3.  MRSP

   MSRP [RFC4975] defines session-based instant messaging as well as
   bulk file transfer and other such large-volume uses.

A.5.3.  Non-SIP related mechanisms

   Another approach that saves considerably on the overhead of
   subscriptions would be for the service provider alternative is to insert use a totally externally signaled channel,
   such as HTTP URI
   in the initial INVITE, noting it is for reporting malicious behavior.
   When the subscriber presses [RFC2616].  In this model, the SPIT button, an user agent knows about a
   rendezvous point to direct HTTP POST gets
   executed, delivering the call information requests to for the service provider.
   The service provider can encode basic call information transfer of
   information.  Examples include encoding of a prompt to retrieve in
   the HTTP SIP Request URI and can instruct the device to send whatever arbitrary data is
   necessary in [RFC4240] or the POST.  This method has the added benefit encoding of being
   entirely outside the real-time SIP proxy network. a SUBMIT target
   in a VoiceXML [W3C.REC-voicexml21-20070619] script.

Appendix B.  Legacy INFO Usages

   We do not intend this section to be a comprehensive catalog of INFO
   usages.  However, it should give the reader a flavor for current INFO
   usages.

B.1.  ISUP

   SIP-T uses Content-Type to identify ISUP protocol elements in an INFO
   message.  See RFC3372 [RFC3372].

B.2.  QSIG

   QSIG uses Content-Type to identify QSIG protocol elements in an INFO
   message.  See RFC4497 [RFC4497].

B.3.  MSCML

   MSCML uses a Require to ensure the UAS understands that INFO messages
   of the MSCML type are in fact MSCML messages.  See RFC5022 [RFC5022].

B.4.  MSML

   MSML endpoints just know the INFO messages carry MSML and from the
   Content-Type of the given INFO method request.  See the MSML
   [I-D.saleem-msml] draft.

B.5.  Video Fast Update

   Microsoft, Polycom, and Radvision used INFO messages as an interim
   solution for requesting fast video update before the ability to
   request I-Frames in RTCP was available.  See the XML Schema for Media
   Control [RFC5168] for more information.

Appendix C.  Acknowledgements

   We are standing on the shoulders of giants.  Jonathan Rosenberg did
   the original "INFO Considered Harmful" Internet Draft on 26 December
   2002, which influenced the work group and this document.  Likewise,
   Dean Willis influenced the text from his Internet Draft, "Packaging
   and Negotiation of INFO Methods for the Session Initiation Protocol"
   of 15 January 2003.  Four paragraphs come from Jonathan Rosenberg's
   INFO Litmus draft.  My, we have been working on this for a long time!

   This and other related drafts have elicited well over 450 messages on
   the SIP list.  People who have argued with its thesis, supported its
   thesis, added to the examples, or argued with the examples, include
   the following individuals:
      Adam Roach, Bram Verburg, Brian Stucker, Chris Boulton, Cullen
      Jennings, Dale Worley, Dean Willis, Frank Miller, Gonzalo
      Camarillo, Gordon Beith, Henry Sinnreich, James Jackson, James
      Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan
      Rosenberg, Juha Heinanen, 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, Salvatore Loreto, Sam Ganesan,
      Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg, and
      Xavier Marjou.

   John Elwell and Francois Audet helped with QSIG references.  In
   addition, Francois Audet provided actual text for the revised
   abstract.  Keith Drage gave lots of excellent comments and helped
   immensely with Figure 1.

   The work group version of this document benefited from the close
   readings and comments from
      John Elwell, Paul Kyzivat, Dean Willis, Francois Audet, Dale
      Worley, Andrew Allen, Adam Roach, Anders Kristensen, Gordon Beith,
      Ben Campbell, Bob Penfield, Keith Drage, Jeroen van Bemmel, Mary
      Barnes, and Salvatore Loreto.

   Since publication of the first work group version of this document,
   we have had over 329 messages.  New voices in addition to those
   included above include
      Arun Arunachalam, Christian Stredicke, Eric Rescorla, Inaki Baz
      Castillo, and Roni Evan.

   However, any errors and issues we missed are still our own.

Appendix D.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   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 headers 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, header field, greatly simplifying negotiation
   o  Multiple body part identification through Content-Disposition:
      Info-Package
   o  Note that forking INVITEs may result in multiple INFO's 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: