draft-ietf-sipcore-content-id-10.txt   rfc8262.txt 
SIPCORE Working Group C. Holmberg Internet Engineering Task Force (IETF) C. Holmberg
Internet-Draft I. Sedlacek Request for Comments: 8262 I. Sedlacek
Updates: 5621, 5368, 6442 (if approved) Ericsson Updates: 5368, 5621, 6442 Ericsson
Intended status: Standards Track September 2, 2017 Category: Standards Track October 2017
Expires: March 6, 2018 ISSN: 2070-1721
Content-ID header field in Session Initiation Protocol (SIP) Content-ID Header Field in the Session Initiation Protocol (SIP)
draft-ietf-sipcore-content-id-10
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). This document also updates RFC
5621, which only allows a Content-ID URL to reference a body part 5621, which only allows a Content-ID URL to reference a body part
that is part of a multipart message-body. This update enables a that is part of a multipart message-body. This update enables a
Content-ID URL to reference a complete message-body and metadata Content-ID URL to reference a complete message-body and metadata
provided by some additional SIP header fields. provided by some additional SIP header fields.
This document updates RFC 5368 and RFC 6442, by clarifying their This document updates RFC 5368 and RFC 6442 by clarifying their usage
usage of the SIP Content-ID header field. of the SIP Content-ID header field.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on March 6, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8262.
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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2 1.1. Identifying a Body Part . . . . . . . . . . . . . . . . . 3
1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3 1.2. Referencing a Body Part . . . . . . . . . . . . . . . . . 3
1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 1.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 4 1.4.1. Example 1: SIP INVITE . . . . . . . . . . . . . . . . 4
1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 5 1.4.2. Example 2: SIP REFER . . . . . . . . . . . . . . . . 6
1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. Backward compatibility . . . . . . . . . . . . . . . . . 7 1.6. Backward Compatibility . . . . . . . . . . . . . . . . . 7
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Content-ID header field . . . . . . . . . . . . . . . . . . . 7 3. Content-ID Header Field . . . . . . . . . . . . . . . . . . . 8
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. User Agent (UA) procedures . . . . . . . . . . . . . 8 3.4.1. User Agent (UA) Procedures . . . . . . . . . . . . . 9
3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 9 3.4.2. Proxy Procedures . . . . . . . . . . . . . . . . . . 9
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.3. Example: Referencing the Message-Body of a SIP
Message . . . . . . . . . . . . . . . . . . . . . . . 9
4. Update to RFC 5368 . . . . . . . . . . . . . . . . . . . . . 10 4. Update to RFC 5368 . . . . . . . . . . . . . . . . . . . . . 10
5. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 10 5. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 11
6. Update to RFC 6442 . . . . . . . . . . . . . . . . . . . . . 11 6. Update to RFC 6442 . . . . . . . . . . . . . . . . . . . . . 11
7. Security considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Header field . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 12
9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.1. Normative references . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
10.2. Informative references . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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
message-body as specified in [RFC3261]. message-body as specified in [RFC3261].
[RFC5621] defines generic handling of a multipart message-body in a [RFC5621] defines generic handling of a multipart message-body in a
SIP message. SIP message.
A multipart message-body contains zero, one or several body parts, A multipart message-body contains zero, one, or several body parts
encoded using [RFC2045] format. encoded using the format define in [RFC2045].
A body part in the multipart message-body is described using header A body part in the multipart message-body is described using header
fields such as Content-Disposition, Content-Encoding, and Content- fields such as Content-Disposition, Content-Encoding, and Content-
Type, which provide information on the content of the body part, as Type, which provide information on the content of the body part as
specified in [RFC5621]. A body part in the multipart message-body specified in [RFC5621]. A body part in the multipart message-body
can also contain a Content-ID header field with an ID value uniquely can also contain a Content-ID header field with an ID value uniquely
identifying the body part, as specified in [RFC2045]. identifying the body part as specified in [RFC2045].
1.2. Referencing a body part 1.2. Referencing a Body Part
A SIP header field can reference a body part using a Content-ID URL, A SIP header field can reference a body part using a Content-ID URL
as specified in [RFC5621]. as specified in [RFC5621].
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. 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 How to uniquely identify a complete message-body of a SIP message
message-body of a SIP message using a Content-ID header field, and using a Content-ID header field and how to reference a complete
how to reference a complete message-body using a Content-ID URL. message-body using a Content-ID URL are not currently specified.
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.
Some existing specifications, such as [RFC5368], contain examples Some existing specifications, such as [RFC5368], contain examples
that show usage of a SIP Content-ID header field referencing a that show usage of a SIP Content-ID header field referencing a
complete message-body, even though such usage has never been complete message-body, even though such usage has never been
specified. Many implementors have interpreted these examples to specified. Many implementors have interpreted these examples to
indicate that such usage is allowed by the corresponding indicate that such usage is allowed by the corresponding
specification, despite the absence of language allowing it. This specification, despite the absence of language allowing it. This
document updates the normative language in the affected documents to document updates the normative language in the affected documents to
explicitly allow such usage. explicitly allow such usage.
1.4. Consequences 1.4. Consequences
The examples below shows the consequences of the problem described The examples below show the consequences of the problem described
above. above.
1.4.1. Example 1 1.4.1. Example 1: SIP INVITE
If a User Agent Client (UAC) sends an INVITE request conveying If a User Agent Client (UAC) sends an INVITE request that conveys
location as specified in [RFC6442], if the UAC decides not to include location by value (as specified in [RFC6442]) and decides not to
an SDP offer, and if the location is conveyed by value, then the UAC include a Session Description Protocol (SDP) offer, then the UAC
needs to include only one MIME entity in the INVITE request. This needs to include only one MIME entity in the INVITE request. This
MIME entity can be, for example, of the application/pidf+xml MIME MIME entity can be, for example, of the 'application/pidf+xml' MIME
type. 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 a single body part in the
INVITE request, and includes the location information of application/ INVITE request, and includes the location information of
pidf+xml MIME type and an associated Content-ID header field in the 'application/pidf+xml' MIME type and an associated Content-ID header
body part. field in the body part.
Example message (SIP INVITE): Example message (SIP INVITE):
INVITE sips:bob@biloxi.example.com SIP/2.0 INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sips:bob@biloxi.example.com> To: Bob <sips:bob@biloxi.example.com>
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@atlanta.example.com Call-ID: 3848276298220188511@atlanta.example.com
Geolocation: <cid:target123@atlanta.example.com> Geolocation: <cid:target123@atlanta.example.com>
skipping to change at page 5, line 21 skipping to change at page 5, line 45
<dm:device id="target123-1"> <dm:device id="target123-1">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gml:location> <gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos> <gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point> </gml:Point>
</gml:location> </gml:location>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gbp:retransmission-allowed>false <gbp:retransmission-allowed>no
</gbp:retransmission-allowed> </gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z <gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry> </gbp:retention-expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>802.11</gp:method> <gp:method>802.11</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:deviceID>mac:1234567890ab</dm:deviceID> <dm:deviceID>mac:1234567890ab</dm:deviceID>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
--boundary1-- --boundary1--
1.4.2. Example 2 1.4.2. Example 2: SIP REFER
If a UAC sends an REFER request including a list of targets as If a UAC sends a 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
resource-lists+xml MIME type. 'application/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 a 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): Example message (SIP REFER):
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com;branch=z9hG4bKhjhs8ass83 Via: SIP/2.0/TCP client.chicago.example.com;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70 Max-Forwards: 70
To: "Conference 123" <sip:conf-123@example.com> To: "Conference 123" <sip:conf-123@example.com>
From: Carol <sip:carol@chicago.example.com>;tag=32331 From: Carol <sip:carol@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710 Call-ID: d432fa84b4c76e66710
skipping to change at page 6, line 47 skipping to change at page 7, line 22
<entry uri="sip:ted@example.net?method=BYE"/> <entry uri="sip:ted@example.net?method=BYE"/>
</list> </list>
</resource-lists> </resource-lists>
--boundary1-- --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.
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 the metadata
provided by some additional SIP header fields, of the SIP message; provided by some additional SIP header fields of the SIP message.
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 the metadata provided by some additional
header fields. SIP header fields.
o Updates [RFC5368] and [RFC6442] by adding explicit text saying
that a SIP Content-ID header field can be used.
1.6. Backward compatibility o Updates [RFC5368] and [RFC6442] by adding text that explicitly
states that a SIP Content-ID header field can be used.
1.6. Backward Compatibility
If an existing specification only defines the usage of a multipart If an existing specification only defines the usage of a multipart
message-body for carrying a single body part to be referenced by a message-body to carry a single body part to be referenced by a
Content-ID URL, implementations MUST NOT carry the MIME entity in a Content-ID URL, implementations MUST NOT carry the MIME entity in a
non-multipart message-body unless the specification is updated to non-multipart message-body unless the specification is updated to
explicitly allow it. explicitly allow it.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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], to disallow the use simplified, compared to the syntax in [RFC5322], to disallow the use
of comments and to adopt to the SIP usage of leading white space. 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 The value of the Content-ID header field value must be unique in the
context of a given SIP message, including any embedded MIME context of a given SIP message, including any embedded MIME
Content-Id header field values. Note that the SIP Content-ID header 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 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. 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.
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 that
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 Note: The message-body identified by the Content-ID header field can
be a non-multipart message-body or a multipart message-body. be a non-multipart message-body or a multipart message-body.
3.4. Procedures 3.4. Procedures
3.4.1. User Agent (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 value A UA MUST set the value of the Content-ID header field to a value
that is unique in the context of the SIP message. 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.
3.4.3. Example 3.4.3. Example: Referencing the Message-Body of a SIP Message
The figure shows an example from [RFC5368], where the SIP Content-ID The figure shows an example from [RFC5368], where the SIP Content-ID
header field is used to reference the message-body (non-multipart) of header field is used to reference the message-body (non-multipart) of
a SIP message. a SIP message.
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com Via: SIP/2.0/TCP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83 ;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70 Max-Forwards: 70
To: "Conference 123" <sip:conf-123@example.com> To: "Conference 123" <sip:conf-123@example.com>
skipping to change at page 10, line 7 skipping to change at page 10, line 16
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list> <list>
<entry uri="sip:bill@example.com?method=BYE" /> <entry uri="sip:bill@example.com?method=BYE" />
<entry uri="sip:joe@example.org?method=BYE" /> <entry uri="sip:joe@example.org?method=BYE" />
<entry uri="sip:ted@example.net?method=BYE" /> <entry uri="sip:ted@example.net?method=BYE" />
</list> </list>
</resource-lists> </resource-lists>
4. Update to RFC 5368 4. Update to RFC 5368
This section updates the second paragraph in section 7 of [RFC5368], This section updates the second paragraph in Section 7 of [RFC5368]
by allowing usage of either a MIME Content-ID header field or a SIP by allowing usage of either a MIME Content-ID header field or a SIP
Content-ID header field to label the body part or the message-body Content-ID header field to label the body part or the message-body
carrying the URI list. carrying the URI list.
OLD TEXT: OLD TEXT:
The Refer-To header field of a REFER request with multiple REFER- The Refer-To header field of a REFER request with multiple REFER-
Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource Targets MUST contain a pointer (i.e., a Content-ID Uniform
Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to
that carries the URI list. The REFER-Issuer SHOULD NOT include any the body part that carries the URI list. The REFER-Issuer SHOULD
particular URI more than once in the URI list. NOT include any particular URI more than once in the URI list.
NEW TEXT: NEW TEXT:
The Refer-To header field of a REFER request with multiple REFER- The Refer-To header field of a REFER request with multiple REFER-
Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource Targets MUST contain a pointer (i.e., a Content-ID Uniform
Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part Resource Locator (URL) as per RFC 2392 [RFC2392]) that points to
or message-body that carries the URI list. The REFER-Issuer SHOULD the body part or message-body that carries the URI list. The
NOT include any particular URI more than once in the URI list. The REFER-Issuer SHOULD NOT include any particular URI more than once
REFER request can use either a MIME Content-ID header field [RFC4483] in the URI list. The REFER request can use either a MIME Content-
or a SIP Content-ID header field [RFCXXXX] to label the body part or ID header field [RFC4483] or a SIP Content-ID header field
the message-body. [RFC8262] to label the body part or the message-body.
5. Update to RFC 5621 5. 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
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 the creation of 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-
message-bodies). A given Content-ID URL [RFC2392], which can appear bodies). A given Content-ID URL [RFC2392], which can appear in a
in a header field or within a body part (e.g., in an SDP attribute), 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).
6. Update to RFC 6442 6. Update to RFC 6442
This section updates the second paragraph in section 3.1 of This section updates the second paragraph in Section 3.1 of [RFC6442]
[RFC6442], by allowing usage of either a MIME Content-ID header field by allowing usage of either a MIME Content-ID header field or a SIP
or a SIP Content-ID header field to label the body part or the Content-ID header field to label the body part or the message-body
message-body carrying the location data. carrying the location data.
OLD TEXT: OLD TEXT:
In Figure 1, Alice is both the Target and the LS that is conveying In Figure 1, Alice is both the Target and the LS that is conveying
her location directly to Bob, who acts as an LR. This conveyance is her location directly to Bob, who acts as an LR. This conveyance
point-to-point: it does not pass through any SIP-layer intermediary. is point-to-point: it does not pass through any SIP-layer
A Location Object appears by-value in the initial SIP request as a intermediary. A Location Object appears by-value in the initial
MIME body, and Bob responds to that SIP request as appropriate. SIP request as a MIME body, and Bob responds to that SIP request
There is a 'Bad Location Information' response code introduced within as appropriate. There is a 'Bad Location Information' response
this document to specifically inform Alice if she conveys bad code introduced within this document to specifically inform Alice
location to Bob (e.g., Bob "cannot parse the location provided", or if she conveys bad location information to Bob (e.g., Bob "cannot
"there is not enough location information to determine where Alice parse the location provided", or "there is not enough location
is"). information to determine where Alice is").
NEW TEXT: NEW TEXT:
In Figure 1, Alice is both the Target and the LS that is conveying In Figure 1, Alice is both the Target and the LS that is conveying
her location directly to Bob, who acts as an LR. This conveyance is her location directly to Bob, who acts as an LR. This conveyance
point-to-point: it does not pass through any SIP-layer intermediary. is point-to-point: it does not pass through any SIP-layer
A Location Object appears by-value in the initial SIP request as a intermediary. A Location Object appears by-value in the initial
MIME body, and Bob responds to that SIP request as appropriate. SIP request as a MIME body, and Bob responds to that SIP request
Either a MIME Content-ID header field [RFC4483] or the SIP Content-ID as appropriate. Either a MIME Content-ID header field [RFC4483]
header field [RFCXXXX] MUST be used to label the location or the SIP Content-ID header field [RFC8262] MUST be used to label
information. There is a 'Bad Location Information' response code the location information. There is a 'Bad Location Information'
introduced within this document to specifically inform Alice if she response code introduced within this document to specifically
conveys bad location to Bob (e.g., Bob "cannot parse the location inform Alice if she conveys bad location information to Bob (e.g.,
provided", or "there is not enough location information to determine Bob "cannot parse the location provided", or "there is not enough
where Alice is"). location information to determine where Alice is").
7. Security considerations 7. 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 is an If the message-body associated with the Content-ID header field is an
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.
8. IANA considerations 8. 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 defined in [RFC3261].
8.1. Header field 8.1. Header Field
The header field described in Section 3 has been registered in the The header field described in Section 3 has been registered in the
"Header Fields" sub-registry of the "Session Initiation Protocol "Header Fields" sub-registry of the "Session Initiation Protocol
(SIP) Parameters" registry by adding a row with these values: (SIP) Parameters" registry by adding a row with these values:
[RFC EDITOR NOTE: Please replace XXXX with the RFC number of this Header Name: Content-ID
document when publishing]
Header Name: Content-ID
compact: compact:
Reference: RFCXXXX Reference: RFC 8262
9. Change log
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-sipcore-content-id-09
o Editorial change based on comment from Adam Roach.
Changes from draft-ietf-sipcore-content-id-08
o Editorial change based on comment from Ben Campbell.
Changes from draft-ietf-sipcore-content-id-07
o Updates to affected RFCs.
o Editorial changes and clarifications based on IESG review.
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
o Changes based on AD comments from Ben Campbell:
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
o Minor editorial fix.
Changes from draft-ietf-sipcore-content-id-03
o Changes based on doc shepherd review:
o - Reference to RFC 5234 added.
o - SIP message example added.
o - Editorial changes.
Changes from draft-ietf-sipcore-content-id-02
o Editorial changes based on comments from Paul Kyzivat.
Changes from draft-ietf-sipcore-content-id-01
o Update to RFC 5621 added.
o Editorial changes.
10. References 9. References
10.1. Normative references 9.1. 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,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://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,
<https://www.rfc-editor.org/info/rfc2392>. <https://www.rfc-editor.org/info/rfc2392>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC4483] Burger, E., Ed., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483,
DOI 10.17487/RFC4483, May 2006,
<https://www.rfc-editor.org/info/rfc4483>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- DOI 10.17487/RFC5234, January 2008,
editor.org/info/rfc5234>. <https://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, <https://www.rfc- DOI 10.17487/RFC5322, October 2008,
editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>.
[RFC5621] Camarillo, G., "Message Body Handling in the Session [RFC5621] Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", RFC 5621, Initiation Protocol (SIP)", RFC 5621,
DOI 10.17487/RFC5621, September 2009, <https://www.rfc- DOI 10.17487/RFC5621, September 2009,
editor.org/info/rfc5621>. <https://www.rfc-editor.org/info/rfc5621>.
10.2. Informative references [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M.,
and H. Khartabil, "Referring to Multiple Resources in the and H. Khartabil, "Referring to Multiple Resources in the
Session Initiation Protocol (SIP)", RFC 5368, Session Initiation Protocol (SIP)", RFC 5368,
DOI 10.17487/RFC5368, October 2008, <https://www.rfc- DOI 10.17487/RFC5368, October 2008,
editor.org/info/rfc5368>. <https://www.rfc-editor.org/info/rfc5368>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442, for the Session Initiation Protocol", RFC 6442,
DOI 10.17487/RFC6442, December 2011, <https://www.rfc- DOI 10.17487/RFC6442, December 2011,
editor.org/info/rfc6442>. <https://www.rfc-editor.org/info/rfc6442>.
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 88 change blocks. 
243 lines changed or deleted 203 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/