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/ |