< draft-ietf-sip-content-indirect-mech-04.txt		draft-ietf-sip-content-indirect-mech-05.txt >
	Session Initiation Protocol D. Willis, Ed.		Session Initiation Protocol E. Burger, Ed.
	Internet-Draft dynamicsoft Inc.		Internet-Draft Brooktrout Technology, Inc.
	Expires: January 14, 2005 July 16, 2004		Expires: April 25, 2005 October 25, 2004
	A Mechanism for Content Indirection in Session Initiation Protocol		A Mechanism for Content Indirection in Session Initiation Protocol
	(SIP) Messages		(SIP) Messages
	draft-ietf-sip-content-indirect-mech-04		draft-ietf-sip-content-indirect-mech-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any applicable patent or other IPR claims of
			which he or she is aware have been or will be disclosed, and any of
			which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 14, 2005.		This Internet-Draft will expire on April 25, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This document proposes an extension to the URL MIME External- Body		This document defines an extension to the URL MIME External-Body
	Access-Type to satisfy the content indirection requirements for SIP.		Access-Type to satisfy the content indirection requirements for SIP.
	These extensions are aimed at allowing any MIME part in a SIP message		These extensions are aimed at allowing any MIME part in a SIP message
	to be referred to indirectly via a URI.		to be referred to indirectly via a URI.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Example Use Cases . . . . . . . . . . . . . . . . . . . . . 4		3. Example Use Cases . . . . . . . . . . . . . . . . . . . . . 4
	3.1 Presence Notification . . . . . . . . . . . . . . . . . . 4		3.1 Presence Notification . . . . . . . . . . . . . . . . . . 4
	3.2 Document Sharing . . . . . . . . . . . . . . . . . . . . . 5		3.2 Document Sharing . . . . . . . . . . . . . . . . . . . . . 5
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Application of RFC2017 to the Content Indirection Problem . 7		5. Application of RFC2017 to the Content Indirection Problem . 7
	5.1 Specifying support for content indirection . . . . . . . . 7		5.1 Specifying support for content indirection . . . . . . . . 7
	5.2 Mandatory support for HTTP URI . . . . . . . . . . . . . . 7		5.2 Mandatory support for HTTP URI . . . . . . . . . . . . . . 7
	5.3 Rejecting content indirection . . . . . . . . . . . . . . 7		5.3 Rejecting content indirection . . . . . . . . . . . . . . 7
	5.4 Specifying the location of the content via a URI . . . . . 8		5.4 Specifying the location of the content via a URI . . . . . 8
	5.5 Specifying versioning information for the URI . . . . . . 8		5.5 Marking indirect content optional . . . . . . . . . . . . 8
	5.6 Specifying the lifetime of the URI . . . . . . . . . . . . 8		5.6 Specifying versioning information for the URI . . . . . . 8
	5.7 Specifying the type of the indirect content . . . . . . . 9		5.7 Specifying the lifetime of the URI . . . . . . . . . . . . 9
	5.8 Specifying the size of the indirect content . . . . . . . 9		5.8 Specifying the type of the indirect content . . . . . . . 9
	5.9 Specifying the purpose of the indirect content . . . . . . 10		5.9 Specifying the size of the indirect content . . . . . . . 10
	5.10 Specifying multiple URIs for content indirection . . . . 10		5.10 Specifying the purpose of the indirect content . . . . . 10
	5.11 Specifying a hash value for the indirect content . . . . 11		5.11 Specifying multiple URIs for content indirection . . . . 10
	5.12 Supplying additional comments about the indirect		5.12 Specifying a hash value for the indirect content . . . . 11
			5.13 Supplying additional comments about the indirect
	content . . . . . . . . . . . . . . . . . . . . . . . . 12		content . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.13 Relationship to Call-Info, Error-Info, and Alert-Info		5.14 Relationship to Call-Info, Error-Info, and Alert-Info
	Headers . . . . . . . . . . . . . . . . . . . . . . . . 12		Headers . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1 Single Content Indirection . . . . . . . . . . . . . . . . 13		6.1 Single Content Indirection . . . . . . . . . . . . . . . . 13
	6.2 Multipart MIME with Content Indirection . . . . . . . . . 13		6.2 Multipart MIME with Content Indirection . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
	9. Contributions . . . . . . . . . . . . . . . . . . . . . . . 16		9. Contributions . . . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	10.1 Normative References . . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.2 References References . . . . . . . . . . . . . . . . . . 17		11.1 Normative References . . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . 17		11.2 Informative References . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . 18		Author's Address . . . . . . . . . . . . . . . . . . . . . . 18
			Intellectual Property and Copyright Statements . . . . . . . 19
	1. Terminology		1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		RFC 2119 [5] defines the key words "MUST", "MUST NOT", "REQUIRED",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	document are to be interpreted as described in RFC 2119 [5]		and "OPTIONAL".
	2. Introduction		2. Introduction
	The purpose of the Session Initiation Protocol [9] (SIP) is to		The purpose of the Session Initiation Protocol [9] (SIP) is to
	create, modify, or terminate sessions with one or more participants.		create, modify, or terminate sessions with one or more participants.
	SIP messages, like HTTP, are sytnactically composed of a start line,		SIP messages, like HTTP, are syntactically composed of a start line,
	one or more headers, and an optional body. Unlike HTTP, SIP is not		one or more headers, and an optional body. Unlike HTTP, SIP is not
	designed as a general purpose transport of data.		designed as a general-purpose data transport protocol.
	There are numerous reasons why it might be desirable to indirectly		There are numerous reasons why it might be desirable to indirectly
	specify the content of the SIP message body. For bandwidth limited		specify the content of the SIP message body. For bandwidth limited
	applications such as cellular wireless, indirection provides a means		applications such as cellular wireless, indirection provides a means
	to annotate the (indirect) content with meta-data which may be used		to annotate the (indirect) content with meta-data which may be used
	by the recipient to determine whether or not to retrieve the content		by the recipient to determine whether or not to retrieve the content
	over the resource limited link.		over the resource limited link.
	It is also possible that the content size to be transferred might		It is also possible that the content size to be transferred might
	potentially overwhelm intermediate signaling proxies, thereby		potentially overwhelm intermediate signaling proxies, thereby
	skipping to change at page 3, line 43 ¶		skipping to change at page 3, line 43 ¶
	There may also be scenarios where the session related data (body)		There may also be scenarios where the session related data (body)
	that needs to be conveyed does not directly reside on the endpoint or		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		User Agent. In such scenarios, it is desirable to have a mechanism
	whereby the SIP message can contain an indirect reference to the		whereby the SIP message can contain an indirect reference to the
	desired content. The receiving party would then use this indirect		desired content. The receiving party would then use this indirect
	reference to retrieve the content via a non-SIP transfer channel such		reference to retrieve the content via a non-SIP transfer channel such
	as HTTP, FTP, or LDAP.		as HTTP, FTP, or LDAP.
	The purpose of content indirection is purely to provide an		The purpose of content indirection is purely to provide an
	alternative transport mechanism for SIP MIME body parts. With the		alternative transport mechanism for SIP MIME body parts. With the
	exception of the transport mechanism, indirected body parts are		exception of the transport mechanism, indirect body parts are
	equivalent, and should have the same treatment, as in-line body		equivalent, and should have the same treatment, as in-line body
	parts.		parts.
	Previous attempts at solving the content indirection problem made use		Previous attempts at solving the content indirection problem made use
	of the text/uri-list [6] MIME type. While attractive for its		of the text/uri-list [6] MIME type. While attractive for its
	simplicity (a list of URIs delimted by end-of-line markers), it fails		simplicity (a list of URIs delimited by end-of-line markers), it
	to satisfy a number of the requirements for a more general purpose		failed to satisfy a number of the requirements for a more
	content indirection mechanism in SIP. Most notably lacking is the		general-purpose content indirection mechanism in SIP. Most notably
	ability to specify various attributes on a per-URI basis. These		lacking is the ability to specify various attributes on a per-URI
	attributes might include version information, the MIME type of the		basis. These attributes might include version information, the MIME
	referenced content, etc.		type of the referenced content, etc.
	In searching for a replacement for the text/uri-list MIME type,		In searching for a replacement for the text/uri-list MIME type,
	RFC2017 defines a strong candidate. RFC2017 [1] defines an extension		RFC2017 defines a strong candidate. RFC2017 [1] defines an extension
	to the message/external-body MIME type originally defined in		to the message/external-body MIME type originally defined in RFC2046
	RFC2046 [3]. The extension that RFC2017 makes is to allow a generic		[3]. The extension that RFC2017 makes is to allow a generic URI to
	URI to specify the location of the content rather than protocol		specify the location of the content rather than protocol specific
	specific parameters for FTP, etc. as originally defined in RFC2046.		parameters for FTP, etc. as originally defined in RFC2046. While
	While providing most of the functionality needed for a SIP content		providing most of the functionality needed for a SIP content
	indirection mechanism, RFC2017 by itself is not a complete solution.		indirection mechanism, RFC2017 by itself is not a complete solution.
	This document will specify the usage of RFC2017 necessary to fulfill		This document specifies the usage of RFC2017 necessary to fulfill the
	the requirments outlined for content indirection.		requirements outlined for content indirection.
	The requirements can be classified as applying either to the URI		The requirements can be classified as applying either to the URI,
	which indirectly references the desired content or to the content		which indirectly references the desired content, or to the content
	itself. Where possible, existing MIME parameters and entity headers		itself. Where possible, existing MIME parameters and entity headers
	are used to satisfy those requirements. MIME (Content-Type)		are used to satisfy those requirements. MIME (Content-Type)
	parameters are the preferred manner of describing the URI while		parameters are the preferred manner of describing the URI while
	entity headers are the preferred manner of describing the (indirect)		entity headers are the preferred manner of describing the (indirect)
	content. See RFC 2045 [2] for a description of most of these entity		content. See RFC 2045 [2] for a description of most of these entity
	headers and MIME parameters.		headers and MIME parameters.
	3. Example Use Cases		3. Example Use Cases
	There are several example users of such a content indirection		There are several example users of such a content indirection
	mechanism. These are examples only and are not intended to limit the		mechanism. These are examples only and are not intended to limit the
	scope or applicability of the mechanism.		scope or applicability of the mechanism.
	3.1 Presence Notification		3.1 Presence Notification
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 19 ¶
	| 200 | |		| 200 | |
	|<-------------------| |		|<-------------------| |
	| | |		| | |
	| | HTTP GET |		| | HTTP GET |
	| |--------------->|		| |--------------->|
	| | image/jpeg |		| | image/jpeg |
	| |<---------------|		| |<---------------|
	| | |		| | |
	In this example, a user wishes to exchange a JPEG image that she has		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		stored on her web server with another user she has an IM conversation
	with. The JPEG is intended to be rendered inline in the IM		with. She intends to render the JPEG inline in the IM conversation.
	conversation. The recepient of the MESSAGE request launches a HTTP		The recipient of the MESSAGE request launches a HTTP GET request to
	GET request to the web server to retrieve the JPEG image.		the web server to retrieve the JPEG image.
	4. Requirements		4. Requirements
	o It MUST be possible to specify the location of content via a URI.		o It MUST be possible to specify the location of content via a URI.
	Such URIS MUST be conformnt with RFC2396 [7] or its successors,		Such URIs MUST conform with RFC2396 [7] or its successors, such as
	such as [10].		[13].
	o It MUST be possible to specify the length of the indirect content.		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 type of the indirect content.
	o It MUST be possible to specify the disposition of each URI		o It MUST be possible to specify the disposition of each URI
	independently.		independently.
	o It MUST be possible to label each URI to identify if and when the		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		content referred to by that URI has changed. Applications of this
	mechanism may send the same URI more than once. The intention of		mechanism may send the same URI more than once. The intention of
	this requirement is to allow the receiving party to determine if		this requirement is to allow the receiving party to determine if
	the content referenced by the URI has changed without having to		the content referenced by the URI has changed without having to
	actually retrieve that content. Example ways the URI could be		actually retrieve that content. Example ways the URI could be
	labelled include a sequence number, timestamp, version number,		labeled include a sequence number, timestamp, version number, etc.
	etc. When used with HTTP, an entity-tag (ETAG) mechanism as		When used with HTTP, the entity-tag (ETAG) mechanism as defined in
	defined in RFC2068 [4]" may be appropriate. Note that we are not		RFC2068 [4] may be appropriate. Note that we are not labeling the
	labeling the URI itself, but the content to which the URI refers,		URI itself, but the content to which the URI refers, and that the
	and that the label is therefore effectively "metadata" of the		label is therefore effectively "metadata" of the content itself.
	content itself.		o It MUST be possible to specify the time span for which a given URI
	o It MUST be possible to specify the timespan for which a given URI
	is valid. This may or may not be the same as the lifetime for the		is valid. This may or may not be the same as the lifetime for the
	content itself.		content itself.
	o It MUST be possible for the UAC and the UAS to indicate support of		o It MUST be possible for the UAC and the UAS to indicate support of
	this content indirection mechanism. A fallback mechanism SHOULD		this content indirection mechanism. A fallback mechanism SHOULD
	be specified in the event that one of the parties is unable to		be specified in the event that one of the parties is unable to
	support content indirection.		support content indirection.
	o It MUST be possible for the UAC and UAS to negotiate the type of		o It MUST be possible for the UAC and UAS to negotiate the type of
	the indirect content when using the content indirection mechanism.		the indirect content when using the content indirection mechanism.
	o It MUST be possible for the UAC and UAS to negotiate support for		o It MUST be possible for the UAC and UAS to negotiate support for
	URI scheme(s) to be used in the content indirection mechanism.		URI scheme(s) to be used in the content indirection mechanism.
	This is in addition to the ability to negotiate the content type.		This is in addition to the ability to negotiate the content type.
	o It SHOULD be possible to ensure the integrity and privacy of the		o It SHOULD be possible to ensure the integrity and confidentiality
	URI when it is received by the remote party.		of the URI when it is received by the remote party.
	o It MUST be possible to process the content indirection without		o It MUST be possible to process the content indirection without
	human intervention.		human intervention.
	o It MUST allow for indirect transference of content in any SIP		o It MUST allow for indirect transference of content in any SIP
	message which would otherwise carry that content as a body.		message that would otherwise carry that content as a body.
	5. Application of RFC2017 to the Content Indirection Problem		5. Application of RFC2017 to the Content Indirection Problem
	The following text describes the application of RFC2017 to the		The following text describes the application of RFC2017 to the
	requirements for content indirection.		requirements for content indirection.
	5.1 Specifying support for content indirection		5.1 Specifying support for content indirection
	A UAC/UAS may indicate support for content indirection through an		A UAC/UAS indicates support for content indirection by including the
	Accept header containing the message/external-body MIME type. The		message/external-body MIME type in the Accept header. The UAC/UAS
	UAC/UAS must supply additional values in the Accept header to		MAY supply additional values in the Accept header to indicate the
	indicate the content types that it is willing to accept either		content types that it is willing to accept, either directly or
	directly or through content indirection. User-Agents supporting		through content indirection. User-Agents supporting content
	content indirection MUST support content indirection of the		indirection MUST support content indirection of the application/sdp
	application/sdp MIME type.		MIME type.
	For example:		For example:
	Accept: message/external-body, image/*, application/sdp		Accept: message/external-body, image/*, application/sdp
	5.2 Mandatory support for HTTP URI		5.2 Mandatory support for HTTP URI
	Applications which use this content indirection mechanism MUST		Applications which use this content indirection mechanism MUST
	support at least the HTTP URI scheme. Additional URI schemes MAY be		support the HTTP URI scheme. Additional URI schemes MAY be used, but
	used, but a UAC/UAS MUST support receiving a HTTP URI for indirect		a UAC/UAS MUST support receiving a HTTP URI for indirect content if
	content if it advertises support for content indirection.		it advertises support for content indirection.
	The intention is to establish a baseline of support to further		The UAS MAY advertise alternate access schemes in the schemes
	strengthen interoperability. Implementors may design for the most		parameter of the Contact header in the UAS response to the UAC's
	common case (HTTP) without having to worry about negotiation of		session establishment request (e.g., INVITE, SUBSCRIBE, etc.), as
	support for this particular URI scheme.		described in Application Interaction [11].
	5.3 Rejecting content indirection		5.3 Rejecting content indirection
	If a UAS receives a SIP request which contains a 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		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		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		Type response as defined in section 21.4.13 of SIP [9] In
	particular, the UAC should note the absence of the message/		particular, the UAC should note the absence of the
	external-body MIME type in the Accept header of this response to		message/external-body MIME type in the Accept header of this response
	indicate that the UAS does not support content indirection.		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		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 URI for the indirect content is specified in a "URI" parameter of
	the message/external-body MIME type. An access-type parameter		the message/external-body MIME type. An access-type parameter
	indicates that the external content is referenced by a URI.		indicates that the external content is referenced by a URI. HTTP URI
			specifications MUST conform to RFC2396 [7] or its successors [13].
	For example:		For example:
	Content-Type: message/external-body;		Content-Type: message/external-body;
	access-type="URL";		access-type="URL";
	URL="http://www.example.com/the-indirect-content"		URL="http://www.example.com/the-indirect-content"
	5.5 Specifying versioning information for the URI		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 RFC3459
			[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 or not the content indirectly		In order to determine whether or not the content indirectly
	referenced by the URI has changed, a Content-ID entity header is		referenced by the URI has changed, a Content-ID entity header is
	used. The syntax of this header is defined in RFC2045 [2]. Changes		used. The syntax of this header is defined in RFC2045 [2]. Changes
	in the underlying content referred to by a URI MUST result in a		in the underlying content referred to by a URI MUST result in a
	change in the Content-ID associated with that URI. Multiple SIP		change in the Content-ID associated with that URI. Multiple SIP
	messages carrying URI that refer to the same content SHOULD reuse the		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		same Content-ID to allow the receiver to cache this content and avoid
	unnecessary retrievals. The Content-ID is intended to be globally		unnecessary retrievals. The Content-ID is intended to be globally
	unique and SHOULD be temporally unique across SIP dialogs.		unique and SHOULD be temporally unique across SIP dialogs.
	For example:		For example:
	Content-ID: <4232423424@www.example.com>		Content-ID: <4232423424@www.example.com>
	5.6 Specifying the lifetime of the URI		5.7 Specifying the lifetime of the URI
	The URI supplied by in Content-Type header is not required to be		The URI supplied by in Content-Type header is not required to be
	accessible or valid for an indefinite period of time. Rather, the		accessible or valid for an indefinite period of time. Rather, the
	supplier of the URI MUST specify the time period for which this URI		supplier of the URI MUST specify the time period for which this URI
	is valid and accessible. This is done through an "EXPIRATION"		is valid and accessible. This is done through an "EXPIRATION"
	parameter of the Content-Type. The format of this expiration		parameter of the Content-Type. The format of this expiration
	parameter is a RFC1123 date-time value. This is further restricted		parameter is a RFC1123 date-time value. This is further restricted
	in this application to use only GMT time, consistent with the Date:		in this application to use only GMT time, consistent with the Date:
	header in SIP. This is a mandatory parameter. Note that the		header in SIP. This is a mandatory parameter. Note that the
	date-time value can range from minutes to days or even years.		date-time value can range from minutes to days or even years.
	For example:		For example:
	Content-Type: message/external-body;		Content-Type: message/external-body;
	expiration="Mon, 24 June 2002 09:00:00 GMT"		expiration="Mon, 24 June 2002 09:00:00 GMT"
	5.7 Specifying the type of the indirect content		5.8 Specifying the type of the indirect content
	To support existing SIP mechanisms for the negotiation of content		To support existing SIP mechanisms for the negotiation of content
	types, a Content-Type entity header SHOULD be present in the entity		types, a Content-Type entity header SHOULD be present in the entity
	(payload) itself. If the protocol (scheme) of the URI supports its		(payload) itself. If the protocol (scheme) of the URI supports its
	own content negotiation mechanisms (e.g. HTTP), this header may be		own content negotiation mechanisms (e.g. HTTP), this header may be
	omitted. The sender MUST however be prepared for the receiving party		omitted. The sender MUST however be prepared for the receiving party
	to reject content indirection if the receiver is unable to negotiate		to reject content indirection if the receiver is unable to negotiate
	an appropriate MIME type using the underlying protocol for the URI		an appropriate MIME type using the underlying protocol for the URI
	scheme.		scheme.
	For example:		For example:
	Content-Type: message/external-body; access-type="URL";		Content-Type: message/external-body; access-type="URL";
	expiration="Mon, 24 June 2002 09:00:00 GMT";		expiration="Mon, 24 June 2002 09:00:00 GMT";
	URL="http://www.example.com/the-indirect-content"		URL="http://www.example.com/the-indirect-content"
	<CRLF>		<CRLF>
	Content-Type: application/sdp		Content-Type: application/sdp
			Content-Disposition: session
	<CRLF>		<CRLF>
	5.8 Specifying the size of the indirect content		5.9 Specifying the size of the indirect content
	When known in advance, the size of the indirect content should be		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		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		extension of RFC2017 but in line with other access types defined for
	the message/external-body MIME type in RFC2046. The content size is		the message/external-body MIME type in RFC2046. The content size is
	useful for the receiving party to make a determination about whether		useful for the receiving party to make a determination about whether
	or not to retrieve the content. As with directly supplied content, a		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		UAS may return a 513 error response in the event the content size is
	too large. This is an optional parameter.		too large. This is an optional parameter.
	For example:		For example:
	Content-Type: message/external-body; access-type="URL";		Content-Type: message/external-body; access-type="URL";
	expiration="Mon, 24 June 2002 09:00:00 GMT";		expiration="Mon, 24 June 2002 09:00:00 GMT";
	URL="http://www.example.com/the-indirect-content";		URL="http://www.example.com/the-indirect-content";
	size=4123		size=4123
	5.9 Specifying the purpose of the indirect content		5.10 Specifying the purpose of the indirect content
	A Content-Disposition entity header SHOULD be present for all		A Content-Disposition entity header MUST be present for all indirect
	indirect content. In the absence of an an explicit		content.
	Content-Disposition header, a content disposition of "session" should
	be assumed.
	For example:		For example:
	Content-Type: message/external-body; access-type="URL";		Content-Type: message/external-body; access-type="URL";
	expiration="Mon, 24 June 2002 09:00:00 GMT";		expiration="Mon, 24 June 2002 09:00:00 GMT";
	URL="http://www.example.com/the-indirect-content"		URL="http://www.example.com/the-indirect-content"
	<CRLF>		<CRLF>
	Content-Type: image/jpeg		Content-Type: image/jpeg
	Content-Disposition: render		Content-Disposition: render
	5.10 Specifying multiple URIs for content indirection		5.11 Specifying multiple URIs for content indirection
	If there is a need to send multiple URIs for the purpose of content		If there is a need to send multiple URIs for the purpose of content
	indirection, an appropriate multipart MIME type [3] should be used.		indirection, an appropriate multipart MIME type [3] should be used.
	Each URI should be contained in a single entity. Indirect content		Each URI MUST be contained in a single entity. Indirect content may
	may be mixed with directly supplied content. This is particularly		be mixed with directly supplied content. This is particularly useful
	useful with the multipart/alternative MIME type.		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 RFC2387 [12].
	For example:		For example:
	MIME-Version: 1.0		MIME-Version: 1.0
	Content-Type: multipart/mixed; boundary=boundary42		Content-Type: multipart/mixed; boundary=boundary42
	--boundary42		--boundary42
	Content-Type: text/plain; charset=us-ascii		Content-Type: text/plain; charset=us-ascii
	The company announcement for June, 2002 follows:		The company announcement for June, 2002 follows:
	--boundary42		--boundary42
	Content-Type: message/external-body;		Content-Type: message/external-body;
	access-type="URL";		access-type="URL";
	expiration="Mon, 24 June 2002 09:00:00 GMT";		expiration="Mon, 24 June 2002 09:00:00 GMT";
	URL="http://www.example.com/announcements/07242002";		URL="http://www.example.com/announcements/07242002";
	size=4123		size=4123
	Content-Type: text/html		Content-Type: text/html
	Content-Disposition: render		Content-Disposition: render
	--boundary42--		--boundary42--
	5.11 Specifying a hash value for the indirect content		5.12 Specifying a hash value for the indirect content
	If the specific content being referenced by the indirection is known		If the sender knows the specific content being referenced by the
	to the sender, and the sender wishes the recipient to be able to		indirection, and the sender wishes the recipient to be able to
	validate that this content has not been altered from that intended by		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		the sender, the sender includes a SHA-1 [8] hash of the content. If
	included, the hash is encoded by extending the MIME syntax [3] to		included, the hash is encoded by extending the MIME syntax [3] to
	include a "hash" parameter for the content type "message/		include a "hash" parameter for the content type
	external-body", the value of which is a base-64 enoding of the hash.		"message/external-body", the value of which is a hexadecimal encoding
			of the hash.
	For example:		For example:
	Content-Type: message/external-body;		Content-Type: message/external-body;
	access-type="URL";		access-type="URL";
	expiration="Mon, 24 June 2002 09:00:00 GMT";		expiration="Mon, 24 June 2002 09:00:00 GMT";
	URL="http://www.example.com/the-indirect-content.au";		URL="http://www.example.com/the-indirect-content.au";
	size=52723		size=52723;
	hash=10AB568E91245681AC1B		hash=10AB568E91245681AC1B
	<CRLF>		<CRLF>
			Content-Disposition: render
	5.12 Supplying additional comments about the indirect content		5.13 Supplying additional comments about the indirect content
	Optional, freeform text may be supplied to comment on the indirect		One MAY use the Content-Description entity header to provide
	content. This should be supplied in a Content-Description entity		optional, freeform text to comment on the indirect content. This
	header. This text may be displayed to the end user but MUST NOT used		text MAY be displayed to the end user but MUST NOT used by other
	by other elements to determine disposition of the body, as such as		elements to determine disposition of the body.
	usage would result in unreviewed extension to the COntent-type and
	Content-disposition header field functions.
	For example:		For example:
	Content-Type: message/external-body;		Content-Type: message/external-body;
	access-type="URL";		access-type="URL";
	expiration="Mon, 24 June 2002 09:00:00 GMT";		expiration="Mon, 24 June 2002 09:00:00 GMT";
	URL="http://www.example.com/the-indirect-content";		URL="http://www.example.com/the-indirect-content";
	size=52723		size=52723
	<CRLF>		<CRLF>
	Content-Description: Multicast gaming session		Content-Description: Multicast gaming session
			Content-Disposition: render
	5.13 Relationship to Call-Info, Error-Info, and Alert-Info Headers		5.14 Relationship to Call-Info, Error-Info, and Alert-Info Headers
	SIP [9] defines three headers which are used to supply additional		SIP [9] defines three headers that supply additional information with
	information with regard to a session, a particular error response, or		regard to a session, a particular error response, or alerting. All
	alerting. All three of these headers allow the UAC or UAS to		three of these headers allow the UAC or UAS to indicate additional
	indicate additional information through a URI. They may be		information through a URI. They may be considered a form of content
	considered a form of content indirection. The content indirection		indirection. The content indirection mechanism defined in this
	mechanism defined in this document is not intended as a replacement		document is not intended as a replacement for these headers. Rather,
	for these headers. Rather, the headers defined in SIP MUST be used		the headers defined in SIP MUST be used in preference to this
	in preference to this mechanism where applicable because of the well		mechanism where applicable because of the well-defined semantics of
	defined semantics of those headers.		those headers.
	6. Examples		6. Examples
	6.1 Single Content Indirection		6.1 Single Content Indirection
	INVITE sip:boromir@example.com SIP/2.0		INVITE sip:boromir@example.com SIP/2.0
	From: <sip:gandalf@nwt.com>;tag=347242		From: <sip:gandalf@example.net>;tag=347242
	To: <sip:boromir@example.com>		To: <sip:boromir@example.com>
	Call-ID: 3573853342923422@nwt.com		Call-ID: 3573853342923422@example.net
	CSeq: 2131 INVITE		CSeq: 2131 INVITE
	Accept: message/external-body application/sdp		Accept: message/external-body application/sdp
	Content-Type: message/external-body;		Content-Type: message/external-body;
	ACCESS-TYPE=URL;		ACCESS-TYPE=URL;
	URL="http://www.nwt.com/party/06/2002/announcement";		URL="http://www.example.net/party/06/2002/announcement";
	EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT"		EXPIRATION="Sat, 20 Jun 2002 12:00:00 GMT";
	size=231		size=231
	Content-Length: ...		Content-Length: ...
	Content-Type: application/sdp		Content-Type: application/sdp
	Content-Disposition: session		Content-Disposition: session
	Content-ID: <4e5562cd1214427d@nwt.com>		Content-ID: <4e5562cd1214427d@example.net>
	6.2 Multipart MIME with Content Indirection		6.2 Multipart MIME with Content Indirection
	MESSAGE sip:boromir@example.com SIP/2.0		MESSAGE sip:boromir@example.com SIP/2.0
	From: <sip:gandalf@nwt.com>;tag=34589882		From: <sip:gandalf@example.net>;tag=34589882
	To: <sip:boromir@example.com>		To: <sip:boromir@example.com>
	Call-ID: 9242892442211117@nwt.com		Call-ID: 9242892442211117@example.net
	CSeq: 388 MESSAGE		CSeq: 388 MESSAGE
	Accept: message/external-body, text/html, text/plain,		Accept: message/external-body, text/html, text/plain,
	image/*, text/x-emoticon		image/*, text/x-emoticon
	MIME-Version: 1.0		MIME-Version: 1.0
	Content-Type: multipart/mixed; boundary=zz993453		Content-Type: multipart/mixed; boundary=zz993453
	--zz993453		--zz993453
	Content-Type: message/external-body;		Content-Type: message/external-body;
	access-type="URL";		access-type="URL";
	expiration="Mon, 24 June 2002 09:00:00 GMT";		expiration="Mon, 24 June 2002 09:00:00 GMT";
	URL="http://www.nwt.com/company_picnic/image1.png"		URL="http://www.example.net/company_picnic/image1.png";
	size=234422		size=234422
	Content-Type: image/png		Content-Type: image/png
	Content-ID: <9535035333@nwt.com>		Content-ID: <9535035333@example.net>
	Content-Disposition: render		Content-Disposition: render
	Content-Description: Kevin getting dunked in the wading pool		Content-Description: Kevin getting dunked in the wading pool
	--zz993453		--zz993453
	Content-Type: message/external-body;		Content-Type: message/external-body;
	access-type="URL";		access-type="URL";
	expiration="Mon, 24 June 2002 09:00:00 GMT";		expiration="Mon, 24 June 2002 09:00:00 GMT";
	URL="http://www.nwt.com/company_picnic/image2.png"		URL="http://www.example.net/company_picnic/image2.png";
	size=233811		size=233811
	Content-Type: image/png		Content-Type: image/png
	Content-ID: <1134299224244@nwt.com>		Content-ID: <1134299224244@example.net>
	Content-Disposition: render		Content-Disposition: render
	Content-Description: Peter on his tricycle		Content-Description: Peter on his tricycle
	--zz993453--		--zz993453--
	7. Security Considerations		7. Security Considerations
	Any content indirection mechanism introduces additional security		Any content indirection mechanism introduces additional security
	concerns. By its nature, content indirection requires an extra		concerns. By its nature, content indirection requires an extra
	processing step and information transfer. There are a number of		processing step and information transfer. There are a number of
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 46 ¶
	Content-Description: Peter on his tricycle		Content-Description: Peter on his tricycle
	--zz993453--		--zz993453--
	7. Security Considerations		7. Security Considerations
	Any content indirection mechanism introduces additional security		Any content indirection mechanism introduces additional security
	concerns. By its nature, content indirection requires an extra		concerns. By its nature, content indirection requires an extra
	processing step and information transfer. There are a number of		processing step and information transfer. There are a number of
	potential abuses of a content indirection mechanism:		potential abuses of a content indirection mechanism:
	o Content indirection allows the initiator to choose an alternative		o Content indirection allows the initiator to choose an alternative
	protocol with weaker security or known vulnerabilities for the		protocol with weaker security or known vulnerabilities for the
	content transfer. For example, asking the recipient to issue an		content transfer. For example, asking the recipient to issue an
	HTTP request which results in a Basic authentication challenge.		HTTP request that results in a Basic authentication challenge.
	o Content indirection allows the initiator to ask the recipient to		o Content indirection allows the initiator to ask the recipient to
	consume additional resources in the information transfer and		consume additional resources in the information transfer and
	content processing, potentially creating an avenue for denial of		content processing, potentially creating an avenue for denial of
	service attacks. For example, an active FTP URL consuming 2		service attacks. For example, an active FTP URL consuming 2
	connections for every indirect content message.		connections for every indirect content message.
	o Content indirection could be used as a form of port scanning		o Content indirection could be used as a form of port scanning
	attack where the indirect content URL is actually a bogus URL		attack where the indirect content URL is actually a bogus URL
	pointing to an internal resource of the recipient. The response		pointing to an internal resource of the recipient. The response
	to the content indirection request could reveal information about		to the content indirection request could reveal information about
	open (and vulnerable) ports on these internal resources.		open (and vulnerable) ports on these internal resources.
	o A content indirection URL can disclose sensitive information about		o A content indirection URL can disclose sensitive information about
	the initiator such as an internal user name (as part of an HTTP		the initiator such as an internal user name (as part of an HTTP
	URL) or possibly geolocation information.		URL) or possibly geolocation information.
	Fortunately, all of these potential threats can be mitigated through		Fortunately, all of these potential threats can be mitigated through
	careful screening of both the indirect content URIs that are received		careful screening of both the indirect content URIs that are received
	as well as those that are sent. Integrity and privacy protection of		as well as those that are sent. Integrity and confidentiality
	the indirect content URI can prevent additional attacks as well.		protection of the indirect content URI can prevent additional attacks
			as well.
	For confidentiality, integrity, and authentication, this content		For confidentiality, integrity, and authentication, this content
	indirection mechanism relies on the security mechanisms outlined in		indirection mechanism relies on the security mechanisms outlined in
	RFC3261. In particular, the usage of S/MIME as defined in section 23		RFC3261. In particular, the usage of S/MIME as defined in section 23
	of RFC3261 provides the necessary mechanism to ensure integrity		of RFC3261 provides the necessary mechanism to ensure integrity,
	protection and privacy of the indirect content URI and associated		protection, and confidentiality of the indirect content URI and
	parameters.		associated parameters.
	Securing the transfer of the indirect content is the responsibility		Securing the transfer of the indirect content is the responsibility
	of the underlying protocol used for this transfer. If HTTP is used,		of the underlying protocol used for this transfer. If HTTP is used,
	applications implementing this content indirection method MUST		applications implementing this content indirection method SHOULD
	support the HTTPS URI scheme for secure transfer of content and must		support the HTTPS URI scheme for secure transfer of content and MUST
	support the upgrading of connections to TLS using starttls. Note		support the upgrading of connections to TLS using starttls. Note
	that a failure to complete HTTPS or starttls (for example, due to		that a failure to complete HTTPS or starttls (for example, due to
	cert or encryption mismatch) after having accepted the indirect		cert or encryption mismatch) after having accepted the indirect
	content in the SIP request is not the same as rejecting the SIP		content in the SIP request is not the same as rejecting the SIP
	request, and may require additional user-user communication for		request, and may require additional user-user communication for
	correction.		correction.
			Note that this document does not advocate the use of transitive
			trust. That is, just because the UAS receives a URI from a UAC that
			the UAS trusts, the UAS SHOULD NOT implicitly trust the object
			referred to by the URI without establishing its own trust
			relationship with the URI provider.
	Access control to the content referenced by the URI is not defined by		Access control to the content referenced by the URI is not defined by
	this specification. Access control mechanisms may be defined by the		this specification. Access control mechanisms may be defined by the
	protocol for the scheme of the indirect content URI.		protocol for the scheme of the indirect content URI.
	If the UAC knows the content in advance, the UAC SHOULD include a		If the UAC knows the content in advance, the UAC SHOULD include a
	hash parameter in the content indirection. The hash parameter is a		hash parameter in the content indirection. The hash parameter is a
	base64-encoded SHA-1 hash of the indirected content. [8] If a hash		hexadecimal-encoded SHA-1 [8] hash of the indirect content. If a
	value is included, the recipient MUST check the indirect content		hash value is included, the recipient MUST check the indirect content
	against that hash and indicate any mismatch to the user.		against that hash and indicate any mismatch to the user.
	In addition, if the hash parameter is included, and the target URI		In addition, if the hash parameter is included, and the target URI
	involves setting up a security context using certificates, the UAS		involves setting up a security context using certificates, the UAS
	MUST ignore the results of the certificate validation procedure, and		MUST ignore the results of the certificate validation procedure, and
	instead verify that the hash of the (canonicalized) content received		instead verify that the hash of the (canonicalized) content received
	matches the hash presented in the content-indirection hash parameter.		matches the hash presented in the content-indirection hash parameter.
	If the hash parameter is NOT included, the sender SHOULD use only		If the hash parameter is NOT included, the sender SHOULD use only
	schemes which offer message integrity (such as https:). When the		schemes that offer message integrity (such as https:). When the hash
	hash parameter is not included and security using certificates is		parameter is not included and security using certificates is used,
	used, the UAS MUST verify any server certificates using the UAS's		the UAS MUST verify any server certificates using the UAS's list of
	list of trusted top-level certificate authorities.		trusted top-level certificate authorities.
	If hashing of indirected content is not used, the possibility exists		If hashing of indirect content is not used, the possibility exists
	that the content returned to the recipient by exercise of the		that the content returned to the recipient by exercise of the
	indirection has been altered from that intended by the sender.		indirection has been altered from that intended by the sender.
	8. IANA Considerations		8. IANA Considerations
	This document raises no new IANA considerations.		This document raises no new IANA considerations.
	9. Contributions		9. Contributions
	It should be noted that the vast majority of this document, including		Sean Olson, seanol@microsoft.com, provided the vast majority of the
	editorship through the first IESG review, was provided by Sean Olson,		content of this document, including editorship through the first IESG
	seanol@microsoft.com		review.
	10. References		Dean Willis touched it next.
	10.1 Normative References		Eric Burger edited the document and addressed IESG comments,
			including the access protocol negotiation mechanism.
	[1] Freed, N. and K. Moore, "Definition of the URL MIME		10. Acknowledgements
	External-Body Access-Type", RFC 2017, October 1996.
	[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		Cullen Jennings and Nancy Greene provided a through review and
	Extensions (MIME) Part One: Format of Internet Message Bodies",		valuable comments and suggestions.
	RFC 2045, November 1996.
	[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		11. References
	Extensions (MIME) Part Two: Media Types", RFC 2046, November		11.1 Normative References
	1996.
	[4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.		[1] Freed, N. and K. Moore, "Definition of the URL MIME
	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC		External-Body Access-Type", RFC 2017, October 1996.
	2068, January 1997.
	[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Levels", BCP 14, RFC 2119, March 1997.		Extensions (MIME) Part One: Format of Internet Message Bodies",
			RFC 2045, November 1996.
	[6] Daniel, R., "A Trivial Convention for using HTTP in URN		[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Resolution", RFC 2169, June 1997.		Extensions (MIME) Part Two: Media Types", RFC 2046, November
			1996.
	[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource		[4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
	Identifiers (URI): Generic Syntax", RFC 2396, August 1998.		Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
			2068, January 1997.
	[8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	RFC 3174, September 2001.		Levels", BCP 14, RFC 2119, March 1997.
	[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[6] Daniel, R., "A Trivial Convention for using HTTP in URN
	Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:		Resolution", RFC 2169, June 1997.
	Session Initiation Protocol", RFC 3261, June 2002.
	10.2 References References		[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
			Resource Identifiers (URI): Generic Syntax", RFC 2396, August
			1998.
	[10] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform		[8] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
			RFC 3174, September 2001.
			[9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
			Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
			Session Initiation Protocol", RFC 3261, June 2002.
			[10] Burger, E., "Critical Content Multi-purpose Internet Mail
			Extensions (MIME) Parameter", RFC 3459, January 2003.
			[11] Rosenberg, J., "A Framework for Application Interaction in the
			Session Initiation Protocol (SIP)",
			draft-ietf-sipping-app-interaction-framework-02 (work in
			progress), July 2004.
			11.2 Informative References
			[12] Levinson, E., "The MIME Multipart/Related Content-type", RFC
			2387, August 1998.
			[13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax",		Resource Identifier (URI): Generic Syntax",
	draft-fielding-uri-rfc2396bis-05 (work in progress), April		draft-fielding-uri-rfc2396bis-06 (work in progress), July 2004.
	2004.
	Author's Address		Author's Address
	Dean Willis (editor)		Eric Burger (editor)
	dynamicsoft Inc.		Brooktrout Technology, Inc.
	EMail: dean.willis@softarmor.com		EMail: eburger@brooktrout.com
	URI: http://www.softarmor.com		URI: http://www.brooktrout.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
End of changes. 91 change blocks.
	209 lines changed or deleted		255 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/