Request for Comments: 4483 Cantata Technolgy, Inc.
Category: Standards Track May 2006
A Mechanism for Content Indirection
in Session Initiation Protocol (SIP) Messages
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines an extension to the URL MIME External-Body
Access-Type to satisfy the content indirection requirements for the
Session Initiation Protocol (SIP). These extensions are aimed at
allowing any MIME part in a SIP message to be referred to indirectly
via a URI.
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Use Case Examples ...............................................3
3.1. Presence Notification ......................................4
3.2. Document Sharing ...........................................4
4. Requirements ....................................................5
5. Application of RFC 2017 to the Content Indirection Problem ......6
5.1. Specifying Support for Content Indirection .................6
5.2. Mandatory support for HTTP URI .............................7
5.3. Rejecting Content Indirection ..............................7
5.4. Specifying the Location of the Content via a URI ...........7
5.5. Marking Indirect Content Optional ..........................7
5.6. Specifying Versioning Information for the URI ..............8
5.7. Specifying the URI Lifetime ................................8
5.8. Specifying the type of the Indirect Content ................8
5.9. Specifying the Size of the Indirect Content ................9
5.10. Specifying the Purpose of the Indirect Content ............9
5.11. Specifying Multiple URIs for Content Indirection .........10
5.12. Specifying a Hash Value for the Indirect Content .........10
5.13. Supplying Additional Comments about the Indirect
Content ..................................................11
5.14. Relationship to Call-Info, Error-Info, and
Alert-Info Headers .......................................11
6. Examples .......................................................12
6.1. Single Content Indirection ................................12
6.2. Multipart MIME with Content Indirection ...................12
7. Security Considerations ........................................13
8. Contributions ..................................................15
9. Acknowledgements ...............................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative Reference ....................................16
1. Introduction
The purpose of the Session Initiation Protocol [9] (SIP) is to
create, modify, or terminate sessions with one or more participants.
SIP messages, like HTTP, are syntactically composed of a start line,
one or more headers, and an optional body. Unlike HTTP, SIP is not
designed as a general-purpose data transport protocol.
There are numerous reasons why it might be desirable to specify the
content of the SIP message body indirectly. For bandwidth-limited
applications such as cellular wireless, indirection provides a means
to annotate the (indirect) content with meta-data, which may be used
by the recipient to determine whether or not to retrieve the content
over a resource-limited link.
It is also possible that the content size to be transferred might
overwhelm intermediate signaling proxies, thereby unnecessarily
increasing network latency. For time-sensitive SIP applications,
this may be unacceptable. Indirect content can remedy this by moving
the transfer of this content out of the SIP signaling network and
into a potentially separate data transfer channel.
There may also be scenarios where the session-related data (body)
that needs to be conveyed does not directly reside on the endpoint or
User Agent. In such scenarios, it is desirable to have a mechanism
whereby the SIP message can contain an indirect reference to the
desired content. The receiving party would then use this indirect
reference to retrieve the content via a non-SIP transfer channel such
as HTTP, FTP, or LDAP.
The purpose of content indirection is purely to provide an
alternative transport mechanism for SIP MIME body parts. With the
exception of the transport mechanism, indirect body parts are
equivalent to, and should have the same treatment as, in-line body
parts.
Previous attempts at solving the content indirection problem made use
of the text/uri-list [6] MIME type. While attractive for its
simplicity (a list of URIs delimited by end-of-line markers), it
failed to satisfy a number of the requirements for a more general-
purpose content indirection mechanism in SIP. Most notably lacking
is the ability to specify various attributes on a per-URI basis.
These attributes might include version information, the MIME type of
the referenced content, etc.
RFC 2017 defines a strong candidate for a replacement for the
text/uri-list MIME type. RFC 2017 [1] defines an extension to the
message/external-body MIME type originally defined in RFC2046 [3].
The extension that RFC 2017 makes allows a generic URI to specify the
location of the content rather than protocol-specific parameters for
FTP, etc., as originally defined in RFC2046. Although it provides
most of the functionality needed for a SIP content indirection
mechanism, RFC 2017 by itself is not a complete solution. This
document specifies the usage of RFC 2017 necessary to fulfill the
requirements outlined for content indirection.
The requirements can be classified as applying either to the URI,
which indirectly references the desired content, or to the content
itself. Where possible, existing MIME parameters and entity headers
are used to satisfy those requirements. MIME (Content-Type)
parameters are the preferred manner of describing the URI, while
entity headers are the preferred manner of describing the (indirect)
content. See RFC 2045 [2] for a description of most of these entity
headers and MIME parameters.
2. Terminology
RFC 2119 [5] defines the keywords "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL".
3. Use Case Examples
There are several examples of using the content indirection
mechanism. These are examples only and are not intended to limit the
scope or applicability of the mechanism.
3.1. Presence Notification
The information carried in a presence document could exceed the
recommended size for a SIP (NOTIFY) request, particularly if the
document carries aggregated information from multiple endpoints. In
such a situation, it would be desirable to send the NOTIFY request
with an indirect pointer to the presence document, which could then
be retrieved by, for example, HTTP.
Watcher Presence Server
| |
| SUBSCRIBE |
|-------------------------->|
| 200 OK |
|<--------------------------|
| |
| NOTIFY |
|<--------------------------|
| 200 OK |
|-------------------------->|
| |
| NOTIFY (w/URI) |
|<--------------------------|
| 200 |
|-------------------------->|
| |
| HTTP GET |
|-------------------------->|
| |
| application/cpim-pidf+xml |
|<--------------------------|
| |
In this example, the presence server returns an HTTP URI pointing to
a presence document on the presence server, which the watcher can
then fetch by using an HTTP GET.
3.2. Document Sharing
During an instant messaging conversation, a useful service is
document sharing, wherein one party sends an IM (MESSAGE request)
with an indirect pointer to a document that is meant to be rendered
by the remote party. Carrying such a document directly in the
MESSAGE request is not an appropriate use of the signaling channel.
Furthermore, the document to be shared may reside on a completely
independent server from that of the originating party.
UAC UAS Web Server
(User Agent (User Agent |
Client) Server) |
| | |
| MESSAGE w/URI | |
|------------------->| |
| 200 | |
|<-------------------| |
| | |
| | HTTP GET |
| |--------------->|
| | image/jpeg |
| |<---------------|
| | |
In this example, a user UAC wishes to exchange a JPEG image that she
has stored on her web server with user UAS with whom she has an IM
conversation. She intends to render the JPEG inline in the IM
conversation. The recipient of the MESSAGE request launches an HTTP
GET request to the web server to retrieve the JPEG image.
4. Requirements
o It MUST be possible to specify the location of content via a URI.
Such URIs MUST conform with RFC2396 [7].
o It MUST be possible to specify the length of the indirect content.
o It MUST be possible to specify the type of the indirect content.
o It MUST be possible to specify the disposition of each URI
independently.
o It MUST be possible to label each URI to identify if and when the
content referred to by that URI has changed. Applications of this
mechanism may send the same URI more than once. The intention of
this requirement is to allow the receiving party to determine
whether the content referenced by the URI has changed, without
having to retrieve that content. Examples of ways the URI could
be labeled include a sequence number, timestamp, and version
number. When used with HTTP, the entity-tag (ETAG) mechanism, as
defined in RFC2068 [4], may be appropriate. Note that we are
labeling not the URI itself but the content to which the URI
refers, and that the label is therefore effectively "metadata" of
the content itself.
o It MUST be possible to specify the time span for which a given URI
is valid. This may or may not be the same as the lifetime for the
content itself.
o It MUST be possible for the UAC and the UAS to indicate support of
this content indirection mechanism. A fallback mechanism SHOULD
be specified in the event that one of the parties is unable to
support content indirection.
o It MUST be possible for the UAC and UAS to negotiate the type of
the indirect content when using the content indirection mechanism.
o It MUST be possible for the UAC and UAS to negotiate support for
any URI scheme to be used in the content indirection mechanism.
This is in addition to the ability to negotiate the content type.
o It SHOULD be possible to ensure the integrity and confidentiality
of the URI when it is received by the remote party.
o It MUST be possible to process the content indirection without
human intervention.
o It MUST allow for indirect transference of content in any SIP
message that would otherwise carry that content as a body.
5. Application of RFC 2017 to the Content Indirection Problem
The following text describes the application of RFC 2017 to the
requirements for content indirection.
5.1. Specifying Support for Content Indirection
A UAC/UAS indicates support for content indirection by including the
message/external-body MIME type in the Accept header. The UAC/UAS
MAY supply additional values in the Accept header to indicate the
content types that it is willing to accept, either directly or
through content indirection. User-Agents supporting content
indirection MUST support content indirection of the application/sdp
MIME type.
For example:
Accept: message/external-body, image/*, application/sdp
5.2. Mandatory support for HTTP URI
Applications that use this content indirection mechanism MUST support
the HTTP URI scheme. Additional URI schemes MAY be used, but a
UAC/UAS MUST support receiving a HTTP URI for indirect content if it
advertises support for content indirection.
The UAS MAY advertise alternate access schemes in the schemes
parameter of the Contact header in the UAS response to the UAC’s
session establishment request (e.g., INVITE, SUBSCRIBE), as described
in RFC 3840 [11].
5.3. Rejecting Content Indirection
If a UAS receives a SIP request that contains a content indirection
payload and the UAS cannot or does not wish to support such a content
type, it MUST reject the request with a 415 Unsupported Media Type
response as defined in section 21.4.13 of SIP [9]. In particular,
the UAC should note the absence of the message/external-body MIME
type in the Accept header of this response to indicate that the UAS
does not support content indirection, or the absence of the
particular MIME type of the requested comment to indicate that the
UAS does not support the particular media type.
5.4. Specifying the Location of the Content via a URI
The URI for the indirect content is specified in a "URI" parameter of
the message/external-body MIME type. An access-type parameter
indicates that the external content is referenced by a URI. HTTP URI
specifications MUST conform to RFC 2396 [7].
For example:
Content-Type: message/external-body; access-type="URL";
URL="http://www.example.com/the-indirect-content"
5.5. Marking Indirect Content Optional
Some content is not critical to the context of the communication if
there is a fetch or conversion failure. The content indirection
mechanism uses the Critical-Content mechanism described in RFC 3459
[10]. In particular, if the UAS is unable to fetch or render an
optional body part, then the server MUST NOT return an error to the
UAC.
5.6. Specifying Versioning Information for the URI
In order to determine whether the content indirectly referenced by
the URI has changed, a Content-ID entity header is used. The syntax
of this header is defined in RFC 2045 [2]. Changes in the underlying
content referred to by a URI MUST result in a change in the Content-
ID associated with that URI. Multiple SIP messages carrying URIs
that refer to the same content SHOULD reuse the same Content-ID, to
allow the receiver to cache this content and to avoid unnecessary
retrievals. The Content-ID is intended to be globally unique and
SHOULD be temporally unique across SIP dialogs.
For example:
Content-ID: <4232423424@www.example.com>
5.7. Specifying the URI Lifetime
The URI supplied by the Content-Type header is not required to be
accessible or valid for an indefinite period of time. Rather, the
supplier of the URI MUST specify the time period for which this URI
is valid and accessible. This is done through an "EXPIRATION"
parameter of the Content-Type. The format of this expiration
parameter is an RFC 1123 [12] date-time value. This is further
restricted in this application to use only GMT time, consistent with
the Date: header in SIP. This is a mandatory parameter. Note that
the date-time value can range from minutes to days or even years.
For example:
Content-Type: message/external-body;
expiration="Mon, 24 June 2002 09:00:00 GMT"
5.8. Specifying the type of the Indirect Content
To support existing SIP mechanisms for the negotiation of content
types, a Content-Type entity header SHOULD be present in the entity
(payload) itself. If the protocol (scheme) of the URI supports its
own content negotiation mechanisms (e.g., HTTP), this header may be
omitted. The sender MUST, however, be prepared for the receiving
party to reject content indirection if the receiver is unable to
negotiate an appropriate MIME type by using the underlying protocol
for the URI scheme.
For example:
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content"
<CRLF>
Content-Type: application/sdp
Content-Disposition: session
<CRLF>
5.9. Specifying the Size of the Indirect Content
When known in advance, the size of the indirect content in bytes
SHOULD be supplied via a size parameter on the Content-Type header.
This is an extension of RFC 2017 but is in line with other access
types defined for the message/external-body MIME type in RFC 2046.
The content size is useful for the receiving party to make a
determination about whether to retrieve the content. As with
directly supplied content, a UAS may return a 513 error response in
the event that the content size is too large. Size is an optional
parameter.
For example:
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content";
size=4123
5.10. Specifying the Purpose of the Indirect Content
A Content-Disposition entity header MUST be present for all indirect
content.
For example:
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content"
<CRLF>
Content-Type: image/jpeg
Content-Disposition: render
5.11. Specifying Multiple URIs for Content Indirection
If there is a need to send multiple URIs for content indirection, an
appropriate multipart MIME type [3] should be used. Each URI MUST be
contained in a single entity. Indirect content may be mixed with
directly-supplied content. This is particularly useful with the
multipart/alternative MIME type.
NOTE: This specification does not change the meanings of the various
multipart flavors, particularly multipart/related, as described in
RFC 2387 [13].
For example:
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
The company announcement for June, 2002 follows:
--boundary42
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/announcements/07242002";
size=4123
Content-Type: text/html
Content-Disposition: render
--boundary42--
5.12. Specifying a Hash Value for the Indirect Content
If the sender knows the specific content being referenced by the
indirection, and if the sender wishes the recipient to be able to
validate that this content has not been altered from that intended by
the sender, the sender includes a SHA-1 [8] hash of the content. If
it is included, the hash is encoded by extending the MIME syntax [3]
to include a "hash" parameter for the content type "message/
external-body", whose value is a hexadecimal encoding of the hash.
For example:
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.example.com/the-indirect-content.au";
size=52723;
hash=10AB568E91245681AC1B
<CRLF>
Content-Disposition: render
5.13. Supplying Additional Comments about the Indirect Content
One MAY use the Content-Description entity header to provide
optional, freeform text to comment on the indirect content. This
text MAY be displayed to the end user but MUST NOT used by other
elements to determine the disposition of the body.
For example:
Content-Type: message/external-body;