draft-ietf-sipcore-content-id-05.txt		draft-ietf-sipcore-content-id-06.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 May 9, 2017		Intended status: Standards Track June 5, 2017
	Expires: November 10, 2017		Expires: December 7, 2017
	Content-ID header field in Session Initiation Protocol (SIP)		Content-ID header field in Session Initiation Protocol (SIP)
	draft-ietf-sipcore-content-id-05		draft-ietf-sipcore-content-id-06
	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 November 10, 2017.		This Internet-Draft will expire on December 7, 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 23 ¶		skipping to change at page 2, line 23 ¶
	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 . . . . . . . . . . . . . . . . . . 6		3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6
	4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 6		3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security considerations . . . . . . . . . . . . . . . . . . . 6		4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 7
	6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6		5. Security considerations . . . . . . . . . . . . . . . . . . . 8
	6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 7		6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7		6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 8
	8. Normative references . . . . . . . . . . . . . . . . . . . . 7		7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		8. Normative references . . . . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	1.1. Identifying a body part		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].
	The message-body can be a non-multipart message-body or a multipart		The message-body can be a non-multipart message-body or a multipart
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 31 ¶
	body part using a Content-ID URL, for providing location.		body part using a Content-ID URL, for providing location.
	o [RFC5368] specifies how a Refer-To header field references a body		o [RFC5368] specifies how a Refer-To header field references a body
	part using a Content-ID URL, to provide a list of targets.		part using a Content-ID URL, to provide a list of targets.
	1.3. Problem statement		1.3. Problem statement
	It is currently not specified how to uniquely identify a complete		It is currently not specified how to uniquely identify a complete
	message-body of a SIP message using a Content-ID header field, and		message-body of a SIP message using a Content-ID header field, and
	how to reference a complete message-body using a Content-ID URL.		how to reference a complete message-body using a Content-ID URL.
			NOTE: In [RFC5621], the Content-ID URL references a specific body
			part only.
	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 only one		location is conveyed by value, then the UAC needs to include only one
	skipping to change at page 4, line 33 ¶		skipping to change at page 4, line 35 ¶
	o Specifies and registers the Content-ID header field as a SIP		o Specifies and registers the Content-ID header field as a SIP
	header field; and		header field; and
	o Specifies that, when used as a SIP header field, the Content-ID		o Specifies that, when used as a SIP header field, the Content-ID
	header field identifies the complete message-body, and metadata		header field identifies the complete message-body, and metadata
	provided by some additional SIP header fields, of the SIP message;		provided by some additional SIP header fields, of the SIP message;
	and		and
	o Updates [RFC5621], to enable a Content-ID URL to reference a		o Updates [RFC5621], to enable a Content-ID URL to reference a
	complete message-body and metadata provided by some additional SIP		complete message-body and metadata provided by some additional SIP
	header fields.		header fields.
	NOTE: In [RFC5621], the Content-ID URL references a specific body
	part only.
	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 [RFC5234] for the Content-ID header field 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]. HCOLON is		NOTE: id-left and id-right are specified in [RFC5322]. HCOLON is
	defined in [RFC3261].		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], to disallow the use
			of comments and to adopt to the SIP usage of leading white space.
			The value of Content-Id header field value must be unique in the
			context of a given SIP message, including any embedded MIME
			Content-Id header field values. Note that the SIP Content-ID header
			field value is not expected to be unique among all SIP messages; it
			has no meaning outside of the message in which it is included.
	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:
	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; and		the SIP message; and
	o any 'Content-' prefixed header fields (including the Content-ID		o any 'Content-' prefixed header fields (including the Content-ID
	skipping to change at page 6, line 14 ¶		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.
			3.4.3. Example
			The figure shows an example from [RFC5368], where the SIP Content-ID
			header field is used to reference the message body (non-multipart) of
			a SIP message.
			REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
			Via: SIP/2.0/TCP client.chicago.example.com
			;branch=z9hG4bKhjhs8ass83
			Max-Forwards: 70
			To: "Conference 123" <sip:conf-123@example.com>
			From: Carol <sip:carol@chicago.example.com>;tag=32331
			Call-ID: d432fa84b4c76e66710
			CSeq: 2 REFER
			Contact: <sip:carol@client.chicago.example.com>
			Refer-To: <cid:cn35t8jf02@example.com>
			Refer-Sub: false
			Require: multiple-refer, norefersub
			Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
			Allow-Events: dialog
			Accept: application/sdp, message/sipfrag
			Content-Type: application/resource-lists+xml
			Content-Disposition: recipient-list
			Content-Length: 362
			Content-ID: <cn35t8jf02@example.com>
			<?xml version="1.0" encoding="UTF-8"?>
			<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<list>
			<entry uri="sip:bill@example.com?method=BYE" />
			<entry uri="sip:joe@example.org?method=BYE" />
			<entry uri="sip:ted@example.net?method=BYE" />
			</list>
			</resource-lists>
	4. Update to RFC 5621		4. Update to RFC 5621
	This section updates section 9.1 of [RFC5621], by allowing a Content-		This section updates section 9.1 of [RFC5621], by allowing a Content-
	ID URL to reference a message-body and the related metadata		ID URL to reference a message-body and the related metadata
	(Section 3.3), in addition to allowing a reference to a body part.		(Section 3.3), in addition to allowing a reference to a body part.
	OLD TEXT:		OLD TEXT:
	Content-ID URLs allow creating references to body parts. A given		Content-ID URLs allow creating references to body parts. A given
	Content-ID URL [RFC2392], which can appear in a header field or		Content-ID URL [RFC2392], which can appear in a header field or
	skipping to change at page 7, line 24 ¶		skipping to change at page 9, line 9 ¶
	Header Name: Content-ID		Header Name: Content-ID
	compact:		compact:
	Reference: RFCXXXX		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-05
			o Changes based on AD comments from Ben Campell:
			o - Clarifying that Content-ID header field value is unique within
			the scope of a SIP message.
	Changes from draft-ietf-sipcore-content-id-04		Changes from draft-ietf-sipcore-content-id-04
	o Minor editorial fix.		o Minor editorial fix.
	Changes from draft-ietf-sipcore-content-id-03		Changes from draft-ietf-sipcore-content-id-03
	o Changes based on doc shepard review:		o Changes based on doc shepard review:
	o - Reference to RFC 5234 added.		o - Reference to RFC 5234 added.
			o - SIP message example added.
	o - Editorial changes.		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.
End of changes. 13 change blocks.
	20 lines changed or deleted		71 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/