draft-ietf-sipcore-content-id-03.txt		draft-ietf-sipcore-content-id-04.txt
	SIPCORE Working Group C. Holmberg		SIPCORE Working Group C. Holmberg
	Internet-Draft I. Sedlacek		Internet-Draft I. Sedlacek
	Updates: 5621 (if approved) Ericsson		Updates: 5621 (if approved) Ericsson
	Intended status: Standards Track April 28, 2017		Intended status: Standards Track May 8, 2017
	Expires: October 30, 2017		Expires: November 9, 2017
	Content-ID header field in Session Initiation Protocol (SIP)		Content-ID header field in Session Initiation Protocol (SIP)
	draft-ietf-sipcore-content-id-03		draft-ietf-sipcore-content-id-04
	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). The document also updates RFC		Session Initiation Protocol (SIP). The document also updates RFC
	5621, to enable a Content-ID URL to reference a complete message-body		5621, to enable a Content-ID URL to reference a complete message-body
	and metadata provided by some additional SIP header fields.		and metadata provided by some additional SIP header fields.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 October 30, 2017.		This Internet-Draft will expire on November 9, 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
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Content-ID header field . . . . . . . . . . . . . . . . . . . 4		3. Content-ID header field . . . . . . . . . . . . . . . . . . . 4
	3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5		3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5
	3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5		3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5
	3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 5		3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6
	4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 6		4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 6
	5. Security considerations . . . . . . . . . . . . . . . . . . . 6		5. Security considerations . . . . . . . . . . . . . . . . . . . 6
	6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 7		6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 7
	7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Normative references . . . . . . . . . . . . . . . . . . . . 7		8. Normative references . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 40 ¶
	1.4. Consequences		1.4. Consequences
	The examples below shows the consequences of the problem described		The examples below shows the consequences of the problem described
	above.		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		location is conveyed by value, then the UAC needs to include only one
	content only in the INVITE request. This content can be e.g. of the		MIME entity in the INVITE request. This content 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 with the location information, the		field referencing the body part with the location information, the
	UAC includes a multipart message-body with single body part in the		UAC includes a multipart message-body with single body part in the
	INVITE request, and includes the location information of application/		INVITE request, and includes the location information of application/
	pidf+xml MIME type and an associated Content-ID header field in the		pidf+xml MIME type and an associated Content-ID header field in the
	body part.		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 content		specified in [RFC5368], then the UAC needs to include only one MIME
	only in the REFER request. This content is of the application/		entity in the REFER request. This content 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 referencing the body part containing the list of targets, the
	UAC includes a multipart message-body with single body part in the		UAC includes a multipart message-body with single body part in the
	REFER request, and includes the list of targets of application/		REFER request, and includes the list of targets of application/
	resource-lists+xml MIME type and an associated Content-ID header		resource-lists+xml MIME type and an associated Content-ID header
	field in the body part.		field in the body part.
	1.5. Solution		1.5. Solution
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	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 [RFC5234] for the Content-ID header field is:
	Content-ID = "Content-ID" HCOLON msg-id		Content-ID = "Content-ID" HCOLON msg-id
	msg-id = "<" id-left "@" id-right ">"		msg-id = "<" id-left "@" id-right ">"
	NOTE: id-left and id-right are specified in [RFC5322].		NOTE: id-left and id-right are specified in [RFC5322]. HCOLON is
			defined in [RFC3261].
	NOTE: When used in a SIP header field, the msg-id syntax has been		NOTE: When used in a SIP header field, the msg-id syntax has been
	simplified compared to the syntax in [RFC5322].		simplified compared to the syntax in [RFC5322].
	3.3. Semantics		3.3. Semantics
	The Content-ID header field included in the header fields of a SIP		The Content-ID header field included in the header fields of a SIP
	message identifies the message-body of the SIP message, and the		message identifies the message-body of the SIP message, and the
	metadata provided by:		metadata provided by:
	skipping to change at page 5, line 37 ¶		skipping to change at page 5, line 38 ¶
	header field itself) included in the header fields of the SIP		header field itself) included in the header fields of the SIP
	message.		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
	A UA MAY include a Content-ID header field in any SIP message which		A UA MAY include a Content-ID header field in any SIP message that is
	is allowed to contain a message-body.		allowed to contain a message-body.
	A UA MUST NOT include a Content-ID header field in any SIP message		A UA MUST NOT include a Content-ID header field in any SIP message
	which is not allowed to contain a message-body.		that is not allowed to contain a message-body.
	The UA MUST set the value of the Content-ID header field to a		The UA MUST set the value of the Content-ID header field to a
	globally unique value.		globally unique value.
	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.
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	encrypted body, it MUST NOT be possible to derive a key that can be		encrypted body, it MUST NOT be possible to derive a key that can be
	used to decrypt the body from the Content-ID header field value.		used to decrypt the body from the Content-ID header field value.
	6. 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].
	6.1. Header field		6.1. Header field
			The header field described in Section 3 has been registered in the
			"Header Fields" sub-registry of the "Session Initiation Protocol
			(SIP) Parameters" registry by adding a row with these values:
	[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		Header Name: Content-ID
	Header Field Name: Content-ID		compact:
	Compact Form: none		Reference: RFCXXXX
	7. Change log		7. Change log
	[RFC EDITOR NOTE: Please remove this section when publishing]		[RFC EDITOR NOTE: Please remove this section when publishing]
			Changes from draft-ietf-sipcore-content-id-03
			o Changes based on doc shepard review:
			o - Reference to RFC 5234 added.
			o - Editorial changes.
	Changes from draft-ietf-sipcore-content-id-02		Changes from draft-ietf-sipcore-content-id-02
	o Editorial changes based on comments from Paul Kyzivat.		o Editorial changes based on comments from Paul Kyzivat.
	Changes from draft-ietf-sipcore-content-id-01		Changes from draft-ietf-sipcore-content-id-01
	o Update to RFC 5621 added.		o Update to RFC 5621 added.
	o Editorial changes.		o Editorial changes.
	8. Normative references		8. Normative references
	skipping to change at page 7, line 45 ¶		skipping to change at page 8, line 9 ¶
	[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>.
			[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", STD 68, RFC 5234,
			DOI 10.17487/RFC5234, January 2008,
			<http://www.rfc-editor.org/info/rfc5234>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	DOI 10.17487/RFC5322, October 2008,		DOI 10.17487/RFC5322, October 2008,
	<http://www.rfc-editor.org/info/rfc5322>.		<http://www.rfc-editor.org/info/rfc5322>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<http://www.rfc-editor.org/info/rfc3261>.		<http://www.rfc-editor.org/info/rfc3261>.
End of changes. 16 change blocks.
	17 lines changed or deleted		33 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/