One document matched: draft-ietf-sipcore-info-events-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<rfc category="std" docName="draft-ietf-sipcore-info-events-00"
ipr="trust200902" obsoletes="RFC 2976" updates="" xml:lang="en">
<front>
<title abbrev="INFO Framework">Session Initiation Protocol (SIP) INFO
Method and Package Framework</title>
<author fullname="Eric W. Burger" initials="E.W." surname="Burger">
<organization>NeuStar, Inc.</organization>
<address>
<postal>
<street>46000 Center Oak Plaza</street>
<city>Sterling</city>
<region>VA</region>
<code>20166-6579</code>
<country>USA</country>
</postal>
<email>eburger@standardstrack.com</email>
<uri>http://www.standardstrack.com</uri>
</address>
</author>
<author fullname="Hadriel Kaplan" initials="H." surname="Kaplan">
<organization>Acme Packet</organization>
<address>
<postal>
<street>71 Third Ave.</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>hkaplan@acmepacket.com</email>
<uri></uri>
</address>
</author>
<author fullname="Christer Holmberg" initials="C." surname="Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>Jorvas</city>
<region></region>
<code>02420</code>
<country>Finland</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>christer.holmberg@ericsson.com</email>
<uri></uri>
</address>
</author>
<date day="5" month="July" year="2009" />
<area>RAI</area>
<workgroup>SIPCORE</workgroup>
<abstract>
<t>This document provides new semantics for the SIP INFO method of RFC
2976. These new semantics defined here are fully backwards compatible
with the old semantics. Core to the new semantics is a mechanism for
defining, negotiating and exchanging Info Packages that use the INFO
method. Applications that need to exchange session-related information
within a SIP INVITE-created session, also known as application level
information, use these INFO requests. This draft addresses issues and
open items from RFC 2976 and replaces it.</t>
</abstract>
<note title="Conventions Used in this Document">
<t>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 <xref
target="RFC2119">RFC 2119</xref>. The terminology in this document
conforms to the <xref target="RFC4949">Internet Security
Glossary</xref>.</t>
<t>Be aware this document strictly follows <xref target="RFC3261">RFC
3261</xref> for the definition of the terms User Agent Server (UAS) and
User Agent Client (UAC). Specifically, the UAC issues a SIP request and
the UAS responds. This terminology may be confusing when one combines
the INFO case with the INVITE case. For an INVITE, the initiator of the
session is the UAC and the target of the session is the UAS. However, it
is possible for the target UA of the session, the UAS of the INVITE
transaction, to send an INFO to the initiating UA of the session, the
UAC of the INVITE transaction. From the perspective of the INFO, the
target UA of the session (INVITE UAS) is, in fact, the UAC (sender) of
the INFO request. Likewise, from the perspective of the INFO, the
initiating UA of the session (INVITE UAC) is the UAS (recipient) of the
INFO request. Since this document strictly follows RFC 3261, we refer to
the UA that issues the INVITE as the "initiating UA" and the UA that
responds to the INVITE as the "target UA" to remove any confusion.</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction" toc="default">
<t>The <xref target="RFC3261">SIP protocol</xref> defines session
control messages used to setup and tear down a SIP controlled session.
In addition, a SIP User Agent (UA) can use the re-INVITE and UPDATE
methods during a session to change the characteristics of the session.
Most often, this is to change the properties of media flows related to
the session or to update the <xref target="RFC4028">SIP session
timer</xref>. The purpose of the <xref target="RFC2976">INFO
message</xref> is to carry application level information along the SIP
signaling path. Note the INFO method does not change the SIP session
state. It may, however, change application state for applications using
the SIP session.</t>
<t>While INFO has been widely adopted for specific application use
cases, such as ISUP and DTMF exchange, <xref target="RFC2976">RFC
2976</xref> neither defined a negotiation mechanism nor a means by which
to explicitly indicate the type of application information contained in
the INFO message. This led to problems associated with static
configuration. In addition, the industry realized there was a potential
for interoperability problems due to undefined content syntax and
semantics. This draft addresses these deficiencies and provides a
framework for explicit negotiation of capabilities and content context
using "Info Packages".</t>
<t>The INFO method as defined by RFC 2976 did not provide any context
for the information the request carried. While it may sometimes be clear
what the content is based on the Content-Type, this is only true where
there is only one contextual usage of the content-type. For example, if
the Content-Type is "image/jpeg", the MIME-attached content is a JPEG
image. However, there are many useful ways a UAS can render an image.
Said differently, there are different contexts for an image in SIP. The
image could be a caller-id picture, a contact icon, a photo for sharing,
and so on. The sender does not know which image to send to the receiver
if the receiver supports an image content type. Likewise, the receiver
does not know the context of an image the client is sending if the
receiver supports receiving more than one image content type. Thus, we
need a well defined and documented statement of what the information
sent is for. This situation is identical to the <xref
target="RFC3458">context issue in Internet Mail</xref>. RFC 3458 goes
into this and other issues in detail.</t>
<t><xref target="RFC3265">Event Packages</xref> perform the role of
disambiguating the context of a message for subscription-based events.
This document provides a similar framework for INVITE-based application
level information exchange. However, while the mechanism described here
is similar to subscription-based events, there is no formal relationship
between this mechanism and the subscription mechanism. In particular,
when a UAC issues a SUBSCRIBE, it creates a dialog usage.</t>
<t>The mechanism defined here creates neither a separate subscription
dialog nor a subscription usage within an existing session. Instead, it
uses the INVITE method and its responses to indicate supported Info
Packages and the INFO method to convey the Info Packages.</t>
<t>Each UA enumerates which Info Packages it can receive. If a first UA
indicates it can receive a package and a second UA can send the package,
the second UA can send INFO methods containing the payload for that
package. The Recv-Info header indicates which packages a UA is willing
to receive. The Info-Package header indicates which package a particular
INFO method request belongs to. There is a reserved Info Package, "nil",
which indicates the UA conforms to this document, but does not wish to
receive Info Packages. This enables other UAs that conform to this
document to detect legacy UAs. A legacy UA will not include a Recv-Info
header in their SIP session establishment or modification requests.
Conversely, a UA that supports Info Packages will have a Recv-Info
header. <xref target="S.Nego"></xref> describes Info Package
advertisement in detail.</t>
<t>This document does not describe any specific Info Package type
extensions. One must extend this protocol by other documents, herein
referred to as "Info Packages". <xref target="S.Package"></xref>
describes guidelines for creating these extensions.</t>
<t>The INFO method does not change the state of SIP calls or the
parameters of the sessions SIP initiates. It merely sends optional
application layer information, generally related to the session.</t>
<t>Applications need to be aware that application level information
transported by the INFO method constitutes mid-session signaling. These
messages traverse the post-session-setup SIP signaling path. This is the
path taken by SIP re-INVITEs, BYEs, and other SIP requests within an
individual session. SIP proxy servers will receive, and potentially act
on, mid-session signaling information. Application designers need to
understand this can be a feature, as when the User Agents are exchanging
information that elements in the SIP signaling path need to be aware of.
Conversely, this can be a problem, as messages these network elements
have no interest in can also put a significant burden on those element's
ability to process other traffic. Moreover, such network elements may
not be able to read end-to-end encrypted INFO bodies.</t>
</section>
<section title="Applicability">
<t>This document replaces the <xref target="RFC2976">SIP INFO method
document</xref> to include explicit negotiation of supported Info
Packages in the INVITE transaction and indication of the Info Package to
use by using a new header field in the INFO request. As described in
<xref target="S.Requests"></xref>, the mechanism described here is
backwards compatible with legacy, RFC 2976 INFO mechanisms.</t>
</section>
<section anchor="S.Nego" title="Info Package Behavior">
<t>As stated in the Conventions section, the term UAC refers to the UAC
(sender) of the INFO method and UAS refers to the recipient of the INFO
method. "Initiating UA" refers to the sender of an initial INVITE to
establish a session and "target UA" refers to the recipient of that
INVITE request.</t>
<section anchor="S.UA" title="UAS Behavior">
<t>A UAS supporting this document MUST advertise the set of Info
Packages it is willing to receive in Recv-Info header(s) in dialog
usage requests and responses for session establishment or target
refresh. This includes INVITE, UPDATE, PRACK, ACK, and their
non-failure responses (101-199 and 2xx only).</t>
<t>Once a UAS indicates support for an Info Package by sending a
Recv-Info header with one or more package names, the UAS MUST be
prepared to receive an INFO containing that package. Note this may
occur before dialog negotiation completes.</t>
<t>Recall the UAC of an INVITE may choose to receive (be a UAS for)
INFO methods. This UA may chose not to offer any packages in the
initial INVITE and subsequently advertise packages from the target
UA's subsequent responses, in order to support <xref
target="RFC3725">third-party call control</xref>.</t>
<t>A UAS lists multiple packages by enumerating the package name(s),
separated by commas, as values for the Recv-Info header in the session
establishment exchange. A UAS may also list multiple packages by
including multiple Recv-Info headers. The UAS may also combine
multiple Recv-Info headers with one or more packages in each header
value. If the UAS prefers to receive one package over another, the UAS
MUST list the preferred Info Package lexically earlier in the message.
That is, by listing it earlier in a list within a given Recv-Info
header or listing it in a previous Recv-Info header in a given
message. The UAS MUST NOT list a package more than once. This order is
only a hint to the UAC, as there is no meaningful way of enforcing the
use of a preferred package at the UAC.</t>
<t>There is an important issue to consider when the UAS advertises
support for multiple packages that one might interpret to be similar
or equivalent. The UAC has no method of knowing whether the UAS would
like the UAC to send a single INFO request with the preferred package
or for the UAC to send multiple INFO requests with the same or similar
information. The behavior is entirely up to the UAC and the rules
specified by the package definitions.</t>
<t>If a UAS does not wish to receive any Info Packages, the UAS MUST
indicate this by including one and only one Recv-Info header with the
value 'nil'. This enables the UAC to discern the difference between a
UAS that understands Info Packages but does not wish to receive any
from a legacy UAS that does not understand Info Packages. A UAC
conforming to this document can always send or receive legacy INFO
usages without packages.</t>
<t>Info Package capability advertisement occurs within the context of
a session negotiation exchange. The Info Package capability set
received by the UAC within the last exchange is the one the UAC will
use to chose Info Packages from. Also note that due to glare, an INFO
request may be in flight prior to the UAC receiving an updated
capability set removing a given Info Package. Thus, the UAS MUST be
prepared to handle an INFO request with an Info Package payload with a
newly delisted Info Package. Proper handling does include rejecting
the request with a 469. See <xref target="S.Responses"></xref> for
more on this topic.</t>
</section>
<section title="UAC Behavior">
<t>A UAC MUST NOT send INFO requests for a given INFO package until
the UAC receives an "INVITE dialog usage" request or response (for
session establishment or target refresh) with a Recv-Info header
listing the given Info Package.</t>
<t>At any time during an "INVITE dialog usage" request or response, if
a UAS sends one or more Recv-Info headers, the UAC MUST replace the
old set of supported Info Packages with the collection of Info
Packages enumerated by the current message.</t>
<t>If the UAS does not send any Recv-Info headers in a message, then
the list of supported Info Packages does not change.</t>
<t>A UAC MUST cease sending INFO requests for a given INFO package
when the UAC receives an "INVITE dialog usage" request or response
(for session establishment or target refresh) that does not contain a
Recv-Info header listing the given Info Package. Note the UAC MUST be
prepared to receive a <xref target="S.Responses">469 response</xref>
at any time, even if the UAS advertised it could receive the Info
Package. This situation can occur if the UAC sends the INFO request at
the same time the UAS advertises it no longer supports the Info
Package in question.</t>
<t>If the UAC receives a Recv-Info header with the value 'nil', the
UAC MUST NOT send any INFO methods that contain Info Packages.</t>
<t>The UAS may advertise support for multiple Info Packages. If some
of these packages have similar or equivalent functionality and the UAC
supports multiple such packages, the UAC SHOULD chose to send Info
Package payload(s) from the Info Package listed lexically earlier in
the last Recv-Info advertisement the UAC received from the UAS. This
document cannot make this protocol action a must strength, as the
concept of "similar or equivalent" is highly Info Package
specific.</t>
<t>INFO itself does not necessitate the use of Require or
Proxy-Require headers. There is no token defined for "Supported"
headers. If necessary, clients may probe for the support of this
version of INFO using the OPTIONS request defined in <xref
target="RFC3261">SIP</xref>. One could envision a particular Info
Package implementation that relied on either of these headers. See
<xref target="S.Package"></xref> for more on this issue.</t>
<t>The presence of the Recv-Info header in a message is sufficient to
indicate support for this version of INFO. The "methods" parameter for
<xref target="RFC3841">Contact</xref> is not sufficient to determine
if the endpoints support Info Packages, as the INFO method supported
might be the obsolete <xref target="RFC2976">RFC 2976</xref>
version.</t>
<t>For Info Packages, this draft does not provide a means of requiring
support for a specific Info Package. If the UAS does not indicate
support for an Info Package that the UAC requires, and the UAC
requires the use of that package, the UAC can use any supported <xref
target="RFC3261">RFC3261</xref> method to terminate the session.</t>
<t>A UAC MAY send a legacy <xref target="RFC2976">INFO</xref> method
at any time.</t>
</section>
<section title="Package Versions">
<t>The protocol mechanism described herein does not provide for a
package versioning mechanism. This is for two reasons. The first is
that if an Info Package has a capability for forward and backward
compatibility in the Info Package payload, then that compatibility
comes from the application level semantics of the information. This
means it is the responsibility of the application to handle such
compatibility and not the INFO framework. For example, one could use
XML versioning techniques in the payload to indicate versions of the
Info Package.</t>
<t>The second reason we do not have a package versioning system is not
all payloads have sufficient capability to carry payload versions. In
this situation, it is highly unlikely payloads will be backwards
compatible. That is, what one really is defining is a new Info
Package. This is more especially so when one considers User Agents can
advertise package support but cannot advertise package version
support. Even if we did allow for package versioning, as a parameter
to the Recv-Info header value, for example, it is lexically equivalent
to having a new Info Package.</t>
<t>UACs MUST NOT depend on any lexical parsing of the Info Package
name for versioning, such as "fooV1" and "fooV2" or "foo.1" and
"foo.2".</t>
</section>
<section title="Advertisement Example">
<t>Here is an INVITE. The initiating UA advertises the following.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[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: ...
...]]></artwork>
<postamble></postamble>
</figure>
<t>This means the initiating UA is willing to receive from Info
Packages P and R.</t>
<t>In this next message, the target UA responds with a 200 OK:</t>
<figure>
<artwork><![CDATA[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: ...
...]]></artwork>
<postamble></postamble>
</figure>
<t>This indicates the target UA is willing to receive from Info
Packages R and T.</t>
<t>The initiating UA then confirms in an ACK, as shown.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[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]]></artwork>
</figure>
<t>The target UA can now send from package R to the initiating UA.
Moreover, in this example, the target UA may not send from package P,
as P no longer is in the initiating UA's Info Package set.</t>
</section>
</section>
<section title="The INFO Method Request">
<section anchor="S.Requests" title="INFO Requests">
<t>The INFO method provides additional, application level information
that can further enhance a SIP application. It is important to note
there are some types of application information for which using INFO
messages are inappropriate. See <xref target="S.info-packages"></xref>
for a discussion of this.</t>
<t>The UAC MUST include the Info-Package header field when it sends an
INFO request carrying an Info Package. The Info-Package header field
value in an INFO request MUST contain a single Info Package token.
That Info Package token MUST match one of the Info Packages the UAS
indicated support for during the negotiation described in <xref
target="S.Nego"></xref>.</t>
<t>The UAC MAY send an INFO in a legacy usage context. See <xref
target="S.legacy"></xref> for examples of legacy usages. In general, a
legacy usage is where there is no Info-Package header. In this case,
if the UAS has never offered a Recv-Info header or never offered a
Recv-Info header with a package of a similar function to the legacy
INFO usage, the UAC MAY send an INFO without an Info-Package header
field and a body appropriate to the said legacy usage.</t>
<t>A UAC MUST NOT use the INFO method outside an INVITE dialog usage.
The INFO method has no lifetime or usage of its own, as it is
inexorably linked to that of the INVITE. When the INVITE-created
session terminates, that signals the termination of the negotiated
Info Packages. A UAS that receives an INFO message after the INVITE
dialog usage terminates MUST respond with a 481 Call Does Not
Exist.</t>
<t>The session identifiers defined in <xref target="RFC3261">RFC
3261</xref> must match those of the provisional or final responses to
the INVITE. As a result, INFO requests cannot fork. The UAC may send
INFO requests once the UAS has sent the Recv-Info header field value,
indicating what the UAS supports.</t>
<t>The converse is not true during initial session establishment. The
initiating UA of the first INVITE MUST be prepared to receive multiple
INFO requests, as the first INVITE may fork. Since session negotiation
has not completed, and we allow early INFO requests, multiple target
UAs may respond. This initial session establishment phase is the only
time the UAS need be prepared to receive multiple INFO requests, as
one would expect there may be messages from non-authoritative forked
dialogs prior to their termination.</t>
<t>The construction of the INFO request is the same as any other
request within an existing INVITE-initiated session. A UAC MAY send an
INFO request on both an early and confirmed session.</t>
<t>The INFO request MUST NOT carry a Recv-Info header. The UAC can
only negotiate Info Packages using the procedures of <xref
target="S.Nego"></xref>.</t>
<t>The signaling path for the INFO method is the signaling path
established as a result of the session setup. This can be direct
signaling between the calling and called user agents or a signaling
path involving SIP proxy servers that were involved in the call setup
and added themselves to the Record-Route header on the initial INVITE
message.</t>
</section>
<section title="INFO Request Body">
<t>The purpose of the INFO request is to carry application level
information between SIP user agents. The INFO message body SHOULD
carry this information, unless the message headers carry the
information of interest. Note this is not an invitation to invent SIP
headers for the purposes of application level information exchange.
Rather, one could envision circumstances where existing SIP headers
already convey the information the application has interest in.</t>
<t>If the Info Package defines a payload, and the package
specification indicates it is appropriate to include a payload with
the request, the UAC MUST include the payload with the MIME type
specified by the Info Package.</t>
<t>If the Info Package definition directs the UAC to send a request
without a payload, the UAC MUST send the INFO request without a
body.</t>
<t>Some SIP extensions, which are orthogonal to INFO, may insert body
parts unrelated to the INFO payload. User Agents MUST conform to RFC
3261 as updated by <xref
target="I-D.ietf-sip-body-handling">body-handling</xref> to support
multipart MIME handling. If there are bodies unrelated to the Info
Package, and the Info Package also has a payload, the UAC MUST bundle
these elements into a multipart MIME body. In this case, the UAS needs
a means to unambiguously identify the body part belonging to the Info
Package. To do this, the UAC MUST identify the Info Package payload
MIME body part with a Content-Disposition of 'Info-Package'.</t>
<t>If the payload of an Info Package is already a multipart MIME body,
the UAC MUST identify the payload with a Content-Disposition of
'Info-Package' in the headers for the appropriate MIME body part.</t>
<t>If there is no payload in the INFO request unrelated to the Info
Package and the payload of the Info Package is not a multipart MIME,
the UAC MUST identify the message, at the SIP header level, with a
Content-Disposition of 'Info-Package'.</t>
<t>If there is no payload for the Info Package, they UAC MAY omit the
Content-Disposition header.</t>
<t><list style="empty">
<t>NOTE: We could be lazy and even save 33 octets by allowing the
UAC to construct a non-multipart MIME payload without a
Content-Disposition header. However, mandating the presence makes
parsing considerably easier, and it is easier to have it required
now than run into a problem later.</t>
<t></t>
<t>NOTE: One could offer that the Info-Package header is
redundant, as we could have the Info Package name be a parameter
for Content-Disposition. However, there could be corner cases with
legacy INFO usage that makes this a poor choice.</t>
</list></t>
</section>
<section anchor="S.Responses"
title="Responses to the INFO Request Method">
<t>If a UAS receives an INFO request, it MUST send a final response. A
UAS MUST send a 200 OK response for an INFO request with no message
body and no Info-Package header if the UAS received the INFO request
on an existing session. This protocol action supports legacy use of
INFO as a keep-alive mechanism.</t>
<t>If the UAS receives an INFO request with an Info-Package the UAS
advertised with a Recv-Info in the last session state update and the
body of the INFO request is an appropriate MIME type for the Info
Package, the UAS MUST send a 200 OK response.</t>
<t>If the INFO request contains a body the server does not understand
then, in the absence of Info Package associated processing rules for
the body, including the absence of an Info-Package header, the server
MUST respond with a 415 Unsupported Media Type message.</t>
<t>If the INFO request indicates an Info Package type the server does
not understand, then the server MUST respond with a 469 Bad INFO
Package. In the terminology of <xref target="RFC5057">Multiple Dialog
Usages</xref>, this represents a Transaction Only failure.</t>
<t>If a server receives an INFO request with a body it understands,
but the request has no Info-Package header, the UAS MAY use the body
as it sees fit. If the UAS accepts the INFO request, the UAS MUST
respond to the INFO request with a 200 OK. This enables legacy use of
INFO. If the UAS needs to enforce strict compliance with the current
INFO framework described here, the UAS MUST reject the request with a
469.</t>
<t>The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message
if the INFO request does not match any existing INVITE-initiated
session.</t>
<t>The UAS MAY send other responses, such as Request Failure (4xx),
Server Failure (5xx) and Global Failure (6xx) as appropriate for the
request.</t>
</section>
<section title="Routing Behavior">
<t>Unless stated otherwise, the protocol rules for the INFO request
governing the usage of tags, Route and Record-Route, retransmission
and reliability, CSeq incrementing and message formatting follow those
in <xref target="RFC3261">RFC 3261</xref> as defined for the BYE
request.</t>
<t>The INFO message MUST NOT change the state of the SIP session. Of
course, outside the INFO machinery specific failure responses as
documented in <xref target="RFC5057">the SIP dialog usages
document</xref>, may cause the INVITE session to terminate.</t>
</section>
<section title="Behavior of Registrars">
<t>Registrars receiving a REGISTER request that includes Recv-Info
headers MAY store such information and use it for routing purposes.
How the registrar uses this information is beyond the scope of this
document.</t>
</section>
<section title="OPTIONS Processing">
<t>A UAC, the sender of the OPTIONS request, SHOULD include Recv-Info
headers, populated appropriately for the packages the UAC supports.
The UAS SHOULD include its set of Recv-Info packages. These strictures
are of "should" strength because local policy might restrict the
advertisement of full capabilities, the UA may know the best choice of
equivalent packages to list from local configuration, and so on.</t>
<t>The UAS and UAC MUST NOT consider the OPTIONS request to be part of
a capabilities negotiation. The OPTIONS request is purely a probe. For
the UAC or UAS to renegotiate package support, they must use the
procedures described in <xref target="S.Nego"></xref>.</t>
</section>
<section title="Order of Delivery">
<t>The INFO method does not define mechanisms for ensuring in-order
delivery for overlapping INFO requests. That is, the UAC can send
another INFO request before receiving a transaction response from the
UAS to a prior INFO request. While the UAC will increment the CSeq
header upon the transmission of new INFO messages, the UAS cannot use
the CSeq to determine the sequence of INFO information. All a UAS can
determine is the UAC sent one INFO message after another. This is due
to the fact that there could be gaps in the INFO message CSeq count
caused by a user agent sending re-INVITES or other SIP messages.</t>
<t>It is up to the individual Info Package definition to specify what
happens when there are overlapping INFO requests. However, since it is
legal SIP to have overlapping requests, the application must be able
to handle the reception of overlapping requests. Overlapping requests
can occur even if the particular instance of an application (Info
Package) does not allow it, as the mechanism described here is
package-agnostic. Thus, the Info Package needs to define the
appropriate response. This is more especially so given the UAC could
send from multiple Info Packages. Some of those packages may allow
overlapping INFO requests, while others do not. In this situation, it
would be hard to tell if the non-overlapping packages were being
violated or not.</t>
</section>
</section>
<section title="Formal INFO Method Definition">
<section title="INFO Method">
<t>This document describes one new SIP method: INFO. This document
replaces the definition and registrations found in <xref
target="RFC2976"></xref>.</t>
<t>This table expands on Tables 2 and 3 in <xref
target="RFC3261"></xref>.</t>
<figure anchor="T.headers" suppress-title="false"
title="Table 1: Summary of Header Fields">
<preamble></preamble>
<artwork><![CDATA[ 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
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="INFO Headers">
<t>This table expands on tables 2 and 3 in <xref
target="RFC3261"></xref>.</t>
<figure suppress-title="???"
title="Table 2: INFO-related Header Fields">
<preamble></preamble>
<artwork><![CDATA[Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR
------------------------------------------------------------------------
Info-Package R - - - - - - - o* - - - - -
Recv-Info R o - - o o o o - - o - - -
Recv-Info 2xx o - - o o - o - - o - - -
Recv-Info 1xx o - - o o - o - - o - - -
Recv-Info r o - - - o - o - - o - - -
]]></artwork>
<postamble>* Info-Package is MANDATORY for INFO messages sent using
Info Packages as described in this document. Info-Package is
OPTIONAL for legacy (RFC2976) INFO messages.</postamble>
</figure>
<section title="Info-Package header">
<t>This document adds Info-Package to the definition of the element
"message-header" in the SIP message grammar.</t>
<t>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 octet-by-octet with that of the
Recv-Info header value. That is, the Info Package name is case
sensitive. Info-package-param is not part of the comparison-checking
algorithm.</t>
<t>This document does not define values for Info-Package types.
Individual Info Packages define these values. Such documents MUST
register such values with IANA. These values are <xref
target="RFC5226">Specification Required</xref>.</t>
</section>
<section title="Recv-Info header">
<t>This document adds Recv-Info to the definition of the element
"general-header" in the <xref target="RFC3261">SIP</xref> message
grammar. <xref target="S.Nego"></xref> describes the Recv-Info
header usage.</t>
</section>
</section>
</section>
<section title="Legacy Uses of INFO">
<t>Several RFC-defined and other standards-defined uses of <xref
target="RFC2976">RFC 2976 INFO</xref> exist and are in use, as well as
numerous proprietary uses. <xref target="S.legacy"></xref> describes
some of these usages. By definition, identifying such uses has relied on
either static local configuration or implicit context determination
based on the body Content-Type or Content-Disposition value or some
proprietary mechanism. This draft cannot forbid nor avoid such uses,
since local configuration can always override standardized
mechanisms.</t>
<t>To maintain backward compatibility with the extant standardized uses
of INFO, a server MAY interpret an INFO request with no "Info-Package"
header as being of such legacy use.</t>
<t>It should be noted that such legacy use will not "break" the
mechanism in this draft. For example, if a UA supports <xref
target="RFC3372">SIP-T</xref>, it does so based on static local
configuration or based on acceptance of the application/isup body. If it
adds support for this draft's Info Package negotiation mechanism, the
local configuration still applies, and the UA will send/receive INFO
messages based on SIP-T regardless of the Info Package negotiation. It
will also be able to send/receive INFO messages based on the Info
Packages it negotiated. If, at some future time, an Info Package is
defined for SIP-T, the UA can indicate such in the negotiation, and
again local configuration would supersede if need be. The UA would not
lose the ability to use SIP-T with legacy devices. Rather, it would gain
the ability to use it with devices which support this draft and with
which it did not have such local configuration set, and could avoid
failures related to unsupported bodies.</t>
<t>It is the hope of this draft's authors that vendors that implement
proprietary INFO uses submit their mechanisms as Info Package extension
documents, and follow the Info Package negotiation mechanism defined in
this draft.</t>
</section>
<section anchor="S.Package" title="Info Package Requirements">
<t>Info Packages SHOULD NOT reiterate any of the behavior described in
this document, unless required for clarity or emphasis. However, such
packages MUST describe the behavior that extends or modifies the
behavior described in this document.</t>
<t>Info Packages MUST NOT weaken any behavior designated with "SHOULD"
or "MUST" in this document. However, Info Packages MAY strengthen
"SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if the
application requires it.</t>
<t>In addition to the normal sections expected in standards-track RFCs
and SIP extension documents, authors of Info Packages need to address
each of the issues detailed in the following subsections, whenever
applicable.</t>
<section title="Applicability">
<t>This section, which MUST be present, describes why any of the other
established user-to-user data transfer protocols are not appropriate
for the given Info Package. Common reasons can be a requirement for
SIP Proxies or back-to-back User Agents (B2BUAs) to see the
application level information. Consideration in this section MUST
describe what happens if one or both endpoints encrypt the
payload.</t>
</section>
<section title="Info Package Name">
<t>This section, which MUST be present, defines the token name that
designates the Info Package. The name MUST conform to the token ABNF
production described in <xref target="S.ABNF"></xref>. It MUST include
the information that appears in the IANA registration of the token.
For information on registering such types, see <xref
target="S.IANA"></xref>.</t>
</section>
<section title="Info Package Parameters">
<t>If the "Info-Package" header allows parameters to modify the
behavior of the Info Package, this section MUST clearly define the
syntax and semantics of such parameters.</t>
</section>
<section title="Info Package Tags">
<t>If useful for the Info Package to have SIP option tags, this is the
place to define the tag. Note that if the Info Package defines a SIP
option tag, the Info Package must conform to the <xref
target="RFC3427">SIP Change Process</xref>.</t>
</section>
<section title="INFO Bodies">
<t>Each Info Package MUST define what type or types of bodies are
expected in INFO requests. Such packages MUST specify or cite detailed
specifications for the syntax and semantics associated with such a
body.</t>
<t>The UAS MUST enumerate every MIME type associated with the Info
Packages advertised in the UAS' Recv-Info header the UAS is willing to
receive. If a UAC sends a body that includes something not enumerated
by the UAS, this is a protocol error and the UAS MUST respond
appropriately.</t>
</section>
<section title="UAC generation of INFO requests">
<t>Each Info Package MUST describe the process by which a UA generates
and sends an INFO request. This includes detailed information about
what events cause the UA to send an INFO request.</t>
<t>If the Info Package does not allow overlapping (outstanding) INFO
requests, the Info Package MUST disclose this in the section
describing UA generation of INFO requests. Note the generic protocol
machinery of the INFO method has no way of enforcing such a
requirement. <xref target="S.UAS_proc"></xref> describes this
situation.</t>
</section>
<section anchor="S.UAS_proc" title="UAS processing of INFO requests">
<t>The Info Package MAY describe the process followed by the UA upon
receipt of an INFO request. Since INFO does not change SIP state, and
may not even change application state, there may be no useful guidance
required in the Info Package specification for UA processing.</t>
<t>If the info Package does not permit overlapping INFO requests, it
is important to note the issuance of overlapping INFO requests is an
application-layer protocol failure and not an INFO method failure.
Therefore, in the event a UAC issues overlapping INFO requests for an
Info Package, the UAS MUST NOT return an error response as a result of
the overlapping INFO request. Of course, if there are other problems
with the request that results in a failure, the UAC issues the
appropriate response code. This section of the Info Package
specification MUST describe the application level response to
overlapping INFO requests. Examples include a new INFO request back to
the offending UAC indicating an application error, ignoring the
overlapping request and processing it to the UAS' best effort, or
terminating the entire SIP session.</t>
</section>
<section title="Rate of INFO Requests">
<t>Each Info Package MUST define a requirement of MUST strength which
defines an absolute maximum on the rate at which an Info Package of a
given type can generate INFO messages by a UA in a session.</t>
<t>If possible, a package MUST define a throttle mechanism that allows
UAs to further limit the rate of INFO messages.</t>
</section>
<section title="IANA Registrations">
<t>The Info Package MUST have an IANA Considerations section that
includes definitions for the Info Package Name and, if needed,
supported MIME types.</t>
</section>
<section title="Security Considerations">
<t>The INFO mechanism transports application level information. One
implication of this is INFO messages may require a higher level of
protection than the underlying SIP-based session signaling. If the
application transports sensitive information, such as credit card
numbers, health history, personal identifiers, and so on, the Info
Package MUST document security procedures that exceed the default
procedures presented in this document. In most circumstances, it is
not sufficient for a package to attempt to mandate TLS for the
signaling channel to secure the data carried by the INFO.
Intermediaries will have access to the payload and past the first hop,
there is no way to assure subsequent hops will not transmit the
payload in clear text. The only way to ensure secure transport at the
application level is to have the security at the application level.
The most common method of achieving this is to use end-to-end security
techniques such as <xref target="RFC3851">S/MIME</xref>. If the
application demands this level of security, the Info Package
definition MUST indicate such.</t>
</section>
<section title="Examples">
<t>We RECOMMEND Info Packages include several demonstrative message
flow diagrams paired with several typical, syntactically correct, and
complete messages.</t>
<t>Documents describing Info Packages MUST clearly indicate the
examples are informative and not normative, with instructions that
implementers refer to the main text of the document for exact protocol
details.</t>
</section>
</section>
<section anchor="S.ABNF" title="Syntax">
<t>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 <xref target="RFC3261">SIP</xref> and contain references to elements
defined therein.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[INFOm = %x49.4E.46.4F ; INFO in caps
extension-method = INFOm / token
Info-Package = "Info-Package" HCOLON Info-package-type
Recv-Info = "Recv-Info" HCOLON Info-package-list
Info-package-list = "nil"
/ Info-package-type *( COMMA Info-package-type )
Info-package-type = Info-package-name *( ";" Info-package-param)
Info-package-name = token
Info-package-param = token
]]></artwork>
<postamble>NOTE on the Recv-Info production: if the value is "nil",
there can be one and only one Recv-Info header in the SIP
message.</postamble>
</figure>
</section>
<section anchor="S.IANA" title="IANA Considerations">
<section title="Update to Registration of SIP INFO Method">
<t>Please update the existing registration in the SIP Methods and
Response Codes registry under the SIP Parameters registry that
states:</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[Method: INFO
Reference: [RFC2976]]]></artwork>
<postamble></postamble>
</figure>
<t>to:</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[Method: INFO
Reference: [RFCXXXX]]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Registration of the Info-Package Header Field">
<t>Please add the following new SIP header field in the Header Fields
subregistry under the SIP Parameters registry.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[Header Name: Info-Package
Compact Form: (none)
Reference: [RFCXXXX]]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Registration of the Recv-Info Header Field">
<t>Please add the following new SIP header field in the Header Fields
subregistry under the SIP Parameters registry.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[Header Name: Recv-Info
Compact Form: (none)
Reference: [RFCXXXX]]]></artwork>
<postamble></postamble>
</figure>
<t></t>
</section>
<section title="Creation of the Info Packages Registry">
<t>Please create a subregistry in the SIP Parameters registry for Info
Packages. This subregistry has a modified <xref target="RFC5226">First
Come First Served</xref> policy.</t>
<t>The following data elements populate the Info Package
Registry.<list style="symbols">
<t>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.</t>
<t>Info Package Payload MIME Types: A list of zero or more
registered MIME types from the MIME Type Registry.</t>
<t>Standards Status: Values are "Standards Track" or empty. See
below for a discussion and rules on this field.</t>
<t>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.</t>
</list></t>
<t>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 <xref
target="RFC5226">Specification Required</xref>, the value for the
Standards Status field is "Standards Track". Otherwise, the field is
empty.</t>
<t>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.</t>
<t>The initial population of this table shall be:</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[Name MIME Type Standards Status Reference
nil Standards Track [RFCXXXX]]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Registration of the Info-Package Content-Disposition">
<t>Please add the following registration to the Content-Disposition
registry. The description suitable for the IANA registry is as
follows.</t>
<t>The payload of the message carrying this Content-Disposition header
field value is the payload of an Info Package.</t>
</section>
<section title="SIP Response Code 469 Registration">
<t>Please register the 469 response code in the Session Initiation
Protocol Parameters - Response Codes registry as follows.</t>
<figure>
<artwork><![CDATA[Response Code: 469
Default Reason Phrase: Bad INFO Package
Reference: RFCXXXX]]></artwork>
</figure>
</section>
</section>
<section title="Examples">
<section title="Simple Info Package">
<t>Here Alice sends Bob a simple Info Package payload.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[INFO sip:alice@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix
CSeq: 2 INFO
Contact: <sip:bob@192.0.2.2>
Info-Package: foo
Content-type: application/foo
Content-length: 24
I am a foo message type
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Multipart INFO Example">
<t>Other SIP extensions can put payloads into an INFO method,
independent of the Info Package. In this case, the Info Package
payload gets put into a Multipart MIME body, with the content
disposition indicating which body belongs to the Info Package. Since
there is one and only one Info Package payload in the message, we only
need to tag which body part goes with the Info Package.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[INFO sip:alice@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix
CSeq: 7 INFO
Contact: <sip:bob@192.0.2.2>
Info-Package: foo
mumble-extension: <cid:abcd9999qq>
Content-Type: multipart/mixed;boundary="theboundary"
Content-Length: ...
--theboundary
Content-Type: application/mumble
Content-Id: abcd9999qq
...
<mumble stuff>
--theboundary
Content-Type: application/foo
Content-Disposition: Info-Package
Content-length: 24
I am a foo message type
--theboundary--]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<section title="Modifications to SIP Change Process">
<t>This document updates <xref target="RFC3427">RFC 3427</xref> to add a
process for registering new Info Packages. The process for registering
new Info Packages follows the process outlined in Section 4.3 of RFC
3427 for the registration of SIP Event Packages. Namely, the
registration of a new SIP Info Package requires the DISPATCH chairs to
assign an individual to perform expert review of the proposal if the
work is not a RAI work item in itself.</t>
</section>
<section title="Security Considerations" toc="default">
<t>By eliminating multiple uses of INFO messages without adequate
community review and by eliminating the possibility for rogue SIP User
Agents from confusing another User Agent by purposely sending unrelated
INFO messages, we expect this document's clarification of the use of
INFO to improve the security of the Internet. Whilst rogue UACs can
still send unrelated INFO messages, this framework provides mechanisms
for which the UAS and other security devices can filter for approved
Info Packages.</t>
<t>If the content of the Info Package payload is private, User Agents
will need to use end-to-end encryption, such as S/MIME, to prevent
access to the content. This is particularly important as transport of
INFO is likely not to be end-to-end, but through SIP proxies and
back-to-back user agents (B2BUA's), which the user may not trust.</t>
<t>The INFO mechanism transports application level information. One
implication of this is INFO messages may require a higher level of
protection than the underlying SIP-based session signaling. In
particular, if one does not protect the SIP signaling from eavesdropping
or authentication and repudiation attacks, for example by using TLS
transport, then the INFO request and its contents will be vulnerable, as
well. Even with SIP/TLS, any SIP hop along the path from UAC to UAS can
view, modify, or intercept INFO requests, as they can with any SIP
request. This means some applications may require end-to-end encryption
of the INFO payload, beyond, for example, hop-by-hop protection of the
SIP signaling itself. Since the application dictates the level of
security required, individual Info Packages have to enumerate these
requirements. In any event, the INFO Framework described by this
document provides the tools for such secure, end-to-end transport of
application data.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement
Levels</title>
<author initials="S." surname="Bradner">
<organization></organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
<seriesInfo name="BCP" value="14" />
</reference>
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization></organization>
</author>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization></organization>
</author>
<date month="May" year="2008" />
<abstract>
<t>Many protocols make use of identifiers consisting of constants
and other well-known values. Even after a protocol has been
defined and deployment has begun, new values may need to be
assigned (e.g., for a new option type in DHCP, or a new encryption
or authentication transform for IPsec). To ensure that such
quantities have consistent values and interpretations across all
implementations, their assignment must be administered by a
central authority. For IETF protocols, that role is provided by
the Internet Assigned Numbers Authority (IANA).</t><t>
In order for IANA to manage a given namespace prudently, it needs
guidelines describing the conditions under which new values can be
assigned or when modifications to existing values can be made. If
IANA is expected to play a role in the management of a namespace,
IANA must be given clear and concise instructions describing that
role. This document discusses issues that should be considered in
formulating a policy for assigning values to a namespace and
provides guidelines for authors on the specific text that must be
included in documents that place demands on
IANA.</t><t> This document obsoletes RFC 2434. This
document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26" />
<seriesInfo name="RFC" value="5226" />
<format octets="66160" target="ftp://ftp.isi.edu/in-notes/rfc5226.txt"
type="TXT" />
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization></organization>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization></organization>
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization></organization>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization></organization>
</author>
<date month="June" year="2002" />
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an
application-layer control (signaling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include Internet telephone calls, multimedia
distribution, and multimedia conferences. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261" />
<format octets="647976"
target="ftp://ftp.isi.edu/in-notes/rfc3261.txt" type="TXT" />
</reference>
<reference anchor="I-D.ietf-sip-body-handling">
<front>
<title>Message Body Handling in the Session Initiation Protocol
(SIP)</title>
<author fullname="Gonzalo Camarillo" initials="G"
surname="Camarillo">
<organization></organization>
</author>
<date day="9" month="March" year="2009" />
<abstract>
<t>This document specifies how message bodies are handled in SIP.
Additionally, this document specifies SIP user agent support for
MIME (Multipurpose Internet Mail Extensions) in message
bodies.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-sip-body-handling-06" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-06.txt"
type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC0793">
<front>
<title abbrev="Transmission Control Protocol">Transmission Control
Protocol</title>
<author fullname="Jon Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information
Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>
</address>
</author>
<date day="1" month="September" year="1981" />
</front>
<seriesInfo name="STD" value="7" />
<seriesInfo name="RFC" value="793" />
<format octets="172710" target="ftp://ftp.isi.edu/in-notes/rfc793.txt"
type="TXT" />
</reference>
<reference anchor="RFC2976">
<front>
<title>The SIP INFO Method</title>
<author fullname="S. Donovan" initials="S." surname="Donovan">
<organization></organization>
</author>
<date month="October" year="2000" />
<abstract>
<t>This document proposes an extension to the Session Initiation
Protocol (SIP). This extension adds the INFO method to the SIP
protocol. The intent of the INFO method is to allow for the
carrying of session related control information that is generated
during a session. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2976" />
<format octets="17736" target="ftp://ftp.isi.edu/in-notes/rfc2976.txt"
type="TXT" />
</reference>
<reference anchor="RFC4497">
<front>
<title>Interworking between the Session Initiation Protocol (SIP)
and QSIG</title>
<author fullname="J. Elwell" initials="J." surname="Elwell">
<organization></organization>
</author>
<author fullname="F. Derks" initials="F." surname="Derks">
<organization></organization>
</author>
<author fullname="P. Mourot" initials="P." surname="Mourot">
<organization></organization>
</author>
<author fullname="O. Rousseau" initials="O." surname="Rousseau">
<organization></organization>
</author>
<date month="May" year="2006" />
<abstract>
<t>This document specifies interworking between the Session
Initiation Protocol (SIP) and QSIG within corporate
telecommunication networks (also known as enterprise networks).
SIP is an Internet application-layer control (signalling) protocol
for creating, modifying, and terminating sessions with one or more
participants. These sessions include, in particular, telephone
calls. QSIG is a signalling protocol for creating, modifying, and
terminating circuit-switched calls (in particular, telephone
calls) within Private Integrated Services Networks (PISNs). QSIG
is specified in a number of Ecma Standards and published also as
ISO/IEC standards. This document specifies an Internet Best
Current Practices for the Internet Community, and requests
discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="117" />
<seriesInfo name="RFC" value="4497" />
<format octets="149992"
target="ftp://ftp.isi.edu/in-notes/rfc4497.txt" type="TXT" />
</reference>
<reference anchor="RFC2616">
<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol --
HTTP/1.1</title>
<author fullname="Roy T. Fielding" initials="R." surname="Fielding">
<organization abbrev="UC Irvine">Department of Information and
Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code>
</postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>
<author fullname="James Gettys" initials="J." surname="Gettys">
<organization abbrev="Compaq/W3C">World Wide Web
Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email>
</address>
</author>
<author fullname="Jeffrey C. Mogul" initials="J." surname="Mogul">
<organization abbrev="Compaq">Compaq Computer
Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code>
</postal>
<email>mogul@wrl.dec.com</email>
</address>
</author>
<author fullname="Henrik Frystyk Nielsen" initials="H."
surname="Frystyk">
<organization abbrev="W3C/MIT">World Wide Web
Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email>
</address>
</author>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization abbrev="Xerox">Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code>
</postal>
<email>masinter@parc.xerox.com</email>
</address>
</author>
<author fullname="Paul J. Leach" initials="P." surname="Leach">
<organization abbrev="Microsoft">Microsoft
Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
</postal>
<email>paulle@microsoft.com</email>
</address>
</author>
<author fullname="Tim Berners-Lee" initials="T."
surname="Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web
Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>
<date month="June" year="1999" />
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used
for many tasks beyond its use for hypertext, such as name servers
and distributed object management systems, through extension of
its request methods, error codes and headers . A feature of HTTP
is the typing and negotiation of data representation, allowing
systems to be built independently of the data being
transferred.</t>
<t>HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2616" />
<format octets="422317"
target="ftp://ftp.isi.edu/in-notes/rfc2616.txt" type="TXT" />
<format octets="5529857"
target="ftp://ftp.isi.edu/in-notes/rfc2616.ps" type="PS" />
<format octets="550558"
target="ftp://ftp.isi.edu/in-notes/rfc2616.pdf" type="PDF" />
<format octets="636125"
target="http://xml.resource.org/public/rfc/html/rfc2616.html"
type="HTML" />
<format octets="493420"
target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"
type="XML" />
</reference>
<reference anchor="RFC0768">
<front>
<title>User Datagram Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel">
<organization>University of Southern California (USC)/Information
Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>
<phone>+1 213 822 1511</phone>
</address>
</author>
<date day="28" month="August" year="1980" />
</front>
<seriesInfo name="STD" value="6" />
<seriesInfo name="RFC" value="768" />
<format octets="5896" target="ftp://ftp.isi.edu/in-notes/rfc768.txt"
type="TXT" />
</reference>
<reference anchor="RFC4949">
<front>
<title>Internet Security Glossary, Version 2</title>
<author fullname="R. Shirey" initials="R." surname="Shirey">
<organization></organization>
</author>
<date month="August" year="2007" />
<abstract>
<t>This Glossary provides definitions, abbreviations, and
explanations of terminology for information system security. The
334 pages of entries offer recommendations to improve the
comprehensibility of written material that is generated in the
Internet Standards Process (RFC 2026). The recommendations follow
the principles that such writing should (a) use the same term or
definition whenever the same concept is mentioned; (b) use terms
in their plainest, dictionary sense; (c) use terms that are
already well-established in open publications; and (d) avoid terms
that either favor a particular vendor or favor a particular
technology or mechanism over other, competing techniques that
already exist or could be developed. This memo provides
information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4949" />
<format octets="867626"
target="ftp://ftp.isi.edu/in-notes/rfc4949.txt" type="TXT" />
</reference>
<reference anchor="RFC3080">
<front>
<title abbrev="The BEEP Core">The Blocks Extensible Exchange
Protocol Core</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>131 Stony Circle</street>
<street>Suite 500</street>
<city>Santa Rosa</city>
<region>CA</region>
<code>95401</code>
<country>US</country>
</postal>
<phone>+1 707 578 2350</phone>
<email>mrose@invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<date month="March" year="2001" />
<area>Applications</area>
<keyword>application protocols</keyword>
<keyword>BEEP</keyword>
<keyword>BXXP</keyword>
<keyword>application framework</keyword>
<abstract>
<t>This memo describes a generic application protocol kernel for
connection-oriented, asynchronous interactions called the BEEP
(Blocks Extensible Exchange Protocol) core. BEEP permits
simultaneous and independent exchanges within the context of a
single application user-identity, supporting both textual and
binary messages.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3080" />
<format octets="82089" target="ftp://ftp.isi.edu/in-notes/rfc3080.txt"
type="TXT" />
<format octets="111015"
target="http://xml.resource.org/public/rfc/html/rfc3080.html"
type="HTML" />
<format octets="87864"
target="http://xml.resource.org/public/rfc/xml/rfc3080.xml"
type="XML" />
</reference>
<reference anchor="RFC3851">
<front>
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version
3.1 Message Specification</title>
<author fullname="B. Ramsdell" initials="B." surname="Ramsdell">
<organization></organization>
</author>
<date month="July" year="2004" />
<abstract>
<t>This document defines Secure/Multipurpose Internet Mail
Extensions (S/MIME) version 3.1. S/MIME provides a consistent way
to send and receive secure MIME data. Digital signatures provide
authentication, message integrity, and non-repudiation with proof
of origin. Encryption provides data confidentiality. Compression
can be used to reduce data size. This document obsoletes RFC 2633.
[STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3851" />
<format octets="53328" target="ftp://ftp.isi.edu/in-notes/rfc3851.txt"
type="TXT" />
</reference>
<reference anchor="RFC3725">
<front>
<title>Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<date month="April" year="2004" />
<abstract>
<t>Third party call control refers to the ability of one entity to
create a call in which communication is actually between other
parties. Third party call control is possible using the mechanisms
specified within the Session Initiation Protocol (SIP). However,
there are several possible approaches, each with different
benefits and drawbacks. This document discusses best current
practices for the usage of SIP for third party call control. This
document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="85" />
<seriesInfo name="RFC" value="3725" />
<format octets="77308" target="ftp://ftp.isi.edu/in-notes/rfc3725.txt"
type="TXT" />
</reference>
<reference anchor="RFC3427">
<front>
<title>Change Process for the Session Initiation Protocol
(SIP)</title>
<author fullname="A. Mankin" initials="A." surname="Mankin">
<organization></organization>
</author>
<author fullname="S. Bradner" initials="S." surname="Bradner">
<organization></organization>
</author>
<author fullname="R. Mahy" initials="R." surname="Mahy">
<organization></organization>
</author>
<author fullname="D. Willis" initials="D." surname="Willis">
<organization></organization>
</author>
<author fullname="J. Ott" initials="J." surname="Ott">
<organization></organization>
</author>
<author fullname="B. Rosen" initials="B." surname="Rosen">
<organization></organization>
</author>
<date month="December" year="2002" />
<abstract>
<t>This memo documents a process intended to apply architectural
discipline to the future development of the Session Initiation
Protocol (SIP). There have been concerns with regards to new SIP
proposals. Specifically, that the addition of new SIP features can
be damaging towards security and/or greatly increase the
complexity of the protocol. The Transport Area directors, along
with the SIP and Session Initiation Proposal Investigation
(SIPPING) working group chairs, have provided suggestions for SIP
modifications and extensions. This document specifies an Internet
Best Current Practices for the Internet Community, and requests
discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="67" />
<seriesInfo name="RFC" value="3427" />
<format octets="26234" target="ftp://ftp.isi.edu/in-notes/rfc3427.txt"
type="TXT" />
</reference>
<reference anchor="RFC3841">
<front>
<title>Caller Preferences for the Session Initiation Protocol
(SIP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="P. Kyzivat" initials="P." surname="Kyzivat">
<organization></organization>
</author>
<date month="August" year="2004" />
<abstract>
<t>This document describes a set of extensions to the Session
Initiation Protocol (SIP) which allow a caller to express
preferences about request handling in servers. These preferences
include the ability to select which Uniform Resource Identifiers
(URI) a request gets routed to, and to specify certain request
handling directives in proxies and redirect servers. It does so by
defining three new request header fields, Accept-Contact,
Reject-Contact, and Request-Disposition, which specify the
caller's preferences. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3841" />
<format octets="61382" target="ftp://ftp.isi.edu/in-notes/rfc3841.txt"
type="TXT" />
</reference>
<reference anchor="RFC3372">
<front>
<title>Session Initiation Protocol for Telephones (SIP-T): Context
and Architectures</title>
<author fullname="A. Vemuri" initials="A." surname="Vemuri">
<organization></organization>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization></organization>
</author>
<date month="September" year="2002" />
</front>
<seriesInfo name="BCP" value="63" />
<seriesInfo name="RFC" value="3372" />
<format octets="49893" target="ftp://ftp.isi.edu/in-notes/rfc3372.txt"
type="TXT" />
</reference>
<reference anchor="RFC3265">
<front>
<title>Session Initiation Protocol (SIP)-Specific Event
Notification</title>
<author fullname="A.B. Roach" initials="A.B." surname="Roach">
<organization></organization>
</author>
<date month="June" year="2002" />
<abstract>
<t>This document describes an extension to the Session Initiation
Protocol (SIP). The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification
from remote nodes indicating that certain events have occurred.
[STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3265" />
<format octets="89005" target="ftp://ftp.isi.edu/in-notes/rfc3265.txt"
type="TXT" />
</reference>
<reference anchor="RFC3458">
<front>
<title>Message Context for Internet Mail</title>
<author fullname="E. Burger" initials="E." surname="Burger">
<organization></organization>
</author>
<author fullname="E. Candell" initials="E." surname="Candell">
<organization></organization>
</author>
<author fullname="C. Eliot" initials="C." surname="Eliot">
<organization></organization>
</author>
<author fullname="G. Klyne" initials="G." surname="Klyne">
<organization></organization>
</author>
<date month="January" year="2003" />
<abstract>
<t>This memo describes a new RFC 2822 message header,
"Message-Context". This header provides information about the
context and presentation characteristics of a message. A receiving
user agent (UA) may use this information as a hint to optimally
present the message. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3458" />
<format octets="34181" target="ftp://ftp.isi.edu/in-notes/rfc3458.txt"
type="TXT" />
</reference>
<reference anchor="RFC3428">
<front>
<title>Session Initiation Protocol (SIP) Extension for Instant
Messaging</title>
<author fullname="B. Campbell" initials="B." surname="Campbell">
<organization></organization>
</author>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="C. Huitema" initials="C." surname="Huitema">
<organization></organization>
</author>
<author fullname="D. Gurle" initials="D." surname="Gurle">
<organization></organization>
</author>
<date month="December" year="2002" />
<abstract>
<t>Instant Messaging (IM) refers to the transfer of messages
between users in near real-time. These messages are usually, but
not required to be, short. IMs are often used in a conversational
mode, that is, the transfer of messages back and forth is fast
enough for participants to maintain an interactive conversation.
This document proposes the MESSAGE method, an extension to the
Session Initiation Protocol (SIP) that allows the transfer of
Instant Messages. Since the MESSAGE request is an extension to
SIP, it inherits all the request routing and security features of
that protocol. MESSAGE requests carry the content in the form of
MIME body parts. MESSAGE requests do not themselves initiate a SIP
dialog; under normal usage each Instant Message stands alone, much
like pager messages. MESSAGE requests may be sent in the context
of a dialog initiated by some other SIP request. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3428" />
<format octets="41475" target="ftp://ftp.isi.edu/in-notes/rfc3428.txt"
type="TXT" />
</reference>
<reference anchor="RFC4028">
<front>
<title>Session Timers in the Session Initiation Protocol
(SIP)</title>
<author fullname="S. Donovan" initials="S." surname="Donovan">
<organization></organization>
</author>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<date month="April" year="2005" />
</front>
<seriesInfo name="RFC" value="4028" />
<format octets="65363" target="ftp://ftp.isi.edu/in-notes/rfc4028.txt"
type="TXT" />
</reference>
<reference anchor="RFC4145">
<front>
<title>TCP-Based Media Transport in the Session Description Protocol
(SDP)</title>
<author fullname="D. Yon" initials="D." surname="Yon">
<organization></organization>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<date month="September" year="2005" />
<abstract>
<t>This document describes how to express media transport over TCP
using the Session Description Protocol (SDP). It defines the SDP
'TCP' protocol identifier, the SDP 'setup' attribute, which
describes the connection setup procedure, and the SDP 'connection'
attribute, which handles connection reestablishment. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4145" />
<format octets="30225" target="ftp://ftp.isi.edu/in-notes/rfc4145.txt"
type="TXT" />
</reference>
<reference anchor="RFC4240">
<front>
<title>Basic Network Media Services with SIP</title>
<author fullname="E. Burger" initials="E." surname="Burger">
<organization></organization>
</author>
<author fullname="J. Van Dyke" initials="J." surname="Van Dyke">
<organization></organization>
</author>
<author fullname="A. Spitzer" initials="A." surname="Spitzer">
<organization></organization>
</author>
<date month="December" year="2005" />
<abstract>
<t>In SIP-based networks, there is a need to provide basic network
media services. Such services include network announcements, user
interaction, and conferencing services. These services are basic
building blocks, from which one can construct interesting
applications. In order to have interoperability between servers
offering these building blocks (also known as Media Servers) and
application developers, one needs to be able to locate and invoke
such services in a well defined manner.</t><t> This
document describes a mechanism for providing an interoperable
interface between Application Servers, which provide application
services to SIP-based networks, and Media Servers, which provide
the basic media processing building blocks. This memo provides
information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4240" />
<format octets="54976" target="ftp://ftp.isi.edu/in-notes/rfc4240.txt"
type="TXT" />
</reference>
<reference anchor="RFC4730">
<front>
<title>A Session Initiation Protocol (SIP) Event Package for Key
Press Stimulus (KPML)</title>
<author fullname="E. Burger" initials="E." surname="Burger">
<organization></organization>
</author>
<author fullname="M. Dolly" initials="M." surname="Dolly">
<organization></organization>
</author>
<date month="November" year="2006" />
<abstract>
<t>This document describes a SIP Event Package "kpml" that enables
monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses
Extensible Markup Language (XML) documents referred to as Key
Press Markup Language (KPML). The kpml Event Package may be used
to support applications consistent with the principles defined in
the document titled "A Framework for Application Interaction in
the Session Initiation Protocol (SIP)". The event package uses
SUBSCRIBE messages and allows for XML documents that define and
describe filter specifications for capturing key presses (DTMF
Tones) entered at a presentation-free User Interface SIP User
Agent (UA). The event package uses NOTIFY messages and allows for
XML documents to report the captured key presses (DTMF tones),
consistent with the filter specifications, to an Application
Server. The scope of this package is for collecting supplemental
key presses or mid-call key presses (triggers). [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4730" />
<format octets="120186"
target="ftp://ftp.isi.edu/in-notes/rfc4730.txt" type="TXT" />
</reference>
<reference anchor="RFC4960">
<front>
<title>Stream Control Transmission Protocol</title>
<author fullname="R. Stewart" initials="R." surname="Stewart">
<organization></organization>
</author>
<date month="September" year="2007" />
<abstract>
<t>This document obsoletes RFC 2960 and RFC 3309. It describes the
Stream Control Transmission Protocol (SCTP). SCTP is designed to
transport Public Switched Telephone Network (PSTN) signaling
messages over IP networks, but is capable of broader
applications.</t><t> SCTP is a reliable transport
protocol operating on top of a connectionless packet network such
as IP. It offers the following services to its
users:</t><t> -- acknowledged error-free
non-duplicated transfer of user data,</t><t> -- data
fragmentation to conform to discovered path MTU
size,</t><t> -- sequenced delivery of user messages
within multiple streams, with an option for order-of-arrival
delivery of individual user messages,</t><t> --
optional bundling of multiple user messages into a single SCTP
packet, and</t><t> -- network-level fault tolerance
through supporting of multi-homing at either or both ends of an
association.</t><t> The design of SCTP includes
appropriate congestion avoidance behavior and resistance to
flooding and masquerade attacks. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4960" />
<format octets="346022"
target="ftp://ftp.isi.edu/in-notes/rfc4960.txt" type="TXT" />
</reference>
<reference anchor="RFC4975">
<front>
<title>The Message Session Relay Protocol (MSRP)</title>
<author fullname="B. Campbell" initials="B." surname="Campbell">
<organization></organization>
</author>
<author fullname="R. Mahy" initials="R." surname="Mahy">
<organization></organization>
</author>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization></organization>
</author>
<date month="September" year="2007" />
<abstract>
<t>This document describes the Message Session Relay Protocol, a
protocol for transmitting a series of related instant messages in
the context of a session. Message sessions are treated like any
other media stream when set up via a rendezvous or session
creation protocol such as the Session Initiation Protocol.
[STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4975" />
<format octets="144254"
target="ftp://ftp.isi.edu/in-notes/rfc4975.txt" type="TXT" />
</reference>
<reference anchor="RFC5022">
<front>
<title>Media Server Control Markup Language (MSCML) and
Protocol</title>
<author fullname="J. Van Dyke" initials="J." surname="Van Dyke">
<organization></organization>
</author>
<author fullname="E. Burger" initials="E." surname="Burger">
<organization></organization>
</author>
<author fullname="A. Spitzer" initials="A." surname="Spitzer">
<organization></organization>
</author>
<date month="September" year="2007" />
<abstract>
<t>Media Server Control Markup Language (MSCML) is a markup
language used in conjunction with SIP to provide advanced
conferencing and interactive voice response (IVR) functions. MSCML
presents an application-level control model, as opposed to
device-level control models. One use of this protocol is for
communications between a conference focus and mixer in the IETF
SIP Conferencing Framework. This memo provides information for the
Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5022" />
<format octets="184482"
target="ftp://ftp.isi.edu/in-notes/rfc5022.txt" type="TXT" />
</reference>
<reference anchor="RFC5057">
<front>
<title>Multiple Dialog Usages in the Session Initiation
Protocol</title>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization></organization>
</author>
<date month="November" year="2007" />
<abstract>
<t>Several methods in the Session Initiation Protocol (SIP) can
create an association between endpoints known as a dialog. Some of
these methods can also create a different, but related,
association within an existing dialog. These multiple
associations, or dialog usages, require carefully coordinated
processing as they have independent life-cycles, but share common
dialog state. Processing multiple dialog usages correctly is not
completely understood. What is understood is difficult to
implement.</t><t> This memo argues that multiple
dialog usages should be avoided. It discusses alternatives to
their use and clarifies essential behavior for elements that
cannot currently avoid them.</t><t> This is an
informative document and makes no normative statements of any
kind. This memo provides information for the Internet
community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5057" />
<format octets="62654" target="ftp://ftp.isi.edu/in-notes/rfc5057.txt"
type="TXT" />
</reference>
<reference anchor="RFC5168">
<front>
<title>XML Schema for Media Control</title>
<author fullname="O. Levin" initials="O." surname="Levin">
<organization></organization>
</author>
<author fullname="R. Even" initials="R." surname="Even">
<organization></organization>
</author>
<author fullname="P. Hagendorf" initials="P." surname="Hagendorf">
<organization></organization>
</author>
<date month="March" year="2008" />
<abstract>
<t>This document defines an Extensible Markup Language (XML)
Schema for video fast update in a tightly controlled environment,
developed by Microsoft, Polycom, Radvision and used by multiple
vendors. This document describes a method that has been deployed
in Session Initiation Protocol (SIP) based systems over the last
three years and is being used across real-time interactive
applications from different vendors in an interoperable manner.
New implementations are discouraged from using the method
described except for backward compatibility purposes. New
implementations are required to use the new Full Intra Request
command in the RTP Control Protocol (RTCP) channel. This memo
provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5168" />
<format octets="17845" target="ftp://ftp.isi.edu/in-notes/rfc5168.txt"
type="TXT" />
</reference>
<reference anchor="W3C.REC-voicexml21-20070619"
target="http://www.w3.org/TR/2007/REC-voicexml21-20070619">
<front>
<title>Voice Extensible Markup Language (VoiceXML) 2.1</title>
<author fullname="Brad Porter" initials="B." surname="Porter">
<organization></organization>
</author>
<author fullname="Scott McGlashan" initials="S." surname="McGlashan">
<organization></organization>
</author>
<author fullname="Alex Lee" initials="A." surname="Lee">
<organization></organization>
</author>
<author fullname="Daniel C. Burnett" initials="D." surname="Burnett">
<organization></organization>
</author>
<author fullname="Jerry Carter" initials="J." surname="Carter">
<organization></organization>
</author>
<author fullname="Matt Oshry" initials="M." surname="Oshry">
<organization></organization>
</author>
<author fullname="Michael Bodell" initials="M." surname="Bodell">
<organization></organization>
</author>
<author fullname="Paolo Baggia" initials="P." surname="Baggia">
<organization></organization>
</author>
<author fullname="Ken Rehor" initials="K." surname="Rehor">
<organization></organization>
</author>
<author fullname="David Burke" initials="D." surname="Burke">
<organization></organization>
</author>
<author fullname="Emily Candell" initials="E." surname="Candell">
<organization></organization>
</author>
<author fullname="RJ Auburn" initials="R." surname="Auburn">
<organization></organization>
</author>
<date day="19" month="June" year="2007" />
</front>
<seriesInfo name="World Wide Web Consortium Recommendation"
value="REC-voicexml21-20070619" />
<format target="http://www.w3.org/TR/2007/REC-voicexml21-20070619"
type="HTML" />
</reference>
<reference anchor="I-D.ietf-speechsc-mrcpv2">
<front>
<title>Media Resource Control Protocol Version 2 (MRCPv2)</title>
<author fullname="Saravanan Shanmugham" initials="S"
surname="Shanmugham">
<organization></organization>
</author>
<author fullname="Daniel Burnett" initials="D" surname="Burnett">
<organization></organization>
</author>
<date day="2" month="June" year="2009" />
<abstract>
<t>The MRCPv2 protocol allows client hosts to control media
service resources such as speech synthesizers, recognizers,
verifiers and identifiers residing in servers on the network.
MRCPv2 is not a "stand-alone" protocol - it relies on other
protocols, such as Session Initiation Protocol (SIP) to rendezvous
MRCPv2 clients and servers and manage sessions between them, and
the Session Description Protocol (SDP) to describe, discover and
exchange capabilities. It also depends on SIP and SDP to establish
the media sessions and associated parameters between the media
source or sink and the media server. Once this is done, the MRCPv2
protocol exchange operates over the control session established
above, allowing the client to control the media processing
resources on the speech resource server.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-speechsc-mrcpv2-19" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-speechsc-mrcpv2-19.txt"
type="TXT" />
</reference>
<reference anchor="I-D.saleem-msml">
<front>
<title>Media Server Markup Language (MSML)</title>
<author fullname="Garland Sharratt" initials="G" surname="Sharratt">
<organization></organization>
</author>
<author fullname="Adnan Saleem" initials="A" surname="Saleem">
<organization></organization>
</author>
<date day="3" month="February" year="2009" />
<abstract>
<t>The Media Server Markup Language (MSML) is used to control and
invoke many different types of services on IP Media Servers.
Clients can use it to define how multimedia sessions interact on a
Media Server and to apply services to individuals or groups of
users. MSML can be used, for example, to control Media Server
conferencing features such as video layout and audio mixing,
create sidebar conferences or personal mixes, and set the
properties of media streams. As well, clients can use MSML to
define media processing dialogs, which may be used as parts of
application interactions with users or conferences. Transformation
of media streams to and from users or conferences as well as IVR
dialogs are examples of such interactions, which are specified
using MSML. MSML clients may also invoke dialogs with individual
users or with groups of conference participants using
VoiceXML.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-saleem-msml-08" />
<format target="http://www.ietf.org/internet-drafts/draft-saleem-msml-08.txt"
type="TXT" />
</reference>
</references>
<section anchor="S.info-packages" title="Info Package Considerations">
<t>This section covers several issues that one should take into
consideration when proposing new Info Packages.</t>
<section anchor="nil" title="Appropriateness of Usage">
<t>When designing an Info Package using the method described in this
document for application level information exchange, it is important
to consider: is INFO and, more importantly, is signaling within a SIP
session, an appropriate mechanism for the problem set? Is it because
it is the most reasonable and appropriate choice, or merely because
"it's easy"?</t>
<t>These are difficult issues to consider, especially when presented
with real-world deadlines and implementation cost issues. However,
choosing to use INFO for inappropriate uses *will* lead to issues in
the real world, not the least of which are certain types of
middleboxes which will remove the device from the network if it is
found to cause damage to other SIP nodes.</t>
<t>Therefore, the following sections provide consideration guidelines
and alternatives to INFO use.</t>
</section>
<section title="Dialog Fate-Sharing">
<t>INFO, by design, is a method within an INVITE dialog usage. <xref
target="RFC5057">RFC 5057</xref> enumerates the problems with using
dialogs for multiple usages, and we strongly urge the reader to review
RFC 5057. The most relevant issue is a failure of transmission or
processing of an INFO request may render the INVITE session
terminated, depending on the type of failure. Prior to RFC 5057, it
was not clear if the INFO usage was a separate usage or not. RFC 5057
clarifies the INFO method is always part of the INVITE usage.</t>
<t>Some uses of INFO can tolerate this fate sharing of the INFO
message over the entire session. For example, in the SIP-T usage, it
may be acceptable for a call to fail, or to tear down the call, if one
cannot deliver the associated SS7 information. The same is usually
true for DTMF. However, it may not be acceptable for a call to fail
if, for example, a DTMF buffer overflows. Then again, for some
services, that may be the exact desired behavior.</t>
</section>
<section title="Messaging Rates and Volume">
<t>There is no throttling mechanism for INFO. Consider that most call
signaling occurs on the order of 7-10 messages per 3 minutes, although
with a burst of 5-7 messages in one second during call setup. DTMF
tones occur in bursts at a rate of up to 20 messages per second. This
is a considerably higher rate than for call signaling. Sending
constant GPS location updates, on the other hand, would incur an undue
burden on SIP Proxies along the path.</t>
<t>Furthermore, SIP messages tend to be relatively small, on the order
of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct exchange
of bulk data beyond these limits, especially if the headers plus body
exceed the <xref target="RFC0768">UDP MTU</xref>. Appropriate
mechanisms for such traffic include <xref
target="RFC4975">MSRP</xref>, <xref target="RFC4145">COMEDIA</xref>,
or <xref target="RFC2616">HTTP</xref>.</t>
</section>
<section title="Is there a better alternative?">
<t>The first alternative for application level interaction is SIP
Events, also known as <xref target="RFC3265">SUBSCRIBE/NOTIFY</xref>.
In this model, a user agent requests state information, such as key
pad presses from a device to an application server or key map images
from an application server to a device. The SUBSCRIBE creates a new
session that does not share the fate of the related INVITE-initiated
session. Moreover, using the SUBSCRIBE model enables multiple
applications to receive state updates. These applications can be
outside the media path and potentially outside the INVITE-initiated
session's proxy path. In fact, SIUBSCRIBE/NOTIFY is your only option
if you need to exchange data outside a communications session.</t>
<t>SUBSCRIBE/NOTIFY messages pass through the SIP signaling
infrastructure, such as SIP Proxies and B2BUAs. Application designers
need to understand this can be a feature, as when the User Agents are
exchanging information that elements in the SIP signaling path need to
be aware of. Conversely, this can be a problem, as messages these
network elements have no interest in can put a significant burden on
those element's ability to process other traffic. Moreover, such
network elements may not be able to read end-to-end encrypted
SUBSCRIBE or NOTIFY bodies.</t>
<t>Implementers do need to be aware the price of having a protocol
that works in all cases, can scale, can easily load balance, and will
not mysteriously fail a session in the event of state synchronization
failure does come at a cost. Session establishment is a minimum of two
messages in addition to the INVITE session establishment. If the
SUBSCRIBE application is co-resident with the INVITE application, the
application will have to manage two SIP sessions instead of one.
Tracking the application level state dominates memory and processing
for some applications, and as such, the doubling of SIP sessions is
not an issue. However, for other applications, this may be an
issue.</t>
<t>The <xref target="RFC3428">MESSAGE method</xref> defines one-time
instant message exchange, typically for sending MIME contents for
rendering to the user.</t>
<t>Another model for application level information exchange is to
establish a communication channel in the media plane. One model for
this is <xref target="I-D.ietf-speechsc-mrcpv2">MRCPv2</xref>. Here,
the INVITE-initiated session establishes a separate reliable,
connection-oriented channel, such as a <xref
target="RFC0793">TCP</xref> or <xref target="RFC4960">SCTP</xref>
stream. One uses SIP to locate the remote endpoint, but uses a direct
connection for the UUI. One then can create whatever protocol one
wishes, whether from scratch (as in MRCPv2) or using a substrate such
as <xref target="RFC3080">BEEP</xref>.</t>
<t>A low latency requirement for the exchange of information is one
strong indicator for using a media channel. Exchanging information
through the SIP routing network can introduce hundreds of milliseconds
of latency. In addition, if there will be a lot of information
exchanged, and there is no need for the SIP routing network to examine
the information, one should use a separate media channel.</t>
<t>Another model is to use a totally externally signaled channel, such
as <xref target="RFC2616">HTTP</xref>. In this model, the user agent
knows about a rendezvous point to direct HTTP requests to for the
transfer of information. Examples include encoding of a prompt to
retrieve in the SIP Request URI in <xref target="RFC4240">RFC
4240</xref> or the encoding of a SUBMIT target in a <xref
target="W3C.REC-voicexml21-20070619">VoiceXML</xref> script.</t>
<t><xref target="RFC4975">MSRP</xref> defines session-based instant
messaging as well as bulk file transfer and other such large-volume
uses. It is part of an INVITE-based session, similar to other media.
Unlike INFO, MSRP follows a direct media path, rather than through the
network elements composing the SIP signaling path.</t>
<t>A common reason people in the past used INFO for application level
information exchange is the negotiation is very lightweight compared
to SUBSCRIBE/NOTIFY. This is more especially so if it is not certain
if there will be application level information exchange. The
SUBSCRIBE/NOTIFY machinery requires the user agents to exchange rich
capabilities and maintain state for additional SIP sessions. However,
this is a weak argument if there is a high likelihood of application
level information exchange. In this case, we recommend the use of a
more robust application level information exchange protocol.</t>
</section>
<section anchor="S.Alternatives"
title="Alternatives for Common INFO Use">
<t>What alternatives to INFO are there for UA-to-UA application
session signaling? As noted above, there are three broad classes of
session signaling available. The choice depends on the circumstances.
Following is a list of situations that have used INFO in the
past.<list style="symbols">
<t>State updates</t>
<t>User stimulus</t>
<t>Direct signaling channel</t>
<t>Proxy-aware signaling</t>
<t>Dialog probe</t>
</list></t>
<section title="State Updates">
<t>This is the broad class of one User Agent updating another with
changes in state. The design goal of the <xref
target="RFC3265">SUBSCRIBE/NOTIFY</xref> event framework is to meet
just this need.</t>
</section>
<section title="User Stimulus: Touch Tones and Others">
<t>This is the class of the user entering stimulus at one User
Agent, and the User Agent transporting that stimulus to the other. A
key thing to realize is key presses on the telephone keypad is user
stimulus. Thus, the appropriate mechanism to use here is <xref
target="RFC4730">KPML</xref>.</t>
</section>
<section title="Direct Signaling Channel">
<t>State updates and user stimulus tend to have relatively few
messages per session. Sometimes, User Agents need to exchange a
relatively high number of messages. In addition, User Agents may
have a need for a relatively low-latency exchange of messages. In
this latter case, the User Agent may not be able to tolerate the
latency introduced by intermediate proxies. Likewise, the
intermediate proxies may have no interest in processing all of that
data.</t>
<t>In this case, establishing a separate, direct control channel, as
in <xref target="RFC4975">MSRP</xref> or <xref
target="I-D.ietf-speechsc-mrcpv2">MRCPv2</xref> is appropriate.</t>
<t>In addition, not every situation requires a SIP solution. Some
signaling is really just one-shot to third-party endpoints. That
situation may better be handled using an appropriate protocol, such
as <xref target="RFC2616">HTTP</xref>.</t>
</section>
<section title="Proxy-Aware Signaling">
<t>Sometimes, one does want proxies to be in the signaling path for
UA-to-UA application signaling. In this case, the use of a SIP
request is appropriate. To date, there are no mechanisms for
completely disambiguating INFO requests. For example, one could
create a registry of INFO packages. The definition of the package
would define the contexts for the various MIME Content-Types, as
well as the context of the request itself. However, a package can
have multiple content types. Moreover, having the context, or
package identifier, at the SIP level precludes bundling multiple
contexts responding in the same INFO request. For example, a User
Agent might want to bundle two different responses in a
multipart/mixed MIME body type.</t>
<t>Because there is no difference in either the protocol machinery
or registration process due to these factors, we will not create an
INFO framework. If one needs a SIP User Agent-to-SIP User Agent
application session signaling transport protocol that touches all
Record-Route proxies in a path, one MUST create a new SIP method as
described in Section 27.4 of <xref target="RFC3261">RFC
3261</xref>.</t>
</section>
<section title="Dialog Probe">
<t>Some implementations in the wild use INFO to probe if an
INVITE-initiated session is alive. While this works, it is NOT
RECOMMENDED. In particular, <xref target="RFC4028">RFC 4028</xref>
describes how to ensure an INVITE-initiated session is alive.</t>
</section>
<section title="Malicious Indicator">
<t>Take the case of Malicious Indicator. This is where a subscriber
receives a call, realizes it is a malicious call (threatening, SPIT,
etc.). They then press the SPIT button (or press *xx), which tells
their service provider to mark the UAC as a bad actor. One might be
tempted to think that INFO would be a great option for this service.
It follows the return path of the INVITE, and so the INFO will hit
the caller's inbound proxy, which it can learn the caller is
(statistically) a bad actor. That way the inbound proxy can do stuff
like notify law enforcement, add a vote to "this is a SPIT source,"
or other useful action.</t>
<t>However, consider a few issues. First, since INFO lives
exclusively within an established session, there is no way to assert
this message after the call completes. Second, this mechanism relies
on an active service provider topology. If there is no proxy in the
chain that will eat the INFO, the caller will see the "this is a bad
guy" message, which may have consequences in the real world. Third,
there is no a'priori way for the UAS to know whether it can issue
the INFO. The caller certainly will not advertise, "please tell me
if I am bad, particularly I know in advance that I *am* a bad
actor."</t>
<t>One approach is for the service provider's proxy to SUBSCRIBE for
the SPIT event at the UAS. At this point, life is good,
interoperable, and works across networks. This enables events after
the session is torn down, as presumably the SPIT event will refer
not to, "this session," which does not exist, but to "that session
identifier," which exists (and is theoretically unique) forever.</t>
<t>Another approach that saves considerably on the overhead of
subscriptions would be for the service provider to insert a HTTP URI
in the initial INVITE, noting it is for reporting malicious
behavior. When the subscriber presses the SPIT button, an HTTP POST
gets executed, delivering the call information to the service
provider. The service provider can encode basic call information in
the HTTP URI and can instruct the device to send whatever arbitrary
data is necessary in the POST. This method has the added benefit of
being entirely outside the real-time SIP proxy network.</t>
</section>
</section>
</section>
<section anchor="S.legacy" title="Legacy INFO Usages">
<t>We do not intend this section to be a comprehensive catalog of INFO
usages. However, it should give the reader a flavor for current INFO
usages.</t>
<section title="ISUP">
<t>SIP-T uses Content-Type to identify ISUP protocol elements in an
INFO message. See <xref target="RFC3372">RFC3372</xref>.</t>
</section>
<section title="QSIG">
<t>QSIG uses Content-Type to identify QSIG protocol elements in an
INFO message. See <xref target="RFC4497">RFC4497</xref>.</t>
</section>
<section title="MSCML">
<t>MSCML uses a Require to ensure the UAS understands that INFO
messages of the MSCML type are in fact MSCML messages. See <xref
target="RFC5022">RFC5022</xref>.</t>
</section>
<section title="MSML">
<t>MSML endpoints just know the INFO messages carry MSML and from the
Content-Type of the given INFO method request. See the <xref
target="I-D.saleem-msml">MSML</xref> draft.</t>
</section>
<section title="Video Fast Update">
<t>Microsoft, Polycom, and Radvision used INFO messages as an interim
solution for requesting fast video update before the ability to
request I-Frames in RTCP was available. See the <xref
target="RFC5168">XML Schema for Media Control</xref> for more
information.</t>
</section>
</section>
<section title="Acknowledgements">
<t>We are standing on the shoulders of giants. Jonathan Rosenberg did
the original "INFO Considered Harmful" Internet Draft on 26 December
2002, which influenced the work group and this document. Likewise, Dean
Willis influenced the text from his Internet Draft, "Packaging and
Negotiation of INFO Methods for the Session Initiation Protocol" of 15
January 2003. Four paragraphs come from Jonathan Rosenberg's INFO Litmus
draft. My, we have been working on this for a long time!</t>
<t>This and other related drafts have elicited well over 450 messages on
the SIP list. People who have argued with its thesis, supported its
thesis, added to the examples, or argued with the examples, include the
following individuals:<list style="empty">
<t>Adam Roach, Bram Verburg, Brian Stucker, Chris Boulton, Cullen
Jennings, Dale Worley, Dean Willis, Frank Miller, Gonzalo Camarillo,
Gordon Beith, Henry Sinnreich, James Jackson, James Rafferty, Jeroen
van Bemmel, Joel Halpern, John Elwell, Johnathan Rosenberg, Juha
Heinanen, Keith Drage, Kevin Attard Compagno, Manpreet Singh, Martin
Dolly, Mary Barnes, Michael Procter, Paul Kyzivat, Peili Xu, Peter
Blatherwick, Raj Jain, Rayees Khan, Robert Sparks, Roland Jesske,
Salvatore Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve
Langstaff, Sumit Garg, and Xavier Marjou.</t>
</list></t>
<t>John Elwell and Francois Audet helped with QSIG references. In
addition, Francois Audet provided actual text for the revised abstract.
Keith Drage gave lots of excellent comments and helped immensely with
<xref target="T.headers"></xref>.</t>
<t>The work group version of this document benefited from the close
readings and comments from <list style="empty">
<t>John Elwell, Paul Kyzivat, Dean Willis, Francois Audet, Dale
Worley, Andrew Allen, Adam Roach, Anders Kristensen, Gordon Beith,
Ben Campbell, Bob Penfield, Keith Drage, Jeroen van Bemmel, Mary
Barnes, and Salvatore Loreto.</t>
</list></t>
<t>Since publication of the first work group version of this document,
we have had over 329 messages. New voices in addition to those included
above include<list style="empty">
<t>Arun Arunachalam, Christian Stredicke, Eric Rescorla, Inaki Baz
Castillo, and Roni Evan.</t>
</list></t>
<t>However, any errors and issues we missed are still our own.</t>
</section>
<section title="Change Log">
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
<t>Changes from draft-ietf-sip-info-events-03<list style="symbols">
<t>Clarified Abstract language</t>
<t>All SIP dialogs are now refered to as sessions</t>
<t>Clarified the image example in the Introduction</t>
<t>Clarified the relationship (none) between SIP Event Packages and
SIP Info Packages</t>
<t>Really, really clarified the protocol is NOT a negotiation but an
advertisement</t>
<t>Split Section 3 into UAS and UAC behavior</t>
<t>Moved the example in section 3 into its own sub-section, and used
full SIP headers</t>
<t>Clarified forking behavior</t>
<t>Clarified language around when to send a body</t>
<t>Added 469 error response, instead of reusing 489</t>
<t>Clarified overlapping INFO method handling</t>
<t>Fixed table 1 to follow 3261, not 2543</t>
<t>Added REFER to the INFO Headers table</t>
<t>replaced token-nodot with token for Info-Package values</t>
<t>Clarified end-to-end security considerations</t>
<t>Info Package parameters are semi-colon delimited, not dot
delimited</t>
</list></t>
<t>Changes from -02<list style="symbols">
<t>Applicability statement explicitly says we're backwards
compatible</t>
<t>Explicitly state we work like UPDATE (both early and confirmed
dialogs)</t>
<t>Agreed text for IANA Considerations package registry</t>
</list></t>
<t>Changes from -01<list style="symbols">
<t>One and only one Info Package per INFO</t>
<t>Removed Send-Info header, greatly simplifying negotiation</t>
<t>Multiple body part identification through Content-Disposition:
Info-Package</t>
<t>Note that forking INVITEs may result in multiple INFO's coming
back to INVITE originator</t>
<t>Describe how a UAS can enforce strict adherence to this
document</t>
<t>Remove CANCEL INFO faux pas</t>
<t>Better explained overlapping INFO issues and resolutions</t>
<t>Token names are now really case sensitive</t>
<t>Moved Info Package Considerations to an Appendix</t>
<t>Introduced stronger, yet more open, IANA registration process</t>
<t>Took a few more paragraphs from INFO Litmus to cover all
bases.</t>
<t>Added RFC 5168 to legacy usages</t>
</list></t>
<t>Changes from -00<list style="symbols">
<t>Corrected ABNF.</t>
<t>Enabled sending of legacy INFO messages. Receiving legacy INFO
messages was already here.</t>
<t>Negotiation is not Offer/Answer, it is Offer/Offer.</t>
<t>Created the explicit "nil" Info Package to indicate no info
package.</t>
<t>Fixed CANCEL impacting future transactions.</t>
<t>Added Registrar behavior.</t>
<t>Added OPTIONS processing.</t>
<t>Clarified overlapping INFO method processing.</t>
<t>Described multiple INFO bodies in a single INFO method.</t>
<t>Took out Info-Package as a header for responses to the INFO
method.</t>
<t>Expanded on risks of using INFO and filled-in more on the
alternatives</t>
<t>Moved definitions of INFO into the body of the text and cleaned
up IANA Considerations section</t>
<t>Added legacy usages descriptions</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-25 01:56:44 |