draft-ietf-sipcore-content-id-06.txt		draft-ietf-sipcore-content-id-07.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 June 5, 2017		Intended status: Standards Track June 28, 2017
	Expires: December 7, 2017		Expires: December 30, 2017
	Content-ID header field in Session Initiation Protocol (SIP)		Content-ID header field in Session Initiation Protocol (SIP)
	draft-ietf-sipcore-content-id-06		draft-ietf-sipcore-content-id-07
	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, which only allows a Content-ID URL to reference a body-part
	and metadata provided by some additional SIP header fields.		that is part of a multipart message-body. This update enables a
			Content-ID URL to reference 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 December 7, 2017.		This Internet-Draft will expire on December 30, 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 13 ¶		skipping to change at page 2, line 15 ¶
	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. Identifying a body part . . . . . . . . . . . . . . . . . 2		1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2
	1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3		1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3
	1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3		1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3
	1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 3		1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 3
	1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3		1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3
	1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4		1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 5
	1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4		1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Content-ID header field . . . . . . . . . . . . . . . . . . . 4		3. Content-ID header field . . . . . . . . . . . . . . . . . . . 7
	3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5		3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 8
	3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5		3.4.1. User Agent (UA) procedures . . . . . . . . . . . . . 8
	3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6		3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 8
	3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 6		3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 7		4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 9
	5. Security considerations . . . . . . . . . . . . . . . . . . . 8		5. Security considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 8		6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 10
	7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Normative references . . . . . . . . . . . . . . . . . . . . 9		8. Normative references . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	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 21 ¶		skipping to change at page 3, line 26 ¶
	The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies		The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies
	how to identify the body part referenced by a Content-ID URL. The		how to identify the body part referenced by a Content-ID URL. The
	Content-ID URL value is included in the Content-ID header field of		Content-ID URL value is included in the Content-ID header field of
	the body part.		the body part.
	Examples of SIP header fields referencing a body part using a		Examples of SIP header fields referencing a body part using a
	Content-ID URL are:		Content-ID URL are:
	o [RFC6442] specifies how a Geolocation header field references a		o [RFC6442] specifies how a Geolocation header field references a
	body part using a Content-ID URL, for providing location.		body part using a Content-ID URL, for providing location
			information.
	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		NOTE: In [RFC5621], the Content-ID URL references a specific body
	part only.		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 User Agent Client (UAC) sends an INVITE request conveying
	[RFC6442], if the UAC decides not to include an SDP offer, and if the		location as specified in [RFC6442], if the UAC decides not to include
	location is conveyed by value, then the UAC needs to include only one		an SDP offer, and if the location is conveyed by value, then the UAC
	MIME entity in the INVITE request. This MIME entity can be e.g. of		needs to include only one MIME entity in the INVITE request. This
	the application/pidf+xml MIME type.		MIME entity can be, for example, of the 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.
			Example message (SIP INVITE):
			INVITE sips:bob@biloxi.example.com SIP/2.0
			Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
			Max-Forwards: 70
			To: Bob <sips:bob@biloxi.example.com>
			From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
			Call-ID: 3848276298220188511@atlanta.example.com
			Geolocation: <cid:target123@atlanta.example.com>
			Geolocation-Routing: no
			Accept: application/sdp, application/pidf+xml
			CSeq: 31862 INVITE
			Contact: <sips:alice@atlanta.example.com>
			Content-Type: multipart/mixed; boundary=boundary1
			Content-Length: ...
			--boundary1
			Content-Type: application/pidf+xml
			Content-ID: <target123@atlanta.example.com>
			<?xml version="1.0" encoding="UTF-8"?>
			<presence
			xmlns="urn:ietf:params:xml:ns:pidf"
			xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
			xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
			xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
			xmlns:gml="http://www.opengis.net/gml"
			xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
			entity="pres:alice@atlanta.example.com"
			>
			<dm:device id="target123-1">
			<gp:geopriv>
			<gp:location-info>
			<gml:location>
			<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
			<gml:pos>32.86726 -97.16054</gml:pos>
			</gml:Point>
			</gml:location>
			</gp:location-info>
			<gp:usage-rules>
			<gbp:retransmission-allowed>false
			</gbp:retransmission-allowed>
			<gbp:retention-expiry>2010-11-14T20:00:00Z
			</gbp:retention-expiry>
			</gp:usage-rules>
			<gp:method>802.11</gp:method>
			</gp:geopriv>
			<dm:deviceID>mac:1234567890ab</dm:deviceID>
			<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
			</dm:device>
			</presence>
			--boundary1--
	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 only one MIME		specified in [RFC5368], then the UAC needs to include only one MIME
	entity in the REFER request. This MIME entity is of the application/		entity in the REFER request. This MIME entity 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.
			Example message (SIP REFER):
			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: multipart/mixed; boundary=boundary1
			Content-Length: ...
			--boundary1
			Content-Type: application/resource-lists+xml
			Content-Disposition: recipient-list
			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>
			--boundary1--
	1.5. Solution		1.5. Solution
	In order to solve the problems described above, this document:		In order to solve the problems described above, this document:
	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
	skipping to change at page 5, line 34 ¶		skipping to change at page 8, line 4 ¶
	has no meaning outside of the message in which it is included.		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
	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.
			NOTE: The message body identified by the Content-ID header field can
			be a non-multipart message-body or a multipart message-body.
	3.4. Procedures		3.4. Procedures
	3.4.1. UA procedures		3.4.1. User Agent (UA) procedures
	A UA MAY include a Content-ID header field in any SIP message that is		A UA MAY include a Content-ID header field in any SIP message that 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
	that 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 value
	globally unique value.		that is unique in the context of the SIP message.
	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.
	skipping to change at page 8, line 14 ¶		skipping to change at page 10, line 14 ¶
	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
	within a body part (e.g., in an SDP attribute), points to a		within a body part (e.g., in an SDP attribute), points to a
	particular body part.		particular body part.
	NEW TEXT:		NEW TEXT:
	Content-ID URLs allow creating references to body parts or		Content-ID URLs allow the creation of references to body parts or
	message-bodies (and the header fields describing the		message-bodies (and the header fields describing the
	message-bodies). A given Content-ID URL [RFC2392], which can appear		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),		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		points to a particular body part or the message-body (and the
	header fields describing the message-body).		header fields describing the message-body).
	5. Security considerations		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.
	skipping to change at page 9, line 9 ¶		skipping to change at page 11, 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-06
			o Editorial changes and clarifications based on Gen-ART review from
			Elwyn Davies.
	Changes from draft-ietf-sipcore-content-id-05		Changes from draft-ietf-sipcore-content-id-05
	o Changes based on AD comments from Ben Campell:		o Changes based on AD comments from Ben Campell:
	o - Clarifying that Content-ID header field value is unique within		o - Clarifying that Content-ID header field value is unique within
	the scope of a SIP message.		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.
End of changes. 15 change blocks.
	34 lines changed or deleted		137 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/