draft-ietf-sipcore-content-id-01.txt		draft-ietf-sipcore-content-id-02.txt
	SIPCORE Working Group C. Holmberg		SIPCORE Working Group C. Holmberg
	Internet-Draft I. Sedlacek		Internet-Draft I. Sedlacek
	Intended status: Standards Track Ericsson		Updates: 5621 (if approved) Ericsson
	Expires: September 9, 2017 March 8, 2017		Intended status: Standards Track April 25, 2017
			Expires: October 27, 2017
	Content ID header field in Session Initiation Protocol (SIP)		Content-ID header field in Session Initiation Protocol (SIP)
	draft-ietf-sipcore-content-id-01		draft-ietf-sipcore-content-id-02
	Abstract		Abstract
	This document specifies the Content-ID header field for usage in the		This document specifies the Content-ID header field for usage in the
	Session Initiation Protocol (SIP).		Session Initiation Protocol (SIP). The document also updates RFC
			5621, to enable a Content-ID URL to refer a complete message-body and
			metadata provided by some additional SIP header fields.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on September 9, 2017.		This Internet-Draft will expire on October 27, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Setting up ID value uniquely identifying body . . . . . . 2		1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2
	1.2. Referencing the ID value uniquely identifying body . . . 3		1.2. Referring a body part . . . . . . . . . . . . . . . . . . 3
	1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3		1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3
	1.4. Examples of the problem . . . . . . . . . . . . . . . . . 3		1.4. Consequencies . . . . . . . . . . . . . . . . . . . . . . 3
	1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3		1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3
	1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4		1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4
	1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4		1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Content-ID header field . . . . . . . . . . . . . . . . . . . 5		3. Content-ID header field . . . . . . . . . . . . . . . . . . . 4
	3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Semantic . . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6		3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5
	3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 6		3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5
	3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6		3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. Security considerations . . . . . . . . . . . . . . . . . . . 6
	5.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 6		6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7		6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 7
	7. Normative References . . . . . . . . . . . . . . . . . . . . 7		7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7
			8. Normative references . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	1.1. Setting up ID value uniquely identifying body		1.1. Identifying a body part
	A SIP message consists of a start-line, one or more header fields, an		A SIP message consists of a start-line, one or more header fields, an
	empty line indicating the end of the header fields, and an optional		empty line indicating the end of the header fields, and an optional
	message-body, as specified in [RFC3261].		message-body, as specified in [RFC3261].
	A message-body of the SIP message can contain one body only or can		The message-body can be a non-multipart message-body or a multipart
	contain several body parts, as specified in [RFC3261] and [RFC5621].		message-body as specified in [RFC3261].
	A body part encoded using [RFC2045] can contain a Content-ID header		[RFC5621] defines generic handling of a multipart message-body in a
	field with an ID value uniquely identifying the body part, as		SIP message.
	specified in [RFC2045].
	However, when the message-body of the SIP message contains one body		A multipart message-body contains zero, one or several body parts,
	only, there is no body part specified. Thus, there is also no		encoded using [RFC2045] format.
	defined method how to convey an ID value uniquely identifying the
	body part.
	1.2. Referencing the ID value uniquely identifying body		A body part in the multipart message-body is described using header
			fields such as Content-Disposition, Content-Encoding, and Content-
			Type, which provide information on the content of the body part, as
			specified in [RFC5621]. A body part in the multipart message-body
			can also contain a Content-ID header field with an ID value uniquely
			identifying the body part, as specified in [RFC2045].
	A SIP header field can contain a reference to a body part using a		1.2. Referring a body part
	Content-ID URL, as specified in [RFC5621].
	The Content-ID URL is specified in [RFC2392]. [RFC2392] also		A SIP header field can refer a body part using a Content-ID URL, as
	specifies how to discover the body part referenced by a Content-ID		specified in [RFC5621].
	URL.
	Examples of a SIP header field referencing a body part using a		The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies
	Content-ID URL are:		how to identify the body part referred by a Content-ID URL. The
			Content-ID URL value is included in the Content-ID header field of
			the body part.
	o [RFC6442] specifies how a Geolocation header field references a		Examples of SIP header fields referring a body part using a Content-
	body part using a Content-ID URL, for providing location.		ID URL are:
	o [RFC5368] specifies how a Refer-To header field references a body
	part using a Content-ID URL, to provide a list of targets.		o [RFC6442] specifies how a Geolocation header field refers a body
			part using a Content-ID URL, for providing location.
			o [RFC5368] specifies how a Refer-To header field refers a body part
			using a Content-ID URL, to provide a list of targets.
	1.3. Problem statement		1.3. Problem statement
	Since the Content-ID header field is not a defined SIP header field:		It is currently not specified how to uniquely identify a complete
			message-body of a SIP message using a Content-ID header field, and
			how to refer a complete message-body using a Content-ID URL.
	o If solely one body needs to be transported in a SIP message and		1.4. Consequencies
	the UAC does not need to include in the SIP message a SIP header
	field referencing the body part, then the UAC sets the message-
	body to the body.
	o However, if solely one body needs to be transported in a SIP
	message and the UAC needs to include in the SIP message a SIP
	header field referencing the body part, then the UAC sets the
	message-body to be of the "multipart" MIME type and includes one
	body part and associated Content-ID header field.
	1.4. Examples of the problem		The examples below shows the consequencies of the problem described
			above.
	1.4.1. Example 1		1.4.1. Example 1
	If a UAC sends an INVITE request conveying location as specified in		If a UAC sends an INVITE request conveying location as specified in
	[RFC6442], if the UAC decides not to include an SDP offer, and if the		[RFC6442], if the UAC decides not to include an SDP offer, and if the
	location is conveyed by value, then the UAC needs to include one body		location is conveyed by value, then the UAC needs to include one
	only in the INVITE request.		content only in the INVITE request. This content can be e.g. of the
	This body contains the location information and can be e.g. of the
	application/pidf+xml MIME type.		application/pidf+xml MIME type.
	However, due to [RFC6442] requiring inclusion of a Geolocation header		However, due to [RFC6442] requiring inclusion of a Geolocation header
	field referencing the body part containing the location information,		field referring the body part with the location information, the UAC
	the UAC needs to include a message-body of "multipart/mixed" MIME		includes a multipart message-body with single body part in the INVITE
	type in the INVITE request, and the UAC needs to include a body part		request, and includes the location information of application/
	of the application/pidf+xml MIME type and associated Content-ID		pidf+xml MIME type and an associated Content-ID header field in the
	header field in the message-body of the "multipart/mixed" MIME type.		body part.
	1.4.2. Example 2		1.4.2. Example 2
	If a UAC sends an REFER request including a list of targets as		If a UAC sends an REFER request including a list of targets as
	specified in [RFC5368], then the UAC needs to include one body only		specified in [RFC5368], then the UAC needs to include one content
	in the REFER request.		only in the REFER request. This content is of the application/
	This body contains the list of targets and is of the application/
	resource-lists+xml MIME type.		resource-lists+xml MIME type.
	However, due to [RFC5368] requiring inclusion of a Refer-To header		However, due to [RFC5368] requiring inclusion of a Refer-To header
	field referencing the body part containing the list of targets, the		field referring the body part containing the list of targets, the UAC
	UAC needs to include a message-body of the "multipart/mixed" MIME		includes a multipart message-body with single body part in the REFER
	type in the REFER request and the UAC needs to include a body part of		request, and includes the list of targets of application/resource-
	the application/resource-lists+xml MIME type and associated Content-		lists+xml MIME type and an associated Content-ID header field in the
	ID header field in the message-body of the "multipart/mixed" MIME		body part.
	type.
	1.5. Solution		1.5. Solution
	To avoid the unnecessary usage of a message-body of a "multipart"		In order to solve the problems described above, this document:
	MIME type when only one body needs to be included in a SIP message,
	this document specifies a Content-ID header field as a SIP header
	field.
	The Content-ID header field included in header fields of a SIP		o Specifies and registers the Content-ID header field as a SIP
	message identifies a body part consisting of the message-body of the		header field; and
	SIP message and:		o Specifies that, when used as a SIP header field, the Content-ID
			header field identifies the complete message-body, and metadata
			provided by some additional SIP header fields, of the SIP message;
			and
			o Updates [RFC5621], to enable a Content-ID URL to refer a complete
			message-body and metadata provided by some additional SIP header
			fields.
	o a MIME-Version header field, if included in the header fields of		NOTE: In [RFC5621], the Content-ID URL refers a specific body part
	the SIP message;		only.
	o a Content-Disposition header field, if included in the header
	fields of the SIP message;
	o a Content-Encoding header field, if included in the header fields
	of the SIP message;
	o a Content-ID header field, if included in the header fields of the
	SIP message;
	o a Content-Language header field, if included in the header fields
	of the SIP message;
	o a Content-Length header field, if included in the header fields of
	the SIP message;
	o a Content-Type header field, if included in the header fields of
	the SIP message.
	2. Conventions		2. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Content-ID header field		3. Content-ID header field
	3.1. Introduction		3.1. Introduction
	This section defines the usage of the Content-ID header field for		This section defines the usage of the Content-ID header field for
	SIP.		SIP.
	3.2. Syntax		3.2. Syntax
	The ABNF for the Content-ID header fields is:		The ABNF for the Content-ID header fields is:
	Content-ID = "Content-ID" HCOLON msg-id		Content-ID = "Content-ID" HCOLON msg-id
	NOTE: msg-id is specified in [RFC5322].		msg-id = "<" id-left "@" id-right ">"
	3.3. Semantic		NOTE: id-left and id-right are specified in [RFC5322].
	A Content-ID header field included in header fields of a SIP message		NOTE: When used in a SIP header field, the msg-id syntax has been
	indicates a globally unique identification of a body part consisting		simplified compared to the syntax in [RFC5322].
	of the message-body of the SIP message and:
			3.3. Semantics
			The Content-ID header field included in the header fields of a SIP
			message identifies the message-body of the SIP message, and the
			metadata provided by:
			o the Content-ID header field itself;
	o a MIME-Version header field, if included in the header fields of		o a MIME-Version header field, if included in the header fields of
	the SIP message;		the SIP message;
	o a Content-Disposition header field, if included in the header		o a Content-Disposition header field, if included in the header
	fields of the SIP message;		fields of the SIP message;
	o a Content-Encoding header field, if included in the header fields		o a Content-Encoding header field, if included in the header fields
	of the SIP message;		of the SIP message;
	o a Content-ID header field, if included in the header fields of the
	SIP message;
	o a Content-Language header field, if included in the header fields		o a Content-Language header field, if included in the header fields
	of the SIP message;		of the SIP message;
	o a Content-Length header field, if included in the header fields of		o a Content-Length header field, if included in the header fields of
	the SIP message;		the SIP message; and
	o a Content-Type header field, if included in the header fields of		o a Content-Type header field, if included in the header fields of
	the SIP message.		the SIP message.
	The Content-ID header field can be included in any SIP message which		The Content-ID header field can be included in any SIP message which
	is allowed to contain a message-body.		is allowed to contain a message-body.
	3.4. Procedures		3.4. Procedures
	3.4.1. UA procedures		3.4.1. UA procedures
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 17 ¶
	3.4.2. Proxy procedures		3.4.2. Proxy procedures
	A proxy MUST NOT add a Content-ID header field in a SIP message.		A proxy MUST NOT add a Content-ID header field in a SIP message.
	A proxy MUST NOT modify a Content-ID header field included in a SIP		A proxy MUST NOT modify a Content-ID header field included in a SIP
	message.		message.
	A proxy MUST NOT delete a Content-ID header field from a SIP message.		A proxy MUST NOT delete a Content-ID header field from a SIP message.
	4. Security Considerations		4. Update to RFC 5621
			This section updates section 9.1 of [RFC5621], by allowing a Content-
			ID URL to reference a message-body and the related metadata
			(Section 3.3), in addition to allowing to reference to a body part.A
			OLD TEXT:
			Content-ID URLs allow creating references to body parts. A given
			Content-ID URL [RFC2392], which can appear in a header field or
			within a body part (e.g., in an SDP attribute), points to a
			particular body part.
			NEW TEXT:
			Content-ID URLs allow creating references to body parts or
			message-bodies (and the header fields describing the
			message-bodies). A given Content-ID URL [RFC2392], which can appear
			in a header field or within a body part (e.g., in an SDP attribute),
			points to a particular body part or the message-body (and the
			header fields describing the message-body).
			5. Security considerations
	The Content-ID header field value MUST NOT reveal sensitive user		The Content-ID header field value MUST NOT reveal sensitive user
	information.		information.
	If the message-body associated with the Content-ID header field		If the message-body associated with the Content-ID header field is an
	contains encrypted content, it MUST NOT be possible to derive a key		encrypted body, it MUST NOT be possible to derive a key that can be
	that can be used to decrypt the message-body content from the		used to decrypt the body from the Content-ID header field value.
	Content-ID header field value.
	5. IANA Considerations		6. IANA considerations
	This specification registers a new SIP header field according to the		This specification registers a new SIP header field according to the
	procedures in [RFC3261].		procedures in [RFC3261].
	5.1. Header Field		6.1. Header field
	[RFC EDITOR NOTE: Please replace XXXX with the RFC number of this		[RFC EDITOR NOTE: Please replace XXXX with the RFC number of this
	document when publishing]		document when publishing]
	RFC Number: RFC XXXX		RFC Number: RFC XXXX
	Header Field Name: Content-ID		Header Field Name: Content-ID
	Compact Form: none		Compact Form: none
	6. Change Log		7. Change log
	[RFC EDITOR NOTE: Please remove this section when publishing]		[RFC EDITOR NOTE: Please remove this section when publishing]
	Changes in draft-ietf-sipcore-content-id-01:		Changes from draft-ietf-sipcore-content-id-01
	o Clean up of section 1, including shortening introduction and		o Update to RFC 5621 added.
	cleaning up of "body" and "body part" usages.		o Editorial changes.
	o Clarify that the SIP header fields forming the body part are not
	required to be present in the SIP message.
	o MIME-Version header field included as one of the SIP header fields
	forming the body part;
	7. Normative References		8. Normative references
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,		Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
	<http://www.rfc-editor.org/info/rfc2045>.		<http://www.rfc-editor.org/info/rfc2045>.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,
	DOI 10.17487/RFC2046, November 1996,
	<http://www.rfc-editor.org/info/rfc2046>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource		[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
	Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,		Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
	<http://www.rfc-editor.org/info/rfc2392>.		<http://www.rfc-editor.org/info/rfc2392>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
End of changes. 44 change blocks.
	123 lines changed or deleted		129 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/