One document matched: draft-ietf-sip-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-sip-info-events-00" ipr="full3978"
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>This Space Available to the Most Interesting
Bidder</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></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="20" month="October" year="2008" />
<area>RAI</area>
<workgroup>SIP</workgroup>
<abstract>
<t>This document defines the new INFO method and a mechanism for
defining, negotiating and exchanging Info Packages that use the INFO
method. Applications which need to exchange session-related information
within a SIP INVITE-created dialog 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>.</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>, on the other hand, is to carry application level
information along the SIP signaling path.</t>
<t>While INFO use 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, provides a framework
for explicit negotiation of capabilities and content context using "Info
Packages".</t>
<t>The INFO method does not provide any context for the information
which it carries. 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 is no indication what the purpose of the image is. The image could
be a caller-id picture, a contact icon, a photo for sharing, and so on.
The sender does not know which JPEG to give the receiver if the receiver
supports a JPEG content type, and the receiver does not know which JPEG
the client is sending if the receiver supports receiving more than one
JPEG content type. Thus there needs to be 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 information
exchange. The mechanism defined in this draft has no relationship to the
SUBSCRIBE and NOTIFY methods. The mechanism defined here neither creates
a separate subscription dialog nor a subscription usage within an
existing dialog. Instead, it uses the INVITE method and its responses to
indicate and negotiate supported Info Packages, and the INFO method to
convey the Info Packages. This mechanism is not appropriate for
IANA-registered <xref target="RFC3265">Subscribe Event</xref> package
types. Info Package definitions and registrations indicate support for
this mechanism when one registers them with IANA.</t>
<t>Each UA enumerates which Info Packages it can send and receive. If
the far end indicates it can receive a package offered by the near end,
the near end can send INFO methods containing the payload for that
package. Likewise, if the far end indicates it can send a package the
near end offers it can receive, the far end can send INFO methods
containing the payload for that package. The Recv-Info header indicates
which packages a UA is willing to receive and the Send-Info header
indicates which packages a UA is willing to send. The Package-Info
header indicates which package a particular INFO method request belongs
to. The presence of empty Send-Info and Recv-Info headers indicates the
UA conforms with this document, but does not wish to send or receive
Info Packages. This enables other UAs that conform with this document to
detect legacy UAs, as the legacy UA will not include Send-Info or
Recv-Info headers in their SIP requests. <xref target="S.Nego"></xref>
describes the negotiation 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.info-packages"></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-dialog signaling
information. These messages traverse the post-session-setup SIP
signaling path. This is the path taken by SIP re-INVITEs, BYEs, and
other SIP requests that within an individual dialog. SIP proxy servers
will receive, and potentially act on, mid-dialog 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 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>
<t>This draft replaces the <xref target="RFC2976">SIP INFO
document</xref>.</t>
</section>
<section title="Terminology">
<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>
</section>
<section title="Applicability">
<t>This draft proposes replacing the [RFC2976] <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.</t>
<t><list>
<t>RFC EDITOR NOTE: Please replace "This draft proposes replacing"
with "This draft replaces" in the final edition.</t>
</list></t>
</section>
<section anchor="S.Nego" title="Info Package Negotiation">
<t>In this section, "UAC" is the User Agent Client from the perspective
of the INVITE method. That is, it is the User Agent (UA) that sends the
initial INVITE method request. This may be somewhat confusing if the
User Agent Server (UAS) from the perspective of the INVITE method sends
an INFO method request.</t>
<section title="Info Package Negotiation Overview">
<t>Info Package negotiation is similar, but not the same, as <xref
target="RFC3264">negotiating SDP</xref>. It is similar, in that the
UAC may offer a set of Send-Info and Recv-Info packages in the initial
INVITE, the UAS offers its set of Send-Info and Recv-Info pacakges in
provisional 1xx and final 2xx responses, and the UAC may offer a final
set of Send-Info and Recv-Info packages in the ACK. Likewise, the UAC
may chose not to offer any packages in the initial INVITE, and
negotiate packages from the UAS' subsequent responses and the ACK, in
order to support <xref target="RFC3725">third-party call
control</xref>.</t>
<t>Info Package negotiation MAY occur any time the UAs negotiate
session parameters. Examples are session establishment, as described
in the above paragraph; re-INVITE; and <xref
target="RFC3311">UPDATE</xref>, to name a few. The general rule is
before a UA may begin sending INFO methods with a given Info Package,
the UAC must have first indicated it wants to send the Info Package by
listing it in a Send-Info header in the most recent dialog negotiation
and the UAS must have positively indicated it is willing to receive
the Info Package by listing it in a Recv-Info header in the most
recent dialog negotiation.</t>
<t>A UA MAY list multiple packages by enumerating the package name(s),
separated by commas, as values for the Send-Info and Recv-Info headers
in the session establishment. A UA MAY list multiple packages by
including multiple Send-Info and Recv-Info headers. A UA MAY combine
these two methods. We do NOT RECOMMEND listing a package multiple
times in a given session establishment message, but there is no harm
in doing so.</t>
<t>If a UA does not wish to receive any Info Packages, the UA MUST
indicate this by including an empty Recv-Info header. Likewise, if a
UA does not wish to send any Info Packages, the UA MUST indicate this
by including an empty Send-Info header. This enables the other UA to
discern the difference between the first UA understanding Info
Packages but not wishing to receive any from a UA that does not
understand Info Packages.</t>
<t>The UAC and UAS MUST NOT send an INFO message until the UAC and UAS
negotiate which Info Packages they support, in which direction. The
dialog state satisfies this requirement once both the UAC and UAS have
exchanged Send-Info and Recv-Info headers in the appropriate session
negotiation messages (INVITE, 1xx, 2xx, ACK, etc.). Once both UAs have
exchanged Send-Info and Recv-Info headers, the UAC MUST NOT send an
INFO message carrying a given Info-Package type if the UAC did not
advertise the package in its Send-Info and the UAS did not advertise
the package in its Recv-Info. This is the DeMorgan's Theorem of saying
the UAC may only send an INFO message for the given package if (1) the
UAC lists the package in its Send-Info and (2) the UAS lists the
package in its Recv-Info.</t>
<t>Once a UAC advertises it is willing to receive a package, it MUST
be ready to receive INFO methods carrying that package type. This is
because the UAS MAY send such INFO requests at the same time as the
UAS sends its confirming Send-Info header, and the request may arrive
out of order. This also enables early exchange of INFO methods.<list>
<t></t>
<t>[EDITOR'S NOTE: is not waiting for a dialog to fully establish
a problem? Personally, I doubt it. Even the corner cases, like
forking, do not bother me.]</t>
<t></t>
</list></t>
<t>It is important to note that if a UAS does not list a package in
its Send-Info package list, the UAS MUST NOT send Info Packages from
that package, even if the UAC listed the package in its Recv-Info
package list. The UAS will have to renegotiate the session parameters
to do this. For example, if a UAC offers</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[Send-Info: P, Q
Recv-Info: P, R
]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>and the UAS responds</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[Send-Info: P, T
Recv-Info: Q, R]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>the UAC MAY start to send INFO messages with type Q, the
intersection of {P, Q} and {Q, R}. Likewise, the UAS MAY send INFO
messages with type P, the intersection of {P, T} and {P, R}.</t>
<t>Such Info Package capability negotiation MUST occur within the
context of a single session negotiation exchange. Moreover, the last
capability set received within the exchange is the one the receiver
applies against its advertised capability set. For example, if in an
INVITE, the UAC offers</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[Send-Info: P, Q
Recv-Info: P, R]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>and the UAS in a 200 OK responds</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[Send-Info: P, T
Recv-Info: Q, R]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>and the UAC then confirms in an ACK with</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[Send-Info: P, Q
Recv-Info: T]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>the UAS can now send from package T. Moreover, in this example, the
UAS may not send form package P, as P no longer is in the UAC's Info
Package set.</t>
<t>The limitation on requiring the negotiation to occur within the
context of a session negotiation exchange means that if the UAC issues
a re-INVITE (after the above ACK) with</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[Recv-Info: P, R, T]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>the UAS MUST NOT send any package P INFO methods until the UAS
re-offers P in its Send-Info header in its 200 OK response.</t>
<t>INFO 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>.</t>
<t>The presence of the "Send-Info" or "Recv-Info" header in a message
is sufficient to indicate support for this version of INFO. Note 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 far-end UA does not
indicate support for an Info Package that the local server requires,
the server MAY terminate the session with a CANCEL or BYE request.</t>
<t>Since the protocol handshake generates some set of Send-Info and
Recv-Info packages, including the empty set, the absence of Send-Info
and Recv-Info headers at the end of session negotiation indicates a
legacy UA that does not understand the Info Package mechanism
described in this document. However, be aware a conforming UAC may
chose to not include the Send-Info and Recv-Info headers in its
initial INVITE message to a UAS, as described in the next section.</t>
</section>
<section title="UAC Behavior">
<t><list>
<t>NOTE: In this section, UAC refers to the initiator of an
INVITE-initiated dialog and not necessarily the UAC receiving an
INFO method request.</t>
<t></t>
</list>A UAC MAY indicate one or more Info Packages it wishes to
support sending during the INVITE dialog by including their
IANA-registered names in the Send-Info header field value in the
INVITE request. Including an empty Send-Info header field indicates
the UAC does not wish to send any Info Packages at this time. The UAC
MAY modify the Send-Info list at any time during session
negotiation.</t>
<t>The UAC MAY indicate one or more Info Packages it wishes to support
receiving during the INVITE-created dialog by including their Info
Package names in the Recv-Info header field in the INVITE request. Not
including the Recv-Info header field in the INVITE does not
necessarily mean the UAC will not accept Info Packages during the
dialog. The UAC MAY include a Recv-Info header in a later phase of the
session negotiation.</t>
<t>Once a UAC indicates support for receiving a given Info Package,
the UAC MUST be ready to accept INFO methods carrying that package
type.</t>
<t>When the UAC receives a Recv-Info header field in any provisional
1xx or 2xx response, it is an indication the UAS supports receiving
the Info Packages indicated in the header field value. The UAC ignores
any Info Packages in the Recv-Info header field value from the UAS the
UAC did not offer in a Send-Info header field. This situation does not
constitute a protocol failure, as the UAC is not going to send such
Info Packages. In other words such mismatches do not fail the
negotiation. However, if the UAS indicates support for receiving an
Info Package the UAC did not indicate it will send, the UAC MUST NOT
send such Info Packages.</t>
<t>When the UAC receives a Send-Info header field in any provisional
1xx or 2xx final response, it is an indication the UAS supports
sending Info Package(s) named in the header field value. Note the UAC
will only receive Info Package(s) the UAC indicates it is willing to
receive in the Recv-Info header field.</t>
<t>Once the UAC and UAS establish an early dialog through a 1xx
provisional response with To-tags, and the UAC has received a
Recv-Info header field values from the UAS in the response, the UAC
MAY send any Info Packages supported by the UAS in an INFO message.
The 2xx final response updates the state of the supported Info
Packages, such that the 2xx contains the full and final list of
Send-Info and Recv-Info Info Packages. If the 2xx contains an empty
Send-Info header field, the UAS is indicating it will not send any,
and if it contains an empty Recv-Info header field, the UAS will not
accept any, regardless of what a previous 1xx response might have
indicated. At this point negotiation is complete.</t>
<t>Similar rules apply for late Send-Info / Recv-Info negotiation,
such as an empty INVITE, followed by an offer in the 200 OK and the
response in the ACK.</t>
</section>
<section title="UAS Behavior">
<t>When a UAS receives an INVITE request, it checks for Send-Info and
Recv-Info header fields.</t>
<t>For each Info Package name in the received Send-Info header field
value, if the UAS wishes to accept receiving such Info Packages from
the UAC, the UAS MUST copy the type token name(s) of the acceptable
Info Packages into a Recv-Info header field value in any and all
subsequent provisional 1xx and final 2xx responses.</t>
<t>Likewise, for each Info Package name listed in the received
Recv-Info header field value, if the UAS wishes to send such Info
Packages to the UAC, the UAC MUST copy the name(s) of those Info
Packages it wishes to generate into a Send-Info header field value in
subsequent provisional 1xx and final 2xx responses. The UAS MAY decide
not to indicate any Info Packages in early 1xx responses, but add them
or change them in subsequent 1xx and final 2xx responses. If the UAS
no longer wishes to support an Info Package after the provisional
response, the UAS MUST indicate such by removing it from the Send-Info
or Recv-Info header field values in subsequent provisional and the 2xx
final response, and if no Info Packages are remaining then by
including the appropriate header field(s) with empty value(s).<list>
<t></t>
<t>[EDITOR'S NOTE: The original text said: "The UAS MUST NOT send
any INFO messages with Info Packages until it has received an
acknowledgement, such as PRACK for a provisional response or an
ACK for a final response, that the UAC has received the SIP
response sent by the UAS, indicating the UAC received the
Send-Info header field values from the UAS. This assures the UAC
can perform any necessary logic it needs in order to receive the
Info Package and can associate the INFO message and associated
Info Package with the proper dialog." Is it OK to ditch this text?
In theory, it is "good" to have full handshaking and allow for
prep work on the part of the UAC. In practice can anyone think of
situations where this will make a difference? The state machine is
much simpler without it.]</t>
<t></t>
</list>Unlike the NOTIFY method, the INFO method cannot establish a
dialog.</t>
</section>
</section>
<section title="The INFO Method Request">
<t>In this section, "UAC" is the User Agent Client from the perspective
of the INFO method. That is, it is the User Agent (UA) that sends the
INFO method request. This may be somewhat confusing if the UA that is
sending an INFO method is the User Agent Server (UAS) that received the
initial SIP INVITE. In this case, the UAS from the INVITE perspective is
the UAC from the INFO perspective. Be aware this section is strict on
calling the UAC the UA that is sending the INFO method request.</t>
<section title="INFO Requests">
<t>The INFO method communicates application level information along
the signaling path for the call. The INFO method does not change the
state of sessions initiated by SIP. Any proposal to have INFO change
the state of a SIP call is an architectural error and one MUST NOT
allow it. 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>This draft creates a new, mandatory header field for INFO requests,
the "Info-Package" header field. The "Info-Package" header field value
in an INFO request contains a single Info Package token. The token in
the "Info-Package" header field value MUST match one of the Info
Package tokens received in the "Recv-Info" header field value in the
received INVITE for the UAS or response for the UAC. In other words,
one can only send what the other end is willing to receive.</t>
<t>One can only use the INFO method within an INVITE-generated dialog
(early or full) and 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 dialog terminates, that signals the termination of the
negotiated Info Packages. A UA that receives an INFO message after the
other UA sends a BYE or CANCEL MUST respond with a 481 Call Does Not
Exist.</t>
<t>The dialog 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 do not fork. Either UA may send
INFO requests, once each UA has exchanged the Send-Info/Recv-Info
header field value indications of what the far-end supports.</t>
<t>The signaling path for the INFO method is the signaling path
established as a result of the call 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="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 dialog. This protocol action supports legacy use of
INFO as a keep-alive mechanism.</t>
<t>If the UAS receives an INFO request with a Package-Info the UAC
advertised with a Send-Info in the last dialog state update and the
UAS advertised with a Recv-Info and the body of the INFO request is an
appropriate MIME type for the Info Package, the UAS MUST send a 200 OK
repsonse.</t>
<t>If the INFO request contains a body that 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 that the server
does not understand, then the server MUST respond with a 489 Bad
Event. The server then MUST terminate the INVITE dialog, as this
represents a protocol failure.<list>
<t></t>
<t>[EDITOR'S NOTE: I chose 489 as 405 implies a media mis-match
and 501 implies INFO is not supported. This protocol failure is
identical to a NOTIFY with an event package the UAS did not
subscribe to. We could create a new response code if you have
problems with "Bad Event" implying there is some link between INFO
and NOTIFY. However, I would offer what we are doing is refining
489 to mean, "received some package in some context that I do not
understand," where today the possible contexts are INFO and
NOTIFY. Work for you?]</t>
<t></t>
</list></t>
<t>If a server receives an INFO request with a body it understands,
but it has no Info-Package header, the UAS MAY render the body. Note
the semantics of "rendering" is up to the Info Package definition. The
UAS MUST respond to the INFO request with a 200 OK. This enables
legacy use of INFO.</t>
<t>The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message
if the INFO request does not match any existing dialog.</t>
<t>The UAS MAY send other responses, such as Request Failure (4xx),
Server Failure (5xx) and Global Failure (6xx) as appropriate for the
INFO Request.<list>
<t></t>
<t>[EDITOR'S NOTE: Need to check 2976 to make sure we cover all
the bases here, as we are obsoleting that document and this
becomes the sole, normative reference.]</t>
</list></t>
</section>
<section title="Behavior of SIP User Agents">
<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>A UAC MAY CANCEL an INFO request. A UAS receiving a CANCEL for an
INFO request SHOULD respond to the INFO with a "487 Request Cancelled"
response unless the UAC has already sent a final response. The UAS
then MUST ignore future INFO requests.</t>
<t>The INFO message MUST NOT change the state of the SIP dialog. The
only exception to this rule is for specific failure responses as
documented in <xref target="RFC5057">RFC 5057</xref>, which may cause
the INVITE dialog to terminate.</t>
</section>
<section title="Behavior of Registrars">
<t><list>
<t>[EDITOR'S NOTE: TBD]</t>
</list></t>
</section>
<section title="OPTIONS Processing">
<t><list>
<t>[EDITOR'S NOTE: TBD]</t>
</list></t>
</section>
<section title="INFO Message Bodies">
<t>The INFO request MAY contain a message body. If the request
contains a message body, the Info Package type extension document MUST
specify the syntax and semantics of the INFO body.</t>
<t>The purpose of the INFO message 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.</t>
<t>In addition, the INFO method does not define mechanisms for
ensuring in-order delivery. 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. 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>
</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. By definition, such uses have 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 title="Info Packages">
<t>This section covers several issues which one should take into
consideration when propsing new Info Packages.</t>
<section anchor="S.info-packages" 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
dialog, 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 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
dialog 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 dialog. 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 design goal of the <xref
target="RFC3265">SUBSCRIBE/NOTIFY</xref> event framework is to meet
the general need of periodic state notifications/updates. Subscribes
have their own dialog or usage, and thus can outlive an INVITE one,
but they can also follow the path of the INVITE-based dialog.</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><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>
</section>
</section>
<section title="Info Package Responsibilities">
<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)
seeing the application level information transfer. 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. 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 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>Info Packages also MUST define a default MIME type if the
"Accept" header fails to define any MIME types in the INVITE
request.</t>
</section>
<section title="UA 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>This section MAY describe the behavior used to process the
subsequent response.</t>
</section>
<section title="UA 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>
</section>
<section title="Rate of notifications">
<t>Each Info Package MUST define a requirement of SHOULD or MUST
strength which defines an absolute maximum on the rate at which an
Info Package can generate INFO messages by a UA in a dialog.</t>
<t>Each package MAY further define a throttle mechanism that allows
UAs to further limit the rate of INFO messages.</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>
<section title="Syntax">
<t>This section describes the syntax extensions required for
user-to-user data exchange in SIP. 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>
<t>The Augmented BNF definitions for the various new and modified syntax
elements follow. The notation is as used in <xref
target="RFC3261">SIP</xref>. See SIP for any elements not defined in
this section.</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[INFOm = %x49.4E.46.4F ; INFO in caps
extension-method = INFOm / token
Info-Package = "Info-Package" HCOLON Info-package-type
Send-Info = "Send-Info" HCOLON Info-package-type
*( COMMA Info-package-type )
Recv-Info = "Send-Info" HCOLON Info-package-type
*( COMMA Info-package-type )
Info-package-type = Info-package-name *( "." Info-package-param)
Info-package-name = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" ) ;rfc3265
Info-package-param = generic-param ;this doesn't work due to dot!]]></artwork>
<postamble>(postamble)</postamble>
</figure>
</section>
<section anchor="S.IANA" title="IANA Considerations">
<t><list>
<t>[EDITOR'S NOTE: We will fix this section in the next revision of
the document.]</t>
</list></t>
<section title="New 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>
<preamble>Table 1: Summary of Header Fields</preamble>
<artwork><![CDATA[ Header Where INFO
------ ----- ----
Accept R o
Accept-Encoding R o
Accept-Language R o
Allow 200 -
Allow 405 o
Authorization R o
Call-ID gc m
Contact R o
Contact 1xx -
Contact 2xx -
Contact 3xx -
Contact 485 -
Content-Encoding e o
Content-Length e o
Content-Type e *
CSeq gc m
Date g o
Encryption g o
Expires g o
From gc m
Hide R o
Max-Forwards R o
Organization g o
Priority R o
Proxy-Authenticate 407 o
Proxy-Authorization R o
Proxy-Require R o
Require R o
Retry-After R -
Retry-After 404,480,486 o
Retry-After 503 o
Retry-After 600,603 o
Response-Key R o
Record-Route R o
Record-Route 2xx o
Route R o
Server r o
Subject R o
Timestamp g o
To gc(1) m
Unsupported 420 o
User-Agent g o
Via gc(2) m
Warning r o
WWW-Authenticate 401 o
]]></artwork>
<postamble>(postamble)</postamble>
</figure>
</section>
<section title="INFO Method">
<t>This document adds "INFO" to the definition of the element "Method"
in the SIP message grammar.</t>
<t>Like all SIP method names, the INFO method name is case sensitive.
The INFO method transmits application level information within an
INVITE-based dialog.</t>
</section>
<section title="New Headers">
<t>This table expands on tables 2 and 3 in <xref
target="RFC3261"></xref>.</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT
--------------------------------------------------------------------
Info-Package R - - - - - - - m - - - -
Info-Package r - - - - - - - o - - - -
Send-Info R - - - o o o - - - - - -
Send-Info 2xx - - - o o - - - - - - -
Send-Info 1xx - - - o o - - - - - - -
Send-Info r - - - - o - - - - - - -
Recv-Info R - - - o o o - - - - - -
Recv-Info 2xx - - - o o - - - - - - -
Recv-Info 1xx - - - o o - - - - - - -
Recv-Info r - - - - o - - - - - - -
]]></artwork>
<postamble>(postamble)</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
Send-Info or 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 byte-by-byte
with that of the same in the "Send-Info" or "Recv-Info" header
values. The 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. That is, they are "Specification
Required."</t>
<t>There MUST be exactly one Info Package type listed per
Info-Package header. Multiple Info-Packages per INFO message are
disallowed.</t>
<t>[EDITOR NOTE: Really? Why not multiple Info-Packages, in a
multipart/mime? Well, I thought of one: it is hard to disambiguate.
For example, take an INFO message with an Info-Package: key_image,
caller_picture. I then have a multipart/mime with, you guessed it,
an image/jpeg and an image/jpeg. I would offer we do allow this and
require the MIME parse order of the body match the order of the
Info-Package enumerations; if you have too many packages or body
parts or they do not align, you barf. However, I timed out on this
and thus we will have to wait for the next version for me to flesh
this out. If we do do this, then we'll reference RFC 3261 as updated
by draft-ietf-sip-body-handling to require multipart MIME
handling.]</t>
</section>
<section title="Send-Info header">
<t>This document adds Send-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 Send-Info
header usage.</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="Example">
<t>In the following example, Alice initiates a call to Bob. Alice can
support sending or receiving "foo" Info Packages, and sending "bar" Info
Packages.</t>
<t>Alice generates the following: (note: much has been left out for
simplicity)</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Contact: <sip:alice@192.0.2.1>
Send-Info: foo, bar
Recv-Info: foo
]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>Bob checks the header field values. He can support sending but not
receiving "foo", and sending but not receiving "bar". Since Bob does not
support receiving anything Alice can send, the response lists an empty
Recv-Info header.</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Send-Info: foo
Recv-Info:
]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>Since he sent the Send-Info header field value in the 180, and still
wishes to support it, Bob also sends it in the 200 response.</t>
<figure>
<preamble>(preamble)</preamble>
<artwork><![CDATA[SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix
CSeq: 1 INVITE
Contact: <sip:bob@192.0.2.2>
Send-Info: foo
Recv-Info:
]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>Alice can send an Info Package as soon as she received the 180, but
in this example she would not have been able to do so since Bob didn't
say he could receive any Info Packages in his 180 response. Bob must
wait to receive the ACK before sending any "foo" packages (ACK not
shown), at which point he sends the following:</t>
<figure>
<preamble>(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
]]></artwork>
<postamble>(postamble)</postamble>
</figure>
</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 the INFO use clarification to improve the
security of the Internet.</t>
<t>There are no specific security issues for this mechanism, beyond
those already applicable to 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.</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="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>
</references>
<references title="Informative References">
<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="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="RFC3311">
<front>
<title>The Session Initiation Protocol (SIP) UPDATE Method</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3311" />
<format octets="28125" target="ftp://ftp.isi.edu/in-notes/rfc3311.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="RFC3264">
<front>
<title>An Offer/Answer Model with Session Description Protocol
(SDP)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2002" />
<abstract>
<t>This document defines a mechanism by which two entities can
make use of the Session Description Protocol (SDP) to arrive at a
common view of a multimedia session between them. In the model,
one participant offers the other a description of the desired
session from their perspective, and the other participant answers
with the desired session from their perspective. This offer/answer
model is most useful in unicast sessions where information from
both participants is needed for the complete view of the session.
The offer/answer model is used by protocols like the Session
Initiation Protocol (SIP). [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3264" />
<format octets="60854" target="ftp://ftp.isi.edu/in-notes/rfc3264.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="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>
</references>
<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. 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>
<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.</t>
<t>The work group version of this document benefited from the close
readings and comments from John Elwell, Paul Kyzivat, Dean Willis,
Francois Audet, Dale Worley, and Andrew Allen. However, any errors are
still our own.</t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 03:01:48 |