SIPCORE                                                        E. Burger
Internet-Draft                                             NeuStar, Inc.
Obsoletes: RFC 2976                                            H. Kaplan
(if approved)                                                Acme Packet
Expires: April 2, 26, 2010                                      C. Holmberg
                                                                Ericsson
                                                      September 29,
                                                        October 23, 2009

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

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 April 2, 26, 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 defines a new semantics method, INFO, 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, indicating support of, Session Initiation
   Protocol (SIP) [RFC3261], and exchanging an Info
   Packages that use Package mechanism.  The
   document obsoletes [RFC2976].  For backward compatibility the INFO method.  Applications that need to
   exchange application information within
   document also specifies a SIP invite "legacy" mode of usage dialog
   (RFC 5057), can use these Info Packages.  This document replaces RFC
   2976 but still allows existing legacy of the INFO usages as method
   that is compatible with the usage previously defined in RFC
   2976. [RFC2976],
   referred to as "legacy INFO Usage" in this document.

Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
   The terminology in this document conforms to the Internet Security
   Glossary [RFC4949].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Info Package Support . . . . . . . . . . . . . . . . . . . . .  7  6
     3.1.   General . . . . . . . . . . . . . . . . . . . . . . . . .  7  6
     3.2.   User Agent Behavior . . . . . . . . . . . . . . . . . . .  7  6
     3.3.   Package Versioning  . . . . . . . . . . . . . . . . . . . .  8  7
     3.4.   REGISTER Processing . . . . . . . . . . . . . . . . . . .  8  7
     3.5.   OPTIONS Processing  . . . . . . . . . . . . . . . . . . . .  8
     3.6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  The INFO Method  . . . . . . . . . . . . . . . . . . . . . . .  9  8
     4.1.   General . . . . . . . . . . . . . . . . . . . . . . . . . 10  8
     4.2.   INFO Request  . . . . . . . . . . . . . . . . . . . . . . . 10  8
     4.3.   INFO Request Message Body . . . . . . . . . . . . . . . . 11  9
     4.4.   INFO Response . . . . . . . . . . . . . . . . . . . . . . 12 10
     4.5.   INFO Response Message Body  . . . . . . . . . . . . . . . . 12 11
     4.6.   Order of Delivery . . . . . . . . . . . . . . . . . . . . 12 11
   5.  Formal INFO Method Definition  . . . . . . . . . . . . . . . . 13 11
     5.1.   INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13
     5.2. 11
   6.  INFO Header Fields . . . . . . . . . . . . . . . . . . . . 14
       5.2.1.  Info-Package header field . . 13
     6.1.   General . . . . . . . . . . . . 15
       5.2.2.  Recv-Info header field . . . . . . . . . . . . . 13
     6.2.   Info-Package header field . . . 15
   6.  Legacy INFO Usage . . . . . . . . . . . . . 13
     6.3.   Recv-Info header field  . . . . . . . . . . 15 . . . . . . . 14
   7.  Info Package Requirements  . Considerations  . . . . . . . . . . . . . . . . . 16 14
     7.1.   General . . . . . . . . . . . . . . . . . . . . . . . . . 16 14
     7.2.  Applicability   Appropriateness of Info Package Usage . . . . . . . . . . 14
     7.3.   Dialog Fate Sharing . . . . . . . . . . . . 16
     7.3.  Info Package Name . . . . . . . 14
     7.4.   INFO Request Rate and Volume  . . . . . . . . . . . . . 17
     7.4.  Info Package Parameters . 14
     7.5.   Alternative Mechanisms  . . . . . . . . . . . . . . . . 17
     7.5. . 15
       7.5.1.  Alternative SIP Option Tags signaling plane mechanisms . . . . . . 15
       7.5.2.  Media Plane Mechanisms . . . . . . . . . . . . . . . 17
     7.6.  INFO Message Bodies . 16
       7.5.3.  Non-SIP related mechanisms . . . . . . . . . . . . . . 17
   8.  Syntax . . . . 17
     7.7.  Info Package Usage Restrictions  . . . . . . . . . . . . . 17
     7.8.  Rate of INFO Requests . . . . . . . . . . . . 17
     8.1.   General . . . . . . 18
     7.9.  IANA Registrations . . . . . . . . . . . . . . . . . . . 17
     8.2.   ABNF  . 18
     7.10. Security Considerations . . . . . . . . . . . . . . . . . 18
     7.11. Application Procedures . . . . . . . . 17
   9.  Legacy INFO Usage  . . . . . . . . . . 19
     7.12. Examples . . . . . . . . . . . . 17
     9.1.   General . . . . . . . . . . . . . 19
   8.  Syntax . . . . . . . . . . . . 17
     9.2.   Problems  . . . . . . . . . . . . . . . . 19
     8.1.  General . . . . . . . . 18
     9.3.   Co-existence with Info Package based INFO usage . . . . . 18
   10. Info Package Requirements  . . . . . . . . . . . . 19
     8.2.  ABNF . . . . . . 19
     10.1.  General . . . . . . . . . . . . . . . . . . . . . 19
   9.  IANA Considerations . . . . 19
     10.2.  Applicability . . . . . . . . . . . . . . . . . 20
     9.1.  Update to Registration of SIP INFO Method . . . . . 19
     10.3.  Info Package Name . . . 20
     9.2.  Registration of the Info-Package Header Field . . . . . . 20
     9.3.  Registration of the Recv-Info Header Field . . . . . . . . 20
     9.4.  Creation of the Info Packages Registry . . . 19
     10.4.  Info Package Parameters . . . . . . . 20
     9.5.  Registration of the Info-Package Content-Disposition . . . 21
     9.6.  SIP Response Code 469 Registration . . . . . . . 20
     10.5.  SIP Option Tags . . . . . 21
   10. Examples . . . . . . . . . . . . . . . . 20
     10.6.  INFO Message Bodies . . . . . . . . . . . 21
     10.1. Simple Info Package . . . . . . . . 20
     10.7.  Info Package Usage Restrictions . . . . . . . . . . . 21
     10.2. Multipart INFO Example . . 20
     10.8.  Rate of INFO Requests . . . . . . . . . . . . . . . . 22
   11. Modifications to SIP Change Process . . 21
     10.9.  IANA Registrations  . . . . . . . . . . . 23
   12. References . . . . . . . . 21
     10.10. Info Package Security Considerations  . . . . . . . . . . 21
     10.11. Application Procedures  . . . . . . . . 24
     12.1. Normative References . . . . . . . . . 22
     10.12. Examples  . . . . . . . . . . 24
     12.2. Informative References . . . . . . . . . . . . . . 22
   11. IANA Considerations  . . . . 25
   Appendix A.  Info Package Considerations . . . . . . . . . . . . . 27
     A.1.  General . . . . 22
     11.1.  Update to Registration of SIP INFO Method . . . . . . . . 22
     11.2.  Registration of the Info-Package Header Field . . . . . . 22
     11.3.  Registration of the Recv-Info Header Field  . . . . . . . 27
     A.2.  Appropriateness 23
     11.4.  Creation of the Info Package Usage Packages Registry  . . . . . . . . . 23
     11.5.  Registration of the Info-Package Content-Disposition  . 27
     A.3.  Dialog Fate Sharing . 24
     11.6.  SIP Response Code 469 Registration  . . . . . . . . . . . 24
   12. Examples . . . . . . . 27
     A.4.  INFO Request Rate and Volume . . . . . . . . . . . . . . . 27
     A.5.  Alternative Mechanisms . . . . . 24
     12.1.  Indication of which Info Packages UAs are willing to
            receive INFO requests within an invite dialog usage . . . 24
     12.2.  INFO request with information associated with a
            simple Info Package . . . . . . . . . . . . . . . . . . 28
       A.5.1.  Alternative SIP signaling plane mechanisms . 25
     12.3.  Multipart INFO Example  . . . . . . . 28
       A.5.2.  Media Plane Mechanisms . . . . . . . . . . 25
   13. Security Considerations  . . . . . . 29
       A.5.3.  Non-SIP related mechanisms . . . . . . . . . . . . . 26
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 27
     14.2.  Informative References  . . . . . . . . . . . . . . . 29 . . 28
   Appendix B. A.  Legacy INFO Usages  . . . . . . . . . . . . . . . . . 29
     B.1.  ISUP 30
     A.1.   General . . . . . . . . . . . . . . . . . . . . . . . . . 30
     A.2.   ISUP  . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     B.2.
     A.3.   QSIG  . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     B.3.
     A.4.   MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     B.4.
     A.5.   MSML  . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     B.5. 31
     A.6.   Video Fast Update . . . . . . . . . . . . . . . . . . . . 30 31
   Appendix C. B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 30 31
   Appendix D. C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33

1.  Introduction

   [RFC3261]

   This document defines a mechanism to setup and tear down SIP sessions.  A
   SIP User Agent (UA) can use the re-INVITE and UPDATE methods during a
   session to change characteristics of the session, including media
   properties, target information or properties related to new method, INFO, for the SIP
   session timer mechanism [RFC4028]. Session Initiation
   Protocol (SIP) [RFC3261].

   The purpose of the INFO message [RFC2976] is to carry application level
   information between endpoints, using the SIP session dialog signaling path.
   Note that the INFO method is not used to update characteristics of the a
   SIP dialog or session, but to allow the applications which use the
   SIP session to exchange information.

   While information (which may update the INFO method has been widely adopted for specific
   application use cases, such as ISUP and DTMF exchange, [RFC2976] does
   not define state of
   those applications).

   This document also defines an Info Package mechanism.  An Info
   Package specification defines the content and semantics of the
   information carried in an INFO message associated with the Info
   Package.  The Info Package mechanism also provides a mechanisms way for SIP UAs to indicate what usages of INFO
   for which Info Packages they support.  In addition, [RFC2976] does not provide a mechanism are willing to
   explicitly indicate receive INFO requests.
   The document defines how the type of application INFO method is used, new SIP header
   fields for which the INFO
   message is used.  In some cases it can be determined by method, and how to transport payload information
   associated with an Info Package using INFO requests.

   Use of the INFO
   message body content, but method does not in a general way.

   Example: If the Content-Type is "image/jpeg", the MIME-attached
   content is constitute a JPEG image.  Still, there separate dialog usage.
   INFO messages are many useful ways a UA can
   render always part of, and share the fate of, an image.  The image could invite
   dialog usage [RFC5057].  INFO messages cannot be sent as part of
   other dialog usages.

   A UA uses the Recv-Info header field, on a caller-id picture, a contact
   icon, a photo per-dialog basis, to
   indicate for sharing, and so on.  The sender does not know which
   image to send Info Packages it is willing to the receiver if the receiver supports receive INFO
   requests.  A UA can indicate an image
   content type.  Likewise, the receiver does not know initial set of Info Packages during
   dialog establishment and can indicate a new set during the context lifetime
   of an
   image the client is sending if invite dialog usage.

   NOTE: A UA can use the receiver supports receiving more
   than one image content type.

   Due Recv-Info header field with a 'nil' value to the problems described above, the usage of INFO often requires
   static configuration about what
   indicate that it is not willing to receive INFO usages the requests for any
   Info-Package, but to inform other UAs support, and the
   way that it still supports the handle application information transported in INFO messages.
   That has caused Info
   Package mechanism.

   When a big risk interoperability problems in UA sends an INFO request, it uses the industry,
   due Info-Package header
   field to undefined content syntax, semantics and UA support of indicate which Info Package is associated with the request.
   One particular INFO
   messages.  Therefore, there is request can only be associated with a need single Info
   Package.

   This document obsoletes [RFC2976].  However, for backward
   compatibility it specifies a well defined and
   documented description "legacy" mode of usage of what the information sent in the INFO
   method that is
   used for.  This situation is identical to compatible with the context issue usage previously defined in
   Internet Mail [RFC3458].
   [RFC2976], referred to as "legacy INFO Usage" in this document.

2.  Applicability

   This document defines a mechanism, using Info Packages, which
   provides the possibility new method, INFO, for UAs to indicate what INFO usages they
   support, and to define content syntax the Session Initiation
   Protocol (SIP) [RFC3261], and semantics for an Info Package mechanism.  The
   document obsoletes [RFC2976].  For backward compatibility the data
   transported in
   document also specifies a "legacy" mode of usage of the INFO messages.  The mechanism allows existing
   legacy INFO usages as method
   that is compatible with the usage previously defined in RFC 2976.  New [RFC2976],
   referred to as "legacy INFO usages MUST use
   the mechanism defined Usage" in this document.

   Event Packages [RFC3265] perform the role of disambiguating the
   context of a message for subscription-based events.  The

3.  Info Package
   mechanisms provides similar functionality Support

3.1.  General

   This section describes how SIP UAs indicate for application information
   exchange using invite dialog usages [RFC5057].

   Note that while which Info Packages may be similar to subscription-based
   events, there is no formal relationship between this mechanism and
   the subscription mechanism.

   The Info Package mechanism does not create a separate dialog usage.
   INFO messages
   they are always part of, and share the fate of, an invite
   dialog usage. willing to receive INFO message can not be sent as part of other dialog
   usages, and they can not be sent outside an existing session.

   If a requests.

3.2.  User Agent Behavior

   A UA which supports the Info Package mechanism it indicates, MUST indicate, using
   the
   Recv-Info Revc-Info header field which field, the set of Info Packages for which it is
   willing to receive,
   on a per-session basis. receive INFO request.  A UA can indicate list multiple Info
   Packages in a new set single Recv-Info header field, and the UA can use
   multiple Recv-Info header fields.

   The indication of Info Packages
   at any time can take place during the lifetime of the invite dialog usage of the
   session.  A UA can use
   establishment, and during a "nil" value target refresh.  This includes INVITE,
   UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx
   only).  Note that the UAC is not required to indicate that it its set of Info
   Packages in the initial INVITE request.

   If a UA is not willing to receive INFO requests for any Info Packages at Packages, during
   dialog establishment or later during the invite dialog usage, the UA
   MUST indicate this by including a certain moment, but Recv-Info header field with a 'nil'
   value.  This informs other UAs that the UA still supports the Info
   Package mechanism.

   When

   Example: If a UA sends an INFO request, it uses the Info-Package header
   field to indicate which has previously indicated Info Package is associated with Packages 'foo' and
   'bar', and the request.

   Section 3 describes UA during the mechanism to indicate support lifetime of Info
   Packages.

   Section 4 describes the invite dialog usage of INFO messages.

   Section 6 describes legacy usage of INFO, as defined in [RFC2976].

   Section 7 describes guidelines on how
   wants to define Info Packages.  This
   document indicate that it does not define any specific Info Packages.

   Annex A provides guidelines and issues want to consider when deciding if
   usage of receive INFO requests for
   any Info Packages is anymore, the most appropriate mechanism for UA sends a
   specific use-case.

2.  Applicability

   This document extends [RFC2976] to include target refresh request with
   a mechanism Recv-Info header field with a header value of 'nil'.

   Once a UA has indicated that it is willing to in SIP
   messages explicitly indicate the supported receive INFO requests
   for a specific Info Packages, Package, and a dialog has been established, the
   UA MUST be prepared to
   explicitly indicate what Info Package is receive INFO request associated with that Info
   Package.

   A UA MUST NOT send an INFO
   request.  The mechanism is backward compatible request associated with legacy usage of
   INFO, as defined in [RFC2976], and allows such usage.  New INFO
   usages MUST use the mechanism defined in this document.

3. an Info Package Support

3.1.  General

   This section describes how SIP UAs indicate which Info Packages they
   are
   until it has received an indication that the remote UA is willing to receive.

3.2.  User Agent Behavior

   A UA which supports the
   receive INFO requests for that Info Package mechanism MUST indicate Package, and a dialog has been
   established with the set
   of remote UA.

   If a UA indicates multiple Info Packages Packages, which provide similar
   functionality, it is willing to receive, using the Revc-Info header
   field.  A UA can list multiple Info Packages in a single Recv-Info
   header field, and the UA can use multiple Recv-Info header fields.

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

   Once a UA has indicated that it is willing to to receive a specific
   Info Package, and a dialog has been established, the UA MUST be
   prepared to receive INFO request associated with that Info Package.

   A UA MUST NOT send INFO request associated with Info Packages until
   it has received an indication priority order of which Info Packages the remote UA is
   willing to receive.

   If a UA indicates that it is willing to receive of multiple
   Info Packages, which provide similar functionality, it is not possible to
   indicate or that that the UA wishes to receive only receive INFO
   request for one of them. the Info Packages.  It is up to the application
   logic associated with the Info Packages, and specific Info Package
   descriptions to describe application behavior in such cases.

   If

   For backward compatibility purpose, even if a UA is not willing to receive any Info Packages, during session
   establishment or later during the session, the UA MUST indicate this
   by including a Recv-Info header field with a header value indicates support of 'nil'.
   This enables other UAs to detect that
   the UA Info Package mechanism, it is still supports allowed to enable legacy INFO
   usages Section 9.

   This document does not define a SIP option tag [RFC3261] for the Info
   Package mechanism.

   Example: If a UA has previously indicated support of Info Packages
   foo and bar, and the UA during the session wants to indicate that it
   does not want to receive any Info Packages anymore, the 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 UA indicates support
   the Info Package mechanism, it is still allowed to enable legacy
   usages of INFO.

   This document does not define a SIP option tag [RFC3261] for the Info
   Package mechanism.  However,  However, an Info Package specifications MAY specification can define
   option-tags
   an option-tag associated with the specific Info Package, as described
   in Section 7.5.

   Note that, for 10.5.

   For backward compatibility purpose, compatibility, if a UA indicates support of the INFO method,
   method using the Allow header field [RFC3261], it does not implicitly
   indicate support of the Info Package mechanism.  A UA MUST use the
   Recv-Info header field in order to indicate support of that it supports the Info
   Package mechanism.  Likewise, even if a UA uses the Recv-Info header
   field to indicate that it
   support supports the Info Package mechanism, in
   addition the UA MUST still also explicitly indicate support of the
   INFO method. method using the Allow header field.

3.3.  Package Versioning

   The Info Package mechanism does not support package versioning.
   Specific Info Package payloads MAY contain version information, which
   is handled by the applications associated wit with the Info Package, but
   that is outside the scope of the Info Package framework.

   Note: mechanism.

   NOTE: Even if an Info Package name contains version numbering (e.g.
   foo_v2), the Info Package mechanism does not distinguish a version
   number from the rest of the Info Package name.

3.4.  REGISTER Processing

   When

   This document allows a UA registers, it SHALL include to insert a Recv-Info header field in the a
   REGISTER request, and list request.  However, a UA SHALL NOT include a header value for
   a specific Info Package unless the specific Info Packages that Package
   specification describes how the header field value shall be
   interpreted and used by the registrar, e.g. in order to determine
   request targets.

   NOTE: Rather than using the Recv-Info header field in order to
   determine request targets, it supports.  The
   registrar MAY later is recommended to use the information more appropriate
   mechanisms, e.g. for forking decisions. based on [RFC3840].

3.5.  OPTIONS Processing

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

   A UA MUST NOT send INFO requests with supports to receive.

   NOTE: As for any other capability and extension, for a specific
   dialog UAs need to indicate which Info Packages based on the
   information the UA received in an OPTIONS request.  The Info Packages
   MUST be negotiated for each session.

3.6.  Example

   The UAC sends an INVITE request, where the UAC indicates that it is
   willing to receive Info Packages P and R.

   INVITE sip:bob@example.com SIP/2.0
   Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
   Max-Forwards: 70
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.example.com
   CSeq: 314159 INVITE
   Recv-Info: P, R
   Contact: <sip:alice@pc33.example.com>
   Content-Type: application/sdp
   Content-Length: ...

   ...

   The UAS sends a 200 OK response back to the UAC, where the UAS
   indicates that it is willing to receive Info 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 support Info Package P, the UAC decides to
   indicate in the ACK request that it is only willing to receive Info
   Package R, which the UAS also indicated support of.

   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

4.  The INFO Method
4.1.  General

   This section describes how they are willing to
   receive within that dialog.

4.  The INFO Method

4.1.  General

   This section describes the UA 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 in OPTIONS
   requests and during registration.

   The INFO method provides additional, application level information
   that can further enhance a SIP application.  Annex A gives more
   details on the types of application for which the usage of INFO is
   seen as appropriate.

   The rules and procedures in this Section apply to implementations and
   applications which support this.  Existing implementations of, and
   applications using, [RFC2976], may not follow the rules in this
   Section.  Because of backward compatibility purpose such cases MUST
   NOT be regarded as error behavior, or wrong protocol usage, but
   simply part of legacy INFO usage.

4.2.  INFO Request

   A

   When a UA sends an INFO request associated with an Info Package, it
   MUST include a an Info-Package header field, which field that indicates the which Info
   Package contained in the request, when it sends an INFO request
   carrying an Info Package.  An is associated with the request.  A specific INFO request can contain
   be used only for a single Info Package.  A  For a specific dialog, a UA
   MUST NOT send INFO requests associated with Info Packages for which that the
   remote entity UA has not indicated willingness
   (using the Recv-Info header filed) that it is willing to receive for the session. receive.

   A UA MAY can send an INFO in requests associated with a legacy INFO usage context.
   Section 9.  In such case there is no Info Package associated with the
   usage, and the INFO request does not contain an Info-Package header
   field.  In addition, the
   support of the legacy usage has not been negotiated using UA cannot use the Recv-
   Info Recv-Info header field.  See Appendix B for examples of field to
   indicate whether it is willing to receive INFO requests associated
   with that legacy usages. INFO usage.

   The INFO method MUST NOT be used outside an INVITE invite dialog usage.  The
   INFO method has no lifetime beyond its transaction or usage of its
   own.  Supported  UAs indicate, per-dialog basis, for which Info Packages they
   are negotiated on a per session basis, and the negotiation
   result MUST NOT willing to receive INFO requests.  The set of Info Packages
   cannot automatically be used for within other sessions.  If a UA receives an INFO
   request outside an existing dialog, the UA MUST response with a 481
   Call Does Not Exist error response. dialogs.

   Due to the possibility of forking, a UAC which which, during the early
   dialog phase indicates support of that it is willing to receive INFO requests
   for one or more Info Packages (using
   the Recv-Info header field) MUST be prepared to receive INFO
   requests associated with those Info Packages from multiple remote entities.
   UAs.  Note that different each remote entities UA can indicate a different sets set of Info
   Packages for which they are willing to receive. receive INFO request.

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

   The INFO request MUST NOT contain a Recv-Info header field.  The UA
   can only indicate the a set of Info Packages that for which it is willing to
   receive INFO requests by using the messages SIP methods (and their responses)
   listed in Section 3.

4.3.  INFO Request Message Body

   The purpose of the INFO request is to carry application level
   information between SIP UAs.  The application data associated with an
   Info Package SHOULD be is carried as a payload in the message body of the INFO
   request, unless the information can be retrieved from a SIP
   header field. using one or more body parts.

   Info Package specifications MUST describe the application level
   information associated with the Info Package.  Message  Each body payloads part MUST
   have a MIME type value value, and the syntax and content of the body part,
   defined.

   If a UA indicates that it is willing to receive a specific

   Each body part, when associated with an Info Package, it means that the UA also supports any associated message MUST have a
   Content-Disposition header field with an 'Info-Package' value
   assigned, in order to be able distinguish body MIME type parts associated with
   the Info Package.  However, the UA
   MUST still indicate support of those MIME types also in the Accept
   header filed, according to the procedures in [RFC3261]. Package from other body parts.

   NOTE: Some SIP extensions, which functions that are orthogonal to INFO, MAY INFO may insert body
   parts unrelated to the Info Package.  UAs MUST conform to [RFC3261]
   as updated by body-handling [I-D.ietf-sip-body-handling] to support
   multipart

   Body parts associated with specific MIME handling.

   Each message types may sometimes have
   specific Content-Disposition header field values defined for them.
   For example, for body (or parts with a 'text/plain' MIME a Content-
   Disposition header field with a 'render' value is often assigned.
   However, when a body part in the case of multipart MIME) INFO message is associated with an
   Info Package, it MUST
   contain always have a Content-Disposition header field
   with an 'Info-Package' header
   value, in order to in an easy way distinguish payloads associated
   with the value assigned.  The Info Package from other payloads.

   If
   specification defines how applications process the whole body part
   contents.

   If a SIP message body is contains multiple body parts, multipart body
   parts [RFC5621] are used to separate them.  If all body parts within
   a multipart body part are associated with the Info Package, the UA
   MUST insert
   multipart body part SHALL have a Content-Disposition header field
   with an 'Info-Package'
   header value in the SIP assigned to it.  However, each body part of
   within the message.  In that case, if multipart MIME is used, the UA does not need to insert an 'Info-
   Package' header value for the individual body parts.

   NOTE: To avoid corner cases with legacy INFO usage, the Info-Package
   header field is used to indicate the Info Package name, rather than
   to use part MUST still have a Content-Disposition
   header field parameter with an 'Info-Package' value assigned to them, in order
   to
   indicate avoid that the name.

4.4.  INFO Response

   If parser assigns a UA receives default Content-Disposition header
   value to the body part.

   NOTE: According to [RFC5621], body parts within a multipart are not
   implicitly assigned the Content-Disposition header field value of the
   multipart body part which they belong to.

   This document does not define Info Package specific rules on how body
   parts associated with Info Packages are to be inserted into multipart
   body parts, and what type of multiparts are used.  If an Info Package
   requires special rules regarding the usage of multipart body parts,
   the specification for that Info Package MUST specify such rules.

   UAs MUST conform to [RFC5621] to support multipart body parts.

   If a UA indicates that it is willing to receive a specific Info
   Package, the UA naturally also supports any associated message body
   part MIME type associated with the Info Package.  However, in
   addition the UA MUST still indicate support of those MIME types in
   the Accept header field, according to the procedures in [RFC3261].

   NOTE: To avoid corner cases with legacy INFO usage, the Info-Package
   header field is used to indicate the Info Package name, rather than
   to use a Content-Disposition header field parameter in order to
   indicate the name.

4.4.  INFO Response

   If a UA receives an INFO request, associated with an Info-Package
   that the UA has indicated willingness to receive, and the INFO
   request contains data associated with that Info-Package, the UA MUST
   send a 200 OK response.

   If a UA receives an INFO request, request for legacy usage, for which no Info-
   Package is associated (the INFO request does not contain an Info-
   Package header field), the UA MUST send a 200 OK response.

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

   If a UA receives an INFO request associated with an Info Package that
   the UA has not indicated willingness to receive, the UA MUST send a
   469 Bad INFO Package response. response Section 11.6.  In the terminology of
   Multiple Dialog Usages [RFC5057], this represents a Transaction Only
   failure.

   If a UA receives an INFO request for legacy usage, for which no Info-
   Package is associated (the INFO request does not contain an Info-
   Package header filed), the UA must send a 200 OK response.

   If a UA receives an INFO request, which does not match any existing
   INVITE dialog that does not match any existing
   invite dialog usage, the UA MUST send a 481 Call Leg/Transaction Does
   Not Exist response.

   If a UA receives an INFO request, which request that 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 UA does not
   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.5.  INFO Response Message Body

   The Info Package mechanism allows a SIP stack to generate a response
   to the an INFO request is normally generated by the SIP
   stack before the Info Package application data has been provided to
   the without application associated with the Info Package.  Therefore, an interaction.  As a result,
   Info
   Package MUST NOT define the inclusion of Packages cannot require a message body in an INFO
   response.

   If responses,
   require different response codes, or otherwise require the response
   to the INFO request to contain application that received information.  If the information
   application needs to send some information in the other direction, it MUST trigger can
   send a new INFO
   request, rather than using the response of request which contains the received INFO request. information.

4.6.  Order of Delivery

   The Info Package framework mechanism relies on the CSeq header field to detect
   if an INFO request is received out of order.

   If specific applications need additional mechanisms for order of
   delivery, those mechanisms, and related procedures, MUST must be specified
   as part of the associated Info Package, and possible sequence numbers
   etc MUST must be defined as application data.

5.  Formal INFO Method Definition

5.1.  INFO Method

   This document describes one new SIP method: INFO.  This document
   replaces the definition and registrations found in [RFC2976].

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

     Header                    Where    INFO
     ------                    -----    ----
     Accept                      R       o
     Accept-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.

6.  INFO Header Fields

6.1.  General

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

Header field where   ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR
------------------------------------------------------------------------
Info-Package   R      -   -   -   -   -   -   -   m*  -   -   -   -   -
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 requests
   associated with Info Packages.  The Info-Package header field is not
   applicable for legacy usage INFO requests [RFC2976].

                    Table 2: INFO-related Header Fields

5.2.1.

6.2.  Info-Package header field

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

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

5.2.2.

6.3.  Recv-Info header field

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

6.  Legacy INFO Usage

   A number of applications, standardized and proprietary, make use of
   INFO messages as defined in [RFC2976], without defined

7.  Info Packages
   the and a possibility to use SIP to indicate what INFO usages UAs are
   willing to use.  For backward compatibility purpose, this document
   does not deprecate such usage, and does not mandate Package Considerations

7.1.  General

   This section covers considerations to define Info
   Packages for existing usages.  However, any new take into account when deciding
   whether the usage of INFO SHALL
   use the an Info Package mechanism defined in this specification.

   Since legacy INFO usages to not have associated Info Packages, it is
   not possible to use the Recv-Info and Info-Package header fields appropriate for transporting
   of application information for
   legacy INFO usages.  That is, a UA can not use the Recv-Info header
   filed to indicate specific use-case.

7.2.  Appropriateness of Info Package Usage

   When designing an Info Package, for which legacy usages application level information
   exchange, it is willing important to receive consider: is signaling, using INFO
   requests, within a SIP dialog, an appropriate mechanism for the use-
   case?  Is it because it is the most reasonable and appropriate
   choice, or merely because "it's easy"?  Choosing an inappropriate
   mechanism for a UA specific use-case can not use cause negative effects in SIP
   networks where the Info-Package header to
   indicate for which legacy INFO usage mechanism is used.

7.3.  Dialog Fate Sharing

   As described in [RFC5057], an INFO request is associated
   with.

   NOTE: For legacy INFO usages, static configuration is often used always part of an
   INVITE dialog usage.

   One needs to
   define what specific legacy INFO usages UAs support.

   An INFO request associated with consider the fate of the dialog usage of an Info Package 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 the request
   SHALL
   is rejected.  In some cases it may be interpreted as being a legacy INFO acceptable that the whole
   dialog usage request.

   UAs are allowed is terminated, while in other cases is is desirable to enable both legacy
   maintain the dialog usage.

7.4.  INFO usages Request Rate and Info Package
   usages as part of the same session.

7.  Info Package Requirements

7.1.  General

   This Section provides guidance on how to define an Info Package, and
   what information needs to be provided.

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

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

   Info Package definitions SHALL address the issues defined in the
   following subsections, unless an issue Volume

   There is not applicable no default throttling mechanism for INFO requests.  Apart
   from the
   specific Info Package.

7.2.  Applicability

   The Info Package specification MUST describe why SIP session establishment, the Info Package
   mechanism, rather than some other mechanism, has been chosen for number of SIP messages
   exchanged during the
   specific use-case to transfer application information between lifetime a normal SIP
   endpoints.  Common reasons session is rather small.

   Some applications, like sending of DTMF tones, can be generate a requirement for burst
   of up to 20 messages per second.  Other applications, like constant
   GPS location updates, could generate a high rate of INFO requests
   during the lifetime of the invite dialog usage.

   Furthermore, SIP Proxies or
   back-to-back User Agents (B2BUAs) messages tend to see be relatively small, on the transport application
   information, or that it is seen unfeasible order
   of 500 Bytes to establish separate
   dialogs (subscription) 32K Bytes.  SIP is a poor mechanism for transporting direct
   exchange of bulk data beyond these limits, especially if the information.

   Annex A provides more information, and headers
   plus body exceed the UDP MTU [RFC0768].  Appropriate mechanisms for
   such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user
   plane data transport mechanisms.

7.5.  Alternative Mechanisms

7.5.1.  Alternative SIP signaling plane mechanisms

7.5.1.1.  General

   This subsection describes some alternative mechanisms which one should consider for solving the specific use-
   case.

7.3.  Info Package Name

   The Info Package specification MUST define an Info Package name.

   The specification MUST also define
   transporting application information on the header field value to be used SIP signaling plane,
   using SIP messages.

7.5.1.2.  SUBSCRIBE/NOTIFY

   An alternative for application level interaction is to indicate support of this package in use
   subscription-based events [RFC3265], which uses the Recv-Info SIP SUBSCRIBE and Info-Package
   header fields.  The header field value MUST conform to the ABNF
   defined in Section 8.2.

   The specification MUST also include the information
   NOTIFY methods.  Using that appears in mechanism, 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.

   Event Packages [RFC3265] perform the IANA registration role of disambiguating the token.  For information on registering
   such types, see Section **9.

7.4.  Info Package Parameters
   context of a message for subscription-based events.  The Info Package specification MAY define Info Package parameters
   which can be used in the Recv-Info or Info-Package header fields,
   together with the header field value representing the Info Package.

   The specification MUST describe the syntax
   mechanism provides similar functionality for application information
   exchange using invite dialog usages [RFC5057].

   While an INFO request is always part of, and semantics of shares the
   parameters.  It MUST be specified whether fate of, an
   existing invite dialog usage, a specific parameter SUBSCRIBE request creates a new
   session and a subscription dialog usage [RFC5057] which is
   only applicable to the Recv-Info header, the Info-Package header, or
   both.

   Note that Info Package parameters are only applicable for separate,
   and does not share the Info
   Package(s) for which they have been explicitly defined.  If used for fate any other Info Packages they MUST be discarded.

7.5.  SIP Option Tags sessions.

   The Info Package specification MAY define SIP option tags, which subscription-based mechanism can be used as described in [RFC3261]. by SIP option tags MUST conform entities to the
   receive state information about SIP Change Process [RFC3427].

7.6.  INFO Message Bodies

   The Info Package specification MUST define what type of message
   bodies, if any, are associated with the Info Package, dialogs and MUST refer
   to specifications where sessions, without
   requiring the syntax, semantics and MIME type entities to be part of the
   message body is described.

7.7.  Info Package Usage Restrictions

   The Info Package specification MUST define whether a UA is allowed to
   send overlapping (outstanding) INFO requests associated with route set of those dialogs
   and sessions.

   As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies
   and B2BUAs, the Info
   Package, or whether resource impact caused by the UA has subscription sessions
   needs to wait for the response for a
   previous INFO request associated with the same Info Package. be considered.  The specification MUST define whether there SIP level restrictions in
   the usage of the Info Package.  For example, an Info Package may
   require support number of subscription sessions per user
   also needs to be considered.

   As for any other SIP extensions (e.g. reliable provisional
   responses).

   The specification MUST define whether there are restrictions on
   indicating support of, or using, the Info Package together with other
   Info Packages.

   If Info Package restrictions are violated (i.e. if overlapping INFO
   requests are not allowed signaling plane based mechanism for an Info Package, but a UA still receives
   overlapping requests), the UA MUST NOT reject such requests.  Instead
   the transporting
   application logic associated with the Info Package MUST handle
   such situations.

7.8.  Rate of INFO Requests

   The Info Package specification MUST a maximum rate at which INFO
   requests associated with information, the specific Info Package SUBSCRIBE/NOTIFY messages can be generated
   by a UA in put a dialog.

   The specification MAY define Info Package parameters to be used for
   indicating or negotiating the INFO request rate.  Alternatively
   significant burden on intermediate SIP entities which are part of the
   rate information can be included
   dialog route set, but do not have any interest in the application
   information
   associated with transported between the Info Package.

7.9.  IANA Registrations end users.

7.5.1.3.  MESSAGE

   The Info Package specification MUST contain an IANA Considerations
   section that includes definitions MESSAGE method [RFC3428] defines one-time instant message
   exchange, typically for the Info Package Name and, if
   needed, supported sending MIME types.

7.10.  Security Considerations

   If contents for rendering to the application information
   ser.

7.5.2.  Media Plane Mechanisms

7.5.2.1.  General

   In SIP, media plane channels associated with SIP dialogs are
   established using SIP signaling, but the Info Package
   requires certain level of security, data exchanged on the Info Package specification
   MUST describe media
   plane channel does not traverse SIP signaling intermediates, so if
   there will be a lot of information exchanged, and there is no need
   for the mechanisms SIP signaling intermediates routing to be used in order to provide examine the
   required security.

   Otherwise, even if no additional security
   information, it is recommended to use a media plane mechanism, rather
   than what a SIP signaling based.

   A low latency requirement for the exchange of information is provided one
   strong indicator for using a media channel.  Exchanging information
   through the underlying SIP protocol routing network can introduce hundreds of
   milliseconds of latency.

7.5.2.2.  MRCPv2

   One mechanism for media plane exchange of application data is needed, it SHALL be stated in the Info
   Package specification.

   NOTE: In some cases, it may not be sufficient to mandate TLS in order
   to secure the Info Package payload, since intermediaries will have
   access to the payload MRCPv2
   [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented
   channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is
   established.

7.5.2.3.  MRSP

   MSRP [RFC4975] defines session-based instant messaging as well as
   bulk file transfer and past the first hop, there other such large-volume uses.

7.5.3.  Non-SIP related mechanisms

   Another alternative is no way to
   assure subsequent hops will not forwards use a totally externally signaled channel,
   such as HTTP [RFC2616].  In this model, the payload in clear text.
   The best way user agent knows about a
   rendezvous point to ensure secure transport at the application level is direct HTTP requests to have the security at for the application level.  The most common
   method transfer of achieving this is to use end-to-end security techniques
   such as S/MIME [RFC3851].

7.11.  Application Procedures

   The Info Package specification SHOULD contain a description
   information.  Examples include encoding of a prompt to retrieve in
   the
   application procedures associated with the Info Package, SIP Request URI in [RFC4240] or
   alternatively refer to application procedures defined elsewhere.

7.12.  Examples

   It is RECOMMENDED that Info Package specifications include
   demonstrative message flow diagrams, paired with complete messages
   and message descriptions.

   Note that example flows are by definition informative, and MUST NOT
   replace normative text the encoding of a SUBMIT target
   in a VoiceXML [W3C.REC-voicexml21-20070619] script.

8.  Syntax

8.1.  General

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

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  =  generic-param

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

9.  IANA Considerations  Legacy INFO Usage

9.1.  Update to Registration  General

   A number of SIP INFO Method

   Please update the existing registration in the SIP Methods applications, standardized and
   Response Codes registry under proprietary, make use of
   the SIP Parameters registry that
   states:

   Method: INFO
   Reference:   [RFC2976]

   to:

   Method: method as it was previously defined in [RFC2976], referred
   to as "legacy INFO
   Reference:   [RFCXXXX]

9.2.  Registration of the Info-Package Header Field

   Please add the following usage".

   For backward compatibility purpose, this document does not deprecate
   such usages, and does not mandate users to define Info Packages for
   such usages.  However, any new 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 usage of INFO SHALL use the Recv-Info Header Field

   Please add the following new SIP header field Info
   Package mechanism defined in the Header Fields
   subregistry under the this specification.

9.2.  Problems

   While legacy INFO usage has been widely adopted for specific
   application use cases, [RFC2976] did not define a mechanism for SIP Parameters registry.

   Header Name:   Recv-Info
   Compact Form:  (none)
   Reference:     [RFCXXXX]

9.4.  Creation
   UAs to indicate for which types of applications and contexts they
   support the Info Packages Registry

   Please create INFO method.  In addition, [RFC2976] did not provide a subregistry in
   mechanism to explicitly indicate 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 type of zero or more registered
      MIME types from the MIME Type Registry.
   o  Standards Status: Values are "Standards Track" or empty.  See
      below application and context
   for which a discussion and rules on this field.
   o  Reference: specific INFO message is associated.

   Example: If there the Content-Type is a published specification describing "image/jpeg", the
      Info Package, place a reference to that specification in this
      column.  See below for a discussion on this field.

   If there MIME-attached
   content is a published specification, the registration MUST include JPEG image.  Still, there are many useful ways a reference to such specification.  The Standards Status field is UA can
   render an
   indicator of the level of community review image.  The image could be a caller-id picture, a contact
   icon, a photo for sharing, and so on.  The sender does not know which
   image to send to the Info Package
   specification.  If receiver if the specification meets receiver supports an image
   content type.  Likewise, the requirements for
   Specification Required [RFC5226], receiver does not know the value for context of an
   image the Standards Status
   field is "Standards Track".  Otherwise, the field client is empty.

   This document uses sending if the receiver supports receiving more
   than one image content type.

   Since legacy INFO usages do not have associated Info Package Name "nil" to represent "no Info
   Package present" and as such, IANA shall Packages, it is
   not honor a request possible 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 use the Recv-Info and Info-Package Content-Disposition

   Please add header fields with
   legacy INFO usages.  That is, a UA cannot use the following registration Recv-Info header
   field to the Content-Disposition
   registry.  The description suitable indicate for the IANA registry which legacy INFO usages it is as
   follows.

   The payload of willing to
   receive INFO requests, and a UA cannot use the message carrying this Content-Disposition Info-Package header
   field value to indicate for which legacy INFO usage an INFO request is
   associated with.

   Due to the payload problems described above, legacy INFO usages often require
   static configuration about for what type of an Info Package.

9.6.  SIP Response Code 469 Registration

   Please register applications and contexts
   UAs support the 469 response code INFO method, and the way they handle application
   information transported in INFO messages.  That has caused
   interoperability problems in the industry.  Therefore, a need for a
   well defined and documented description of what the information sent
   in the 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 is used for has been identified.  This situation is
   analogous to the context issue in Internet Mail [RFC3458].

9.3.  Co-existence with Info Package

   Here Alice sends Bob a simple Info Package payload. based 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 usage

   As described in Section 4, an INFO
   Info-Package: foo
   Content-type: application/foo
   Content-Disposition: request associated with an Info
   Package always contains an Info-Package
   Content-length: 24

   I am a foo message type

10.2.  Multipart header field.  A legacy INFO Example

   Other SIP extensions can put payloads into
   request MUST NOT contain an Info-Package header field.

   UAs are allowed to enable both legacy INFO method,
   independent usages and Info Package
   usages as part of the same invite dialog usage.

   See Appendix A for examples of existing legacy INFO usages.

10.  Info Package.  In Package Requirements

10.1.  General

   This Section provides guidance on how to define an Info Package, and
   what information needs to be provided.

   If an Info Package extends or modifies the behavior described in this case,
   document, it MUST be described in the definition for that Info
   Package.  Info Package
   payload gets put into a Multipart MIME body, definitions should not repeat procedures
   defined in this specification, unless needed for clarification or
   emphasis purpose.

   Info Packages MUST NOT weaken any behavior designated with the content
   disposition indicating which body belongs "SHOULD"
   or "MUST" in this specification.  However, Info Packages MAY
   strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST"
   strength if applications associated with the Info Package.  Since
   there is one and only one Package requires
   it.

   Info Package payload definitions SHALL address the issues defined in the message, we
   only need to tag which body part goes with
   following subsections, or document why an issue is not applicable for
   the specific 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
   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

10.2.  Applicability

   The Info Package specification MUST describe why the Info Package
   mechanism, rather than some other mechanism, has been chosen for the
   specific use-case to transfer application information between SIP Change Process

   By eliminating multiple uses of INFO messages without adequate
   community review and by eliminating the possibility
   endpoints.  Common reasons can be a requirement for rogue SIP UAs
   from confusing another Proxies or
   back-to-back User Agent by purposely sending unrelated INFO
   requests, we expect this document's clarification of the use of INFO Agents (B2BUAs) to improve see the security of transported application
   information (which would not be the Internet.  Whilst rogue UAs can still
   send unrelated INFO requests, this framework case if the information was
   transported on a media path), or that it is not seen feasible to
   establish separate dialogs (subscription) in order to transport the
   information.

   Annex A provides more information, and describes alternative
   mechanisms for which the UAS and other security devices can filter one should consider for approved solving a specific use-case.

10.3.  Info
   Packages.

   If the content of the Package Name

   The Info Package payload is private, User Agents
   will need to use end-to-end encryption, such as S/MIME, to prevent
   access to specification MUST define a for Info Package name
   (e.g.  "Info Package for X").

   The specification MUST also define the content.  This is particularly important as transport
   of INFO is likely not header field value (e.g.
   "infoX") to be end-to-end, but through SIP proxies used to indicate support of this package in the Recv-
   Info and
   back-to-back user agents (B2BUA's), which Info-Package header fields.  The header field value MUST
   conform to the user may not trust. ABNF defined in Section 8.2.

   The INFO mechanism transports application level information.  One
   implication of this is INFO messages may require a higher level of
   protection than specification MUST also include the underlying SIP-based session signaling.  In
   particular, if one does not protect information that appears in
   the SIP signaling from
   eavesdropping or authentication and repudiation attacks, for example
   by using TLS transport, then IANA registration of the INFO request and its contents will token.  For information on registering
   such types, see Section 9.

10.4.  Info Package Parameters

   The Info Package specification MAY define Info Package parameters
   which can be vulnerable, as well.  Even with SIP/TLS, any SIP hop along used in the
   path from UAC to UAS can view, modify, Recv-Info or intercept INFO requests, as
   they can Info-Package header fields,
   together 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 header field value representing the application dictates Info Package.

   The specification MUST describe the level syntax and semantics of security required, individual
   Info Packages have the
   parameters.  It MUST be specified whether a specific parameter is
   only applicable to enumerate these requirements.  In any event, the Recv-Info header, the Info-Package header, or
   both.

   Note that Info Package mechanism described by this document provides the
   tools parameters are only applicable for such secure, end-to-end transport of application data.

   One interesting property of the Info Package use is one can reuse the
   same digest-challenge mechanism
   Package(s) for which they have been explicitly defined.  They MUST
   NOT be used for INVITE based authentication other Info Packages.

   NOTE: Info Package parameters defined for specific Info Packages may
   share the name with parameters defined for other Info Packages, but
   the parameter semantics are specific to the Info Package for which
   they are defined.

10.5.  SIP Option Tags

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

   SIP option tags MUST conform to the SIP Change Process
   [I-D.peterson-rai-rfc3427bis].

10.6.  INFO request.  For example, one could use a quality-of-
   protection (qop) value Message Bodies

   The Info Package specification MUST define what type of authentication message body
   parts are associated with integrity (auth-int),
   to challenge the request Info Package, and its body, MUST refer to
   specifications where the syntax, semantics and prevent intermediate
   devices from modifying MIME type of the body.  However this assumes
   message body parts are described.

   If multiple body parts are used with an Info Package, the device
   which knows Info
   Package specification MUST define whether there are special rules on
   how the credentials body parts are to be inserted in order multipart body parts, and
   what types of multipart to perform the INVITE challenge use.

10.7.  Info Package Usage Restrictions

   The Info Package specification MUST define whether a UA is still in the path for allowed to
   send overlapping (outstanding) INFO requests associated with the INFO, Info
   Package, or that whether the far-end UAS knows such
   credentials.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs UA has to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines wait 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.

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

12.2.  Informative References

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2976]  Donovan, S., "The SIP response for a
   previous INFO Method", RFC 2976,
              October 2000.

   [RFC4497]  Elwell, J., Derks, F., Mourot, P., and O. Rousseau,
              "Interworking between request associated with the Session Initiation Protocol
              (SIP) and QSIG", BCP 117, RFC 4497, May 2006.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

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

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

   [RFC3080]  Rose, M., "The Blocks Extensible Exchange Protocol Core",
              RFC 3080, March 2001.

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

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) same Info Package.

   The specification MUST define whether there are SIP level
   restrictions in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, April 2004.

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

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for Info Package.  For example, an Info
   Package may require support of other SIP extensions (e.g. reliable
   provisional responses).

   The specification MUST define whether there are restrictions on
   indicating support of, or using, the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [RFC3372]  Vemuri, A. and J. Peterson, "Session Initiation Protocol
              for Telephones (SIP-T): Context and Architectures",
              BCP 63, RFC 3372, September 2002.

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

   [RFC3458]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
              Context for Internet Mail", RFC 3458, January 2003.

   [RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

   [RFC4028]  Donovan, S. and J. Rosenberg, "Session Timers in Info Package together with other
   Info Packages.

   As the
              Session Initiation Protocol (SIP)", RFC 4028, April 2005.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport SIP stack may not be aware of Info Package specific
   restrictions, it cannot be assumed that overlapping requests would be
   rejected.  As defined in Section 4.4, in most cases a 200 OK response
   will be sent for the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [RFC4240]  Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
              Media Services INFO request.  The application logic associated
   with SIP", RFC 4240, December 2005.

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

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC4975]  Campbell, B., Mahy, R., and C. Jennings, "The Message
              Session Relay Protocol (MSRP)", RFC 4975, September 2007.

   [RFC5022]  Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
              Control Markup Language (MSCML) and Protocol", RFC 5022,
              September 2007.

   [RFC5057]  Sparks, R., "Multiple Dialog Usages in the Session
              Initiation Protocol", RFC 5057, November 2007.

   [RFC5168]  Levin, O., Even, R., and P. Hagendorf, "XML Schema for
              Media Control", RFC 5168, March 2008.

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

   [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. Saleem, "Media Server Markup Language
              (MSML)", draft-saleem-msml-08 (work in progress),
              February 2009.

Appendix A.  Info Package Considerations

A.1.  General

   This section covers considerations needs to take into account when deciding
   whether the usage handle situations which can occur due
   to overlapping requests.

10.8.  Rate of an INFO Requests

   The Info Package is appropriate for transporting
   of application information for specification MUST specify a maximum rate at which
   INFO requests associated with the specific use-case.

A.2.  Appropriateness of Info Package Usage

   When designing an can be
   generated by a UA in a dialog.

   The specification MAY define Info Package, for application level information
   exchange, it is important Package parameters to consider: is signaling, using INFO
   requests, within a SIP session, an appropriate mechanism be used for
   indicating or negotiating the use-
   case?  Is it because it is INFO request rate.  Alternatively the most reasonable and appropriate
   choice, or merely because "it's easy"?  Choosing an inappropriate
   mechanism for a specific use-case
   rate information can cause negative effects be included in SIP
   networks where the mechanism is used.

A.3.  Dialog Fate Sharing

   As described in [RFC5057], application information
   associated with the Info Package.

10.9.  IANA Registrations

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

10.10.  Info Package Security Considerations

   If the application information associated with the Info Package
   requires certain level of an
   INVITE dialog usage.

   One needs security, the Info Package specification
   MUST describe the mechanisms to consider be used in order to provide the fate of
   required security.

   Otherwise, even if no additional security than what is provided for
   the dialog usage of an INFO request underlying SIP protocol is rejected. needed, this fact SHALL be stated in
   the Info Package specification.

   NOTE: In some cases cases, it may not be acceptable that the whole
   dialog useage is terminated, while sufficient to mandate TLS in other cases is is desirable order
   to
   maintain secure the dialog usage.

A.4.  INFO Request Rate Info Package payload, since intermediaries will have
   access to the payload, and Volume

   There beyond the first hop, there is no default throttling mechanism for INFO requests.  Apart
   from way to
   assure subsequent hops will not forwards the session establishment, payload in clear text.
   The best way to ensure secure transport at the number of SIP messages exchanged
   during a normal SIP session application level is rather small.

   Some applications, like sending of DTMF tones, can generate a burst
   of up
   to 20 messages per second.  Other applications, like constant
   GPS location updates, could generate a high rate of INFO requests
   during have the whole session.

   Furthermore, SIP messages tend to be relatively small, on security at the order application level.  One way of 500 Bytes to 32K Bytes.  SIP achieving
   this is to use end-to-end security techniques such as S/MIME
   [RFC3851].

10.11.  Application Procedures

   The Info Package specification SHOULD contain a poor mechanism for direct
   exchange description of bulk data beyond these limits, especially if the headers
   plus body exceed the UDP MTU [RFC0768].  Appropriate mechanisms for
   such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user
   plane data transport mechanisms.

A.5.  Alternative Mechanisms

A.5.1.  Alternative SIP signaling plane mechanisms

A.5.1.1.  General

   This subsection describes some alternative mechanisms for
   transporting
   application information on procedures associated with the SIP signaling plane,
   using SIP messages.

A.5.1.2.  SUBSCRIBE/NOTIFY

   An 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 Info Package, or key map images from an application server
   alternatively refer to
   a device.

   A SUBSCRIBE requests creates a new session, and a subscription dialog
   usage [RFC5057], which application procedures defined elsewhere.

10.12.  Examples

   It is separate, recommended that Info Package specifications include
   demonstrative message flow diagrams, paired with complete messages
   and does not share the fate any
   other sessions.

   The subscription mechanism can be used message descriptions.

   Note that example flows are by SIP entities definition informative, and do not
   replace normative text

11.  IANA Considerations

11.1.  Update to receive
   state information about Registration of SIP sessions, without requiring INFO Method

   Please update the entities
   to be part of existing registration in the route set of those sessions.

   As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies Methods and B2BUAs, the resource impact caused by
   Response Codes registry under the subscription sessions
   needs to be considred.  The number SIP Parameters registry that
   states:

   Method:      INFO
   Reference:   [RFC2976]

   to:

   Method:      INFO
   Reference:   [RFCXXXX]

11.2.  Registration of subscription sessions per user
   also needs to be considered.

   As for any other the Info-Package Header Field

   Please add the following new SIP signaling plane based mechanism for transporting
   application information, header field in the Header Fields
   subregistry under the SUBSCRIBE/NOTIFY messages can put a
   significant burden on intermediate SIP entities which are part Parameters registry.

   Header Name:   Info-Package
   Compact Form:  (none)
   Reference:     [RFCXXXX]

11.3.  Registration of the
   session route set, but do not have any interest in Recv-Info Header Field

   Please add the application
   information transported between following new SIP header field in 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 Header Fields
   subregistry under 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 Parameters registry.

   Header Name:   Recv-Info
   Compact Form:  (none)
   Reference:     [RFCXXXX]

11.4.  Creation of the data exchanged on Info Packages Registry

   Please create a subregistry in the media
   plane channel does not traverse SIP signaling intermediates, so if
   there will be Parameters registry for Info
   Packages.  This subregistry has a lot of information exchanged, 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]

11.5.  Registration of the Info-Package Content-Disposition

   Please add the following new header field value to the Content-
   Disposition registry.
Name: info-package
Description: the body contains information associated with an Info Package
Reference: RFCXXXX

11.6.  SIP Response Code 469 Registration

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

12.  Examples

12.1.  Indication of which Info Packages UAs are willing to receive INFO
       requests within an invite dialog usage

   The UAC sends an INVITE request, where the UAC indicates that it is
   willing to receive Info Packages P and R.

   INVITE sip:bob@example.com SIP/2.0
   Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
   Max-Forwards: 70
   To: Bob <sip:bob@example.com>
   From: Alice <sip:alice@example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.example.com
   CSeq: 314159 INVITE
   Recv-Info: P, R
   Contact: <sip:alice@pc33.example.com>
   Content-Type: application/sdp
   Content-Length: ...

   ...

   The UAS sends a 200 OK response back to the UAC, where the UAS
   indicates that it is willing to receive Info 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: ...

  ...

   The UAC sends ACK.

   ACK sip:ngw1@a.example.com SIP/2.0
   Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754
   Max-Forwards: 70
   To: Bob <sip:bob@example.com>;tag=a6c85cf
   From: Alice <sip:alice@example.com>;tag=1928301774
   Call-ID: a84b4c76e66710@pc33.example.com
   CSeq: 314159 ACK
   Content-Length: 0

12.2.  INFO request with information associated with a 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
   Info-Package: foo
   Content-type: application/foo
   Content-Disposition: Info-Package
   Content-length: 24

   I am a foo message type

12.3.  Multipart INFO Example

   Other SIP extensions can sometimes add payload body parts into an
   INFO request, independent of the Info Package.  In this case, the
   Info Package payload gets put into a Multipart MIME body, with a
   Content-Disposition header field that indicates which body part is
   associated with the Info Package.

   INFO sip:alice@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
   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--

13.  Security Considerations

   By eliminating multiple usages of INFO messages without adequate
   community review and by eliminating the possibility for rogue SIP UAs
   from confusing another UA by purposely sending unrelated INFO
   requests, we expect this document's clarification of the use of INFO
   to improve the security of the Internet.  Whilst rogue UAs can still
   send unrelated INFO requests, this mechanism provides mechanisms for
   which the UAS and other security devices can filter for approved Info
   Packages.

   If the content of the Info Package payload is private, UAs will need
   to use end-to-end encryption, such as S/MIME, to prevent access to
   the content.  This is particularly important as transport of INFO is
   likely not to be end-to-end, but through SIP proxies and back-to-back
   user agents (B2BUA's), which the user may not trust.

   The INFO request transports application level information.  One
   implication of this is INFO messages may require a higher level of
   protection than the underlying SIP dialog signaling.  In particular,
   if one does not protect the SIP signaling from eavesdropping or
   authentication and repudiation attacks, for example by using TLS
   transport, then the INFO request and its contents will be vulnerable,
   as well.  Even with SIP/TLS, any SIP hop along the path from UAC to
   UAS can view, modify, or intercept INFO requests, as they can with
   any SIP request.  This means some applications may require end-to-end
   encryption of the INFO payload, beyond, for example, hop-by-hop
   protection of the SIP signaling itself.  Since the application
   dictates the level of security required, individual Info Packages
   have to enumerate these requirements.  In any event, the Info Package
   mechanism described by this document provides the tools for such
   secure, end-to-end transport of application data.

   One interesting property of Info Package use is one can reuse the
   same digest-challenge mechanism used for INVITE based authentication
   for the INFO request.  For example, one could use a quality-of-
   protection (qop) value of authentication with integrity (auth-int),
   to challenge the request and its body, and prevent intermediate
   devices from modifying the body.  However this assumes the device
   which knows the credentials in order to perform the INVITE challenge
   is still in the path for the INFO, or that the far-end UAS knows such
   credentials.

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC5621]  Camarillo, G., "Message Body Handling in the Session
              Initiation Protocol (SIP)", RFC 5621, September 2009.

14.2.  Informative References

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2976]  Donovan, S., "The SIP INFO Method", RFC 2976,
              October 2000.

   [RFC4497]  Elwell, J., Derks, F., Mourot, P., and O. Rousseau,
              "Interworking between the Session Initiation Protocol
              (SIP) and QSIG", BCP 117, RFC 4497, May 2006.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

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

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

   [RFC3080]  Rose, M., "The Blocks Extensible Exchange Protocol Core",
              RFC 3080, March 2001.

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

   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and there is no need G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the SIP signaling intermediates routing to examine Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, April 2004.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the
   information, it is recommended to use a media plane mechanism, rather
   than a SIP signaling based.

   A low latency requirement Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the exchange of information is one
   strong indicator Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [RFC3372]  Vemuri, A. and J. Peterson, "Session Initiation Protocol
              for using a media channel.  Exchanging information
   through Telephones (SIP-T): Context and Architectures",
              BCP 63, RFC 3372, September 2002.

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

   [RFC3458]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
              Context for Internet Mail", RFC 3458, January 2003.

   [RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

   [RFC4028]  Donovan, S. and J. Rosenberg, "Session Timers in the SIP routing network can introduce hundreds of
   milliseconds of latency.

A.5.2.2.  MRCPv2

   One mechanism
              Session Initiation Protocol (SIP)", RFC 4028, April 2005.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [RFC4240]  Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
              Media Services with SIP", RFC 4240, December 2005.

   [RFC4730]  Burger, E. and M. Dolly, "A Session Initiation Protocol
              (SIP) Event Package for media plane exchange of application data is MRCPv2
   [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented
   channel, such as a TCP [RFC0793] or SCTP Key Press Stimulus (KPML)",
              RFC 4730, November 2006.

   [RFC4960] stream is
   established.

A.5.2.3.  MRSP

   MSRP  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC4975] defines session-based instant messaging as well as
   bulk file transfer  Campbell, B., Mahy, R., and other such large-volume uses.

A.5.3.  Non-SIP related mechanisms

   Another alternative is to use a totally externally signaled channel,
   such as HTTP [RFC2616].  In this model, 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 user agent knows about a
   rendezvous point to direct HTTP requests to Session
              Initiation Protocol", RFC 5057, November 2007.

   [RFC5168]  Levin, O., Even, R., and P. Hagendorf, "XML Schema for
              Media Control", RFC 5168, March 2008.

   [I-D.peterson-rai-rfc3427bis]
              Peterson, J., Jennings, C., and R. Sparks, "Change Process
              for the transfer of
   information.  Examples include encoding of a prompt to retrieve Session Initiation Protocol (SIP)",
              draft-peterson-rai-rfc3427bis-03 (work in
   the SIP Request URI progress),
              September 2009.

   [W3C.REC-voicexml21-20070619]
              McGlashan, S., Lee, A., Carter, J., Porter, B., Auburn,
              R., Oshry, M., Rehor, K., Bodell, M., Burke, D., Baggia,
              P., Candell, E., and D. Burnett, "Voice Extensible Markup
              Language (VoiceXML) 2.1", World Wide Web Consortium
              Recommendation REC-voicexml21-20070619, June 2007,
              <http://www.w3.org/TR/2007/REC-voicexml21-20070619>.

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

   [I-D.saleem-msml]
              Saleem, A. and G. Sharratt, "Media Server Markup Language
              (MSML)", draft-saleem-msml-09 (work in [RFC4240] or the encoding progress),
              July 2009.

   [Ecma-355]
              "Standard ECMA-355 Corporate Telecommunication Networks -
              Tunnelling of a SUBMIT target
   in a VoiceXML [W3C.REC-voicexml21-20070619] script. QSIG over SIP", ECMA http://
              www.ecma-international.org/publications/standards/
              Ecma-355.htm, June 2008.

Appendix B. A.  Legacy INFO Usages

   We do not intend this

A.1.  General

   This section provides examples of existing legacy INFO usages.  This
   section is not meant to be a comprehensive catalog of legacy INFO
   usages.  However,
   usages, but it should give the reader a flavor for current legacy
   INFO usages.

B.1.

A.2.  ISUP

   SIP-T uses Content-Type to identify

   [RFC3372] specifies the encapsulation of ISUP protocol elements in an INFO
   message.  See RFC3372 [RFC3372].

B.2.  QSIG SIP message bodies.
   ITU-T and 3GPP have specified similar procedures.

A.3.  QSIG uses Content-Type to identify

   [Ecma-355] specifies the encapsulation of QSIG protocol elements in an SIP message bodies.

A.4.  MSCML

   [RFC5022] specifies how INFO
   message.  See RFC4497 [RFC4497].

B.3. is used as a transport mechanism by the
   MSCML protocol.  MSCML uses a an option-tag in the Require header field
   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 receiver understands the INFO messages carry content.

A.5.  MSML and from the
   Content-Type of the given

   [I-D.saleem-msml] specifies how INFO method request.  See us used as a transport mechanism
   by the MSML
   [I-D.saleem-msml] draft.

B.5. protocol.

A.6.  Video Fast Update

   Microsoft, Polycom, and Radvision used

   Companies have been using INFO messages as an interim
   solution for requesting fast video update before the ability in order to request I-Frames fast
   video update.  Currently a standardized mechanism, based on RTCP, has
   been specified in RTCP was available.  See the XML Schema for Media
   Control [RFC5168] for more information.

Appendix C. B.  Acknowledgements

   We are standing

   The work on this document was influenced by the shoulders of giants.  Jonathan Rosenberg did
   the original "INFO Considered
   Harmful" Internet Draft on 26 draft (26 December
   2002, which influenced the work group 2002) written by Jonathan Rosenberg, and this document.  Likewise,
   Dean Willis influenced
   by the text from his Internet Draft, "Packaging and Negotiation of INFO Methods for the Session
   Initiation Protocol"
   of 15 draft (15 January 2003.  Four paragraphs come from Jonathan Rosenberg's
   INFO Litmus draft.  My, we 2003) written by Dean Willis.

   The following individuals 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 involved in the following individuals: work, and have
   provided input and feedback on this document:
      Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben
      Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris
      Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean
      Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon
      Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James
      Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan
      Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard
      Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael
      Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain,
      Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore
      Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve
      Langstaff, Sumit Garg, Garg and Xavier Marjou. Marjoum.

   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 provided 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, Elwell and Salvatore Loreto.

   Since publication of Robert Sparks provided valuable feedback during the first work group version of this document,
   we have had over 329 messages.  New voices
   WGLC process, in addition order 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. prepare this document for publication.

Appendix D. C.  Change Log

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

   Changes from draft-ietf-sipcore-info-events-01
   o  Further changes based on WGLC comments
   o  Appending A moved into the main part of the document
   o  Section name changed from "Modifications to SIP Change Process" to
      "Security Considerations"
   o  "Syntax" section moved further up in the document
   o  Clarification on usage of Info Package related message body parts,
      and the usage of the Content-Disposition header field with those
      body parts
   o  Removed REFER and NOTIFY from the INFO Headers table
   o  Clarified usage of the Recv-Info header field in the REGISTER and
      OPTIONS requests
   o  Major re-write of the Introduction section
   o  Text about legacy INFO and subscription-based events moved from
      the Introduction to the main part of the document
   o  Wording about receiving Info-Packages has been replaced with
      wording about receiving INFO requests for Info-Packages
   o  The text about the usage of message body, and body parts,
      associated with Info Packages, has been clarified

   Changes from draft-ietf-sip-info-events-04
   o  Major re-write of the document, due to problems to implement WGLC
      comments into the existing text structure
   o  Wording allignment
   o  Clarification or roles

   Changes from draft-ietf-sip-info-events-03
   o  Clarified Abstract language
   o  All SIP dialogs are now refered to as sessions
   o  Clarified the image example in the Introduction
   o  Clarified the relationship (none) between SIP Event Packages and
      SIP Info Packages
   o  Really, really clarified the protocol is NOT a negotiation but an
      advertisement
   o  Split Section 3 into UAS and UAC behavior
   o  Moved the example in section 3 into its own sub-section, and used
      full SIP header fields
   o  Clarified forking behavior
   o  Clarified language around when to send a body
   o  Added 469 error response, instead of reusing 489
   o  Clarified overlapping INFO method handling
   o  Fixed table 1 to follow 3261, not 2543
   o  Added REFER to the INFO Headers table
   o  replaced token-nodot with token for Info-Package header field
      values
   o  Clarified end-to-end security considerations
   o  Info Package parameters are semi-colon delimited, not dot
      delimited

   Changes from -02
   o  Applicability statement explicitly says we're backwards compatible
   o  Explicitly state we work like UPDATE (both early and confirmed
      dialogs)
   o  Agreed text for IANA Considerations package registry

   Changes from -01
   o  One and only one Info Package per INFO
   o  Removed Send-Info header field, greatly simplifying negotiation
   o  Multiple body part identification through Content-Disposition:
      Info-Package
   o  Note that forking INVITEs may result in multiple INFOs coming back
      to INVITE originator
   o  Describe how a UAS can enforce strict adherence to this document
   o  Remove CANCEL INFO faux pas
   o  Better explained overlapping INFO issues and resolutions
   o  Token names are now really case sensitive
   o  Moved Info Package Considerations to an Appendix
   o  Introduced stronger, yet more open, IANA registration process
   o  Took a few more paragraphs from INFO Litmus to cover all bases.
   o  Added RFC 5168 to legacy usages

   Changes from -00
   o  Corrected ABNF.
   o  Enabled sending of legacy INFO messages.  Receiving legacy INFO
      messages was already here.
   o  Negotiation is not Offer/Answer, it is Offer/Offer.
   o  Created the explicit "nil" Info Package to indicate no info
      package.
   o  Fixed CANCEL impacting future transactions.
   o  Added Registrar behavior.
   o  Added OPTIONS processing.
   o  Clarified overlapping INFO method processing.
   o  Described multiple INFO bodies in a single INFO method.
   o  Took out Info-Package as a header field for responses to the INFO
      method.
   o  Expanded on risks of using INFO and filled-in more on the
      alternatives
   o  Moved definitions of INFO into the body of the text and cleaned up
      IANA Considerations section
   o  Added legacy usages descriptions

Authors' Addresses

   Eric W. Burger
   NeuStar, Inc.
   46000 Center Oak Plaza
   Sterling, VA  20166-6579
   USA

   Email: eburger@standardstrack.com
   URI:   http://www.standardstrack.com

   Hadriel Kaplan
   Acme Packet
   71 Third Ave.
   Burlington, MA  01803
   USA

   Phone:
   Fax:
   Email: hkaplan@acmepacket.com
   URI:

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas,   02420
   Finland

   Phone:
   Fax:
   Email: christer.holmberg@ericsson.com
   URI: