SIP S. Olson
Internet-Draft Microsoft
Expires: February 5, 2003 August 7, 2002
A Mechanism for Content Indirection in SIP Messages
draft-olson-sip-content-indirect-mech-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 5, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This Internet-Draft proposes an extension to the URL MIME External-
Body Access-Type as defined in RFC2017 [7] to satisfy the content
indirection requirements defined in draft-ietf-sipping-content-
indirect-01 [1]. These extensions are aimed at allowing any MIME
part in a SIP message to be referred to indirectly via a URL [4].
Olson Expires February 5, 2003 [Page 1]
Internet-Draft Content Indirection in SIP Messages August 2002
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
Olson Expires February 5, 2003 [Page 2]
Internet-Draft Content Indirection in SIP Messages August 2002
2. Introduction
Previous attempts at solving the content indirection problem made use
of the text/uri-list [8] MIME type. While attractive for its
simplicity (a list of URIs delimted by end-of-line markers), it fails
to satisfy a number of the requirements for a more general purpose
content indirection mechanism. Most notably lacking is the ability
to specify various attributes on a per-URL basis. These attributes
might include version information, the MIME type of the referenced
content, etc.
In searching for a replacement for the text/uri-list MIME type,
RFC2017 defines a strong candidate. RFC2017 defines an extension to
the message/external-body MIME type originally defined in RFC2046
[6]. The extension that RFC2017 makes is to allow a generic URI to
specify the location of the content rather than protocol specific
parameters for FTP, etc. as originally defined in RFC2046. While
providing most of the functionality needed for a SIP content
indirection mechanism, RFC2017 by itself is not a complete solution.
This document will specify the usage of RFC2017 necessary to fulfill
the requirments outlined for content indirection.
The requirements of [1] can be classified as applying either to the
URL which indirectly references the desired content or to the content
itself. Where possible, existing MIME parameters and entity headers
will be used to satisfy those requirements. MIME (Content-Type)
parameters will be the preferred manner of describing the URL while
entity headers will be the preferred manner of describing the
(indirect) content. See RFC 2045 [5] for a description of most of
these entity headers and MIME parameters.
Olson Expires February 5, 2003 [Page 3]
Internet-Draft Content Indirection in SIP Messages August 2002
3. Application of RFC2017 to the Content Indirection Problem
The following text describes the application of RFC2017 to the
requirements for content indirection.
3.1 Specifying the location of the content via a URL
The URL for the indirect content is specified in a "URL" parameter of
the message/external-body MIME type. An access-type parameter
indicates that the external content is referenced by a URL.
For example:
Content-Type: message/external-body;
access-type="URL";
URL="http://www.volcano.com/the-indirect-content"
3.2 Specifying versioning information for the URL
In order to determine whether or not the content indirectly
referenced by the URL has changed, a Content-ID entity header is
used. The syntax of this header follows that of the Call-ID in SIP.
Changes in the underlying content referred to by a URL MUST result in
a change in the Content-ID associated with that URL. Multiple SIP
messages carrying URLs that refer to the same content SHOULD reuse
the same Content-ID to allow the receiver to cache this content and
avoid unnecessary lookups. The Content-ID is intended to be globally
unique and SHOULD be temporally unique across SIP dialogs.
For example:
Content-ID: 4232423424@www.volcano.com
3.3 Specifying the lifetime of the URL
The URL supplied by in Content-Type header is not required to be
accessible or valid for an indefinite period of time. Rather, the
supplier of the URL MUST specify the time period for which this URL
is valid and accessible. This is done through an "EXPIRATION"
parameter of the Content-Type. The format of this expiration
parameter is a RFC1123 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.
Olson Expires February 5, 2003 [Page 4]
Internet-Draft Content Indirection in SIP Messages August 2002
For example:
Content-Type: message/external-body;
expiration="Mon, 24 June 2002 09:00:00 GMT"
3.4 Specifying support for content indirection
A UAC/UAS may indicate support for content indirection through an
Accept header containing the message/external-body MIME type. In the
absence of any other Accept headers, this indicates support for
content indirection of the application/sdp MIME type. If other
Accept values are present, this indicates support for content
indirection of those MIME types as well. User-Agents supporting
content indirection MUST support content indirection of the
application/sdp MIME type.
For example:
Accept: message/external-body, image/*, application/sdp
3.5 Mandatory support for HTTP URLs
Applications which use this content indirection mechanism MUST
support at least 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 intention is to establish a baseline of support to further
strengthen interoperability. Implementors may design for the most
common case (HTTP) without having to worry about negotiation of
support for this particular URI scheme.
3.6 Rejecting content indirection
If a UAS receives a SIP request which 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 [3]. 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.
Olson Expires February 5, 2003 [Page 5]
Internet-Draft Content Indirection in SIP Messages August 2002
3.7 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 URL 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 using the underlying protocol for the URL
scheme.
For example:
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.volcano.com/the-indirect-content"
<CRLF>
Content-Type: application/sdp
<CRLF>
3.8 Specifying the purpose of the indirect content
A Content-Disposition entity header SHOULD be present for all
indirect content. In the absence of an an explicit Content-
Disposition header, a content disposition of "session" should be
assumed.
For example:
Content-Type: message/external-body; access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.volcano.com/the-indirect-content"
Content-Disposition: render
<CRLF>
Content-Type: image/jpeg
<CRLF>
3.9 Specifying multiple URLs for content indirection
If there is a need to send multiple URLs for the purpose of content
indirection, an appropriate multipart MIME type [6] should be used.
Each URL should 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.
Olson Expires February 5, 2003 [Page 6]
Internet-Draft Content Indirection in SIP Messages August 2002
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.volcano.com/announcements/07242002"
Content-Disposition: render
Content-Type: text/html
--boundary42--
3.10 Supplying additional comments about the indirect content
Optional, freeform text may be supplied to comment on the indirect
content. This should be supplied in a Content-Description entity
header.
For example:
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.volcano.com/the-indirect-content"
Content-Description: Multicast gaming session
3.11 Relationship to Call-Info, Error-Info, and Alert-Info Headers
SIP [3] defines three headers which are used to supply additional
information with regard to a session, a particular error response, or
alerting. All three of these headers allow the UAC or UAS to
indicate additional information through a URL. They may be
considered a form of content indirection. The content indirection
mechanism defined in this document is not intended as a replacement
Olson Expires February 5, 2003 [Page 7]
Internet-Draft Content Indirection in SIP Messages August 2002
for these headers. Rather, the headers defined in SIP MUST be used
in preference to this mechanism where applicable because of the well
defined semantics of those headers.
Olson Expires February 5, 2003 [Page 8]
Internet-Draft Content Indirection in SIP Messages August 2002
4. Examples
4.1 Single Content Indirection
INVITE sip:boromir@volcano.com SIP/2.0
From: <sip:gandalf@nwt.com>;tag=347242
To: <sip:boromir@volcano.com>
Call-ID: 3573853342923422@nwt.com
CSeq: 2131 INVITE
Accept: message/external-body
Content-Type: message/external-body;
ACCESS-TYPE=URL;
URL="http://www.nwt.com/party/06/2002/announcement";
EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"
Content-Disposition: session
Content-ID: <4e5562cd1214427d@nwt.com>
Content-Length: 32
Content-Type: application/sdp
4.2 Multipart MIME with Content Indirection
Olson Expires February 5, 2003 [Page 9]
Internet-Draft Content Indirection in SIP Messages August 2002
MESSAGE sip:boromir@volcano.com SIP/2.0
From: <sip:gandalf@nwt.com>;tag=34589882
To: <sip:boromir@volcano.com>
Call-ID: 9242892442211117@nwt.com
CSeq: 388 MESSAGE
Accept: message/external-body, text/html, text/plain, image/*, text/x-emoticon
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=zz993453
--zz993453
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.nwt.com/company_picnic/image1.png"
Content-ID: <9535035333@nwt.com>
Content-Disposition: render
Content-Description: "Kevin getting dunked in the wading pool"
Content-Type: image/png
--zz993453
Content-Type: message/external-body;
access-type="URL";
expiration="Mon, 24 June 2002 09:00:00 GMT";
URL="http://www.nwt.com/company_picnic/image2.png"
Content-ID: <1134299224244@nwt.com>
Content-Disposition: render
Content-Description: "Peter on his tricycle"
Content-Type: image/png
--zz993453--
Olson Expires February 5, 2003 [Page 10]
Internet-Draft Content Indirection in SIP Messages August 2002
5. Security Considerations
For confidentiality, integrity, and authentication, this content
indirection mechanism relies on the security mechanisms outlined in
RFC3261. In particular, the usage of S/MIME as defined in section 23
of RFC3261 provides the necessary mechanism to ensure integrity
protection of the indirect content URL and associated parameters.
Securing the transfer of the indirect content is the responsibility
of the underlying protocol used for this transfer. It is RECOMMENDED
that applications implementing this content indirection method
support the HTTPS URI scheme for secure transfer of content.
Olson Expires February 5, 2003 [Page 11]
Internet-Draft Content Indirection in SIP Messages August 2002
References
[1] Olson, S., "Requirements for Content Indirection in SIP
Messages", Internet Draft draft-ietf-sipping-content-indirect-
01, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] Rosenberg, J., Schulzrinne, Camarillo, Johnston, Peterson,
Sparks, Handley and Schooler, "SIP: Session Initiation
Protocol", RFC 3261, June 2002.
[4] Berners-Lee, Fielding and Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1996.
[5] Freed and Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies", RFC 2045,
November 1996.
[6] Freed and Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, November 1996.
[7] Freed, "Definition of the URL MIME External-Body Access-Type",
RFC 2017, October 1996.
[8] Daniel, R., "A Trivial Convention for using HTTP in URN
Resolution", RFC 2169, June 1997.
Author's Address
Sean Olson
Microsoft
One Microsoft Way
Redmond, WA 98052
US
Phone: +1-425-707-2846
EMail: seanol@microsoft.com
URI: http://www.microsoft.com/rtc
Olson Expires February 5, 2003 [Page 12]
Internet-Draft Content Indirection in SIP Messages August 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Olson Expires February 5, 2003 [Page 13]