| TOC |
|
By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668.
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 January 14, 2005.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document proposes an extension to the URL MIME External- Body Access-Type to satisfy the content indirection requirements for SIP. These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI.
1.
Terminology
2.
Introduction
3.
Example Use Cases
3.1
Presence Notification
3.2
Document Sharing
4.
Requirements
5.
Application of RFC2017 to the Content Indirection Problem
5.1
Specifying support for content indirection
5.2
Mandatory support for HTTP URI
5.3
Rejecting content indirection
5.4
Specifying the location of the content via a URI
5.5
Specifying versioning information for the URI
5.6
Specifying the lifetime of the URI
5.7
Specifying the type of the indirect content
5.8
Specifying the size of the indirect content
5.9
Specifying the purpose of the indirect content
5.10
Specifying multiple URIs for content indirection
5.11
Specifying a hash value for the indirect content
5.12
Supplying additional comments about the indirect content
5.13
Relationship to Call-Info, Error-Info, and Alert-Info Headers
6.
Examples
6.1
Single Content Indirection
6.2
Multipart MIME with Content Indirection
7.
Security Considerations
8.
IANA Considerations
9.
Contributions
§.
Normative References
§.
References References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
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 [5]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997.
| TOC |
The purpose of the Session Initiation Protocol [9]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, SIP: Session Initiation Protocol, June 2002. (SIP) is to create, modify, or terminate sessions with one or more participants. SIP messages, like HTTP, are sytnactically composed of a start line, one or more headers, and an optional body. Unlike HTTP, SIP is not designed as a general purpose transport of data.
There are numerous reasons why it might be desirable to indirectly specify the content of the SIP message body. 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 the resource limited link.
It is also possible that the content size to be transferred might potentially 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, indirected body parts are equivalent, 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]Daniel, R., A Trivial Convention for using HTTP in URN Resolution, June 1997. 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 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.
In searching for a replacement for the text/uri-list MIME type, RFC2017 defines a strong candidate. RFC2017 [1]Freed, N. and K. Moore, Definition of the URL MIME External-Body Access-Type, October 1996. defines an extension to the message/external-body MIME type originally defined in RFC2046 [3]Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, November 1996.. 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 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]Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996. for a description of most of these entity headers and MIME parameters.
| TOC |
There are several example users of such a content indirection mechanism. These are examples only and are not intended to limit the scope or applicability of the mechanism.
The information carried in a presence document could potentially 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 |
|<--------------------------|
| |
| Example information flow for presence notification |
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 using an HTTP GET.
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 which is meant to be rendered by the remote party. Carrying such a document directly in the MESSAGE request is not appropriate for most documents. Furthermore, the document to be shared may reside on a completely independent server from the originating party.
UAC UAS Web Server
| | |
| MESSAGE w/URI | |
|------------------->| |
| 200 | |
|<-------------------| |
| | |
| | HTTP GET |
| |--------------->|
| | image/jpeg |
| |<---------------|
| | |
| Example information flow for document sharing |
In this example, a user wishes to exchange a JPEG image that she has stored on her web server with another user she has a IM conversation with. The JPEG is intended to be rendered inline in the IM conversation. The recepient of the MESSAGE request launches a HTTP GET request to the web server to retrieve the JPEG image.
| TOC |
| TOC |
The following text describes the application of RFC2017 to the requirements for content indirection.
A UAC/UAS may indicate support for content indirection through an Accept header containing the message/external-body MIME type. The UAC/UAS must 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
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.
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 [9]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, SIP: Session Initiation Protocol, June 2002.. 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.
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.
For example:
Content-Type: message/external-body;
access-type="URL";
URL="http://www.example.com/the-indirect-content"
In order to determine whether or not the content indirectly referenced by the URI has changed, a Content-ID entity header is used. The syntax of this header is defined in RFC2045 [2]Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996.. 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 URI that refer to the same content SHOULD reuse the same Content-ID to allow the receiver to cache this content and 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>
The URI 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 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 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. 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"
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 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
<CRLF>
When known in advance, the size of the indirect content should be supplied via a size parameter on the Content-Type header. This is an extension of RFC2017 but in line with other access types defined for the message/external-body MIME type in RFC2046. The content size is useful for the receiving party to make a determination about whether or not to retrieve the content. As with directly supplied content, a UAS may return a 513 error response in the event the content size is too large. This 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
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.example.com/the-indirect-content"
<CRLF>
Content-Type: image/jpeg
Content-Disposition: render
If there is a need to send multiple URIs for the purpose of content indirection, an appropriate multipart MIME type [3]Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, November 1996. should be used. Each URI 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.
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--
If the specific content being referenced by the indirection is known to the sender, and 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]Eastlake, D. and P. Jones, US Secure Hash Algorithm 1 (SHA1), September 2001. hash of the content. If included, the hash is encoded by extending the MIME syntax [3]Freed, N. and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, November 1996. to include a "hash" parameter for the content type "message/external-body", the value of which is a base-64 enoding 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>
Optional, freeform text may be supplied to comment on the indirect content. This should be supplied in a Content-Description entity header. This text may be displayed to the end user but MUST NOT used by other elements to determine disposition of the body, as such as usage would result in unreviewed extension to the COntent-type and Content-disposition header field functions.
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=52723
<CRLF>
Content-Description: Multicast gaming session
SIP [9]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, SIP: Session Initiation Protocol, June 2002. 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 URI. They may be considered a form of content indirection. The content indirection mechanism defined in this document is not intended as a replacement 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.
| TOC |
INVITE sip:boromir@example.com SIP/2.0
From: <sip:gandalf@nwt.com>;tag=347242
To: <sip:boromir@example.com>
Call-ID: 3573853342923422@nwt.com
CSeq: 2131 INVITE
Accept: message/external-body application/sdp
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"
size=231
Content-Length: ...
Content-Type: application/sdp
Content-Disposition: session
Content-ID: <4e5562cd1214427d@nwt.com>
MESSAGE sip:boromir@example.com SIP/2.0
From: <sip:gandalf@nwt.com>;tag=34589882
To: <sip:boromir@example.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"
size=234422
Content-Type: image/png
Content-ID: <9535035333@nwt.com>
Content-Disposition: render
Content-Description: Kevin getting dunked in the wading pool
--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"
size=233811
Content-Type: image/png
Content-ID: <1134299224244@nwt.com>
Content-Disposition: render
Content-Description: Peter on his tricycle
--zz993453--
| TOC |
Any content indirection mechanism introduces additional security concerns. By its nature, content indirection requires an extra processing step and information transfer. There are a number of potential abuses of a content indirection mechanism:
Fortunately, all of these potential threats can be mitigated through careful screening of both the indirect content URIs that are received as well as those that are sent. Integrity and privacy protection of the indirect content URI can prevent additional attacks as well.
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 and privacy of the indirect content URI and associated parameters.
Securing the transfer of the indirect content is the responsibility of the underlying protocol used for this transfer. If HTTP is used, applications implementing this content indirection method MUST support the HTTPS URI scheme for secure transfer of content and must support the upgrading of connections to TLS using starttls. Note that a failure to complete HTTPS or starttls (for example, due to cert or encryption mismatch) after having accepted the indirect content in the SIP request is not the same as rejecting the SIP request, and may require additional user-user communication for correction.
Access control to the content referenced by the URI is not defined by this specification. Access control mechanisms may be defined by the protocol for the scheme of the indirect content URI.
If the UAC knows the content in advance, the UAC SHOULD include a hash parameter in the content indirection. The hash parameter is a base64-encoded SHA-1 hash of the indirected content. [8]Eastlake, D. and P. Jones, US Secure Hash Algorithm 1 (SHA1), September 2001. If a hash value is included, the recipient MUST check the indirect content against that hash and indicate any mismatch to the user.
In addition, if the hash parameter is included, and the target URI involves setting up a security context using certificates, the UAS MUST ignore the results of the certificate validation procedure, and instead verify that the hash of the (canonicalized) content received matches the hash presented in the content-indirection hash parameter.
If the hash parameter is NOT included, the sender SHOULD use only schemes which offer message integrity (such as https:). When the hash parameter is not included and security using certificates is used, the UAS MUST verify any server certificates using the UAS's list of trusted top-level certificate authorities.
If hashing of indirected content is not used, the possibility exists that the content returned to the recipient by exercise of the indirection has been altered from that intended by the sender.
| TOC |
This document raises no new IANA considerations.
| TOC |
It should be noted that the vast majority of this document, including editorship through the first IESG review, was provided by Sean Olson, seanol@microsoft.com
| TOC |
| TOC |
| TOC |
| [10] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", draft-fielding-uri-rfc2396bis-05 (work in progress), April 2004. |
| TOC |
| Dean Willis (editor) | |
| dynamicsoft Inc. | |
| EMail: | dean.willis@softarmor.com |
| URI: | http://www.softarmor.com |
| TOC |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.