draft-ietf-sipcore-content-id-05.txt | draft-ietf-sipcore-content-id-06.txt | |||
---|---|---|---|---|
SIPCORE Working Group C. Holmberg | SIPCORE Working Group C. Holmberg | |||
Internet-Draft I. Sedlacek | Internet-Draft I. Sedlacek | |||
Updates: 5621 (if approved) Ericsson | Updates: 5621 (if approved) Ericsson | |||
Intended status: Standards Track May 9, 2017 | Intended status: Standards Track June 5, 2017 | |||
Expires: November 10, 2017 | Expires: December 7, 2017 | |||
Content-ID header field in Session Initiation Protocol (SIP) | Content-ID header field in Session Initiation Protocol (SIP) | |||
draft-ietf-sipcore-content-id-05 | draft-ietf-sipcore-content-id-06 | |||
Abstract | Abstract | |||
This document specifies the Content-ID header field for usage in the | This document specifies the Content-ID header field for usage in the | |||
Session Initiation Protocol (SIP). The document also updates RFC | Session Initiation Protocol (SIP). The document also updates RFC | |||
5621, to enable a Content-ID URL to reference a complete message-body | 5621, to enable a Content-ID URL to reference a complete message-body | |||
and metadata provided by some additional SIP header fields. | and metadata provided by some additional SIP header fields. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 34 ¶ | skipping to change at page 1, line 34 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on November 10, 2017. | This Internet-Draft will expire on December 7, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 23 ¶ | skipping to change at page 2, line 23 ¶ | |||
1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4 | 1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Content-ID header field . . . . . . . . . . . . . . . . . . . 4 | 3. Content-ID header field . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5 | 3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6 | 3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6 | |||
4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 6 | 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. Security considerations . . . . . . . . . . . . . . . . . . . 6 | 4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 7 | |||
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 | |||
6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 7 | 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Normative references . . . . . . . . . . . . . . . . . . . . 7 | 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | 8. Normative references . . . . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
1. Introduction | 1. Introduction | |||
1.1. Identifying a body part | 1.1. Identifying a body part | |||
A SIP message consists of a start-line, one or more header fields, an | A SIP message consists of a start-line, one or more header fields, an | |||
empty line indicating the end of the header fields, and an optional | empty line indicating the end of the header fields, and an optional | |||
message-body, as specified in [RFC3261]. | message-body, as specified in [RFC3261]. | |||
The message-body can be a non-multipart message-body or a multipart | The message-body can be a non-multipart message-body or a multipart | |||
skipping to change at page 3, line 31 ¶ | skipping to change at page 3, line 31 ¶ | |||
body part using a Content-ID URL, for providing location. | body part using a Content-ID URL, for providing location. | |||
o [RFC5368] specifies how a Refer-To header field references a body | o [RFC5368] specifies how a Refer-To header field references a body | |||
part using a Content-ID URL, to provide a list of targets. | part using a Content-ID URL, to provide a list of targets. | |||
1.3. Problem statement | 1.3. Problem statement | |||
It is currently not specified how to uniquely identify a complete | It is currently not specified how to uniquely identify a complete | |||
message-body of a SIP message using a Content-ID header field, and | message-body of a SIP message using a Content-ID header field, and | |||
how to reference a complete message-body using a Content-ID URL. | how to reference a complete message-body using a Content-ID URL. | |||
NOTE: In [RFC5621], the Content-ID URL references a specific body | ||||
part only. | ||||
1.4. Consequences | 1.4. Consequences | |||
The examples below shows the consequences of the problem described | The examples below shows the consequences of the problem described | |||
above. | above. | |||
1.4.1. Example 1 | 1.4.1. Example 1 | |||
If a UAC sends an INVITE request conveying location as specified in | If a UAC sends an INVITE request conveying location as specified in | |||
[RFC6442], if the UAC decides not to include an SDP offer, and if the | [RFC6442], if the UAC decides not to include an SDP offer, and if the | |||
location is conveyed by value, then the UAC needs to include only one | location is conveyed by value, then the UAC needs to include only one | |||
skipping to change at page 4, line 33 ¶ | skipping to change at page 4, line 35 ¶ | |||
o Specifies and registers the Content-ID header field as a SIP | o Specifies and registers the Content-ID header field as a SIP | |||
header field; and | header field; and | |||
o Specifies that, when used as a SIP header field, the Content-ID | o Specifies that, when used as a SIP header field, the Content-ID | |||
header field identifies the complete message-body, and metadata | header field identifies the complete message-body, and metadata | |||
provided by some additional SIP header fields, of the SIP message; | provided by some additional SIP header fields, of the SIP message; | |||
and | and | |||
o Updates [RFC5621], to enable a Content-ID URL to reference a | o Updates [RFC5621], to enable a Content-ID URL to reference a | |||
complete message-body and metadata provided by some additional SIP | complete message-body and metadata provided by some additional SIP | |||
header fields. | header fields. | |||
NOTE: In [RFC5621], the Content-ID URL references a specific body | ||||
part only. | ||||
2. Conventions | 2. Conventions | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
3. Content-ID header field | 3. Content-ID header field | |||
3.1. Introduction | 3.1. Introduction | |||
This section defines the usage of the Content-ID header field for | This section defines the usage of the Content-ID header field for | |||
SIP. | SIP. | |||
3.2. Syntax | 3.2. Syntax | |||
The ABNF [RFC5234] for the Content-ID header field is: | The ABNF [RFC5234] for the Content-ID header field is: | |||
Content-ID = "Content-ID" HCOLON msg-id | Content-ID = "Content-ID" HCOLON msg-id | |||
msg-id = "<" id-left "@" id-right ">" | msg-id = "<" id-left "@" id-right ">" | |||
NOTE: id-left and id-right are specified in [RFC5322]. HCOLON is | NOTE: id-left and id-right are specified in [RFC5322]. HCOLON is | |||
defined in [RFC3261]. | defined in [RFC3261]. | |||
NOTE: When used in a SIP header field, the msg-id syntax has been | NOTE: When used in a SIP header field, the msg-id syntax has been | |||
simplified compared to the syntax in [RFC5322]. | simplified, compared to the syntax in [RFC5322], to disallow the use | |||
of comments and to adopt to the SIP usage of leading white space. | ||||
The value of Content-Id header field value must be unique in the | ||||
context of a given SIP message, including any embedded MIME | ||||
Content-Id header field values. Note that the SIP Content-ID header | ||||
field value is not expected to be unique among all SIP messages; it | ||||
has no meaning outside of the message in which it is included. | ||||
3.3. Semantics | 3.3. Semantics | |||
The Content-ID header field included in the header fields of a SIP | The Content-ID header field included in the header fields of a SIP | |||
message identifies the message-body of the SIP message, and the | message identifies the message-body of the SIP message, and the | |||
metadata provided by: | metadata provided by: | |||
o a MIME-Version header field, if included in the header fields of | o a MIME-Version header field, if included in the header fields of | |||
the SIP message; and | the SIP message; and | |||
o any 'Content-' prefixed header fields (including the Content-ID | o any 'Content-' prefixed header fields (including the Content-ID | |||
skipping to change at page 6, line 14 ¶ | skipping to change at page 6, line 17 ¶ | |||
3.4.2. Proxy procedures | 3.4.2. Proxy procedures | |||
A proxy MUST NOT add a Content-ID header field in a SIP message. | A proxy MUST NOT add a Content-ID header field in a SIP message. | |||
A proxy MUST NOT modify a Content-ID header field included in a SIP | A proxy MUST NOT modify a Content-ID header field included in a SIP | |||
message. | message. | |||
A proxy MUST NOT delete a Content-ID header field from a SIP message. | A proxy MUST NOT delete a Content-ID header field from a SIP message. | |||
3.4.3. Example | ||||
The figure shows an example from [RFC5368], where the SIP Content-ID | ||||
header field is used to reference the message body (non-multipart) of | ||||
a SIP message. | ||||
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 | ||||
Via: SIP/2.0/TCP client.chicago.example.com | ||||
;branch=z9hG4bKhjhs8ass83 | ||||
Max-Forwards: 70 | ||||
To: "Conference 123" <sip:conf-123@example.com> | ||||
From: Carol <sip:carol@chicago.example.com>;tag=32331 | ||||
Call-ID: d432fa84b4c76e66710 | ||||
CSeq: 2 REFER | ||||
Contact: <sip:carol@client.chicago.example.com> | ||||
Refer-To: <cid:cn35t8jf02@example.com> | ||||
Refer-Sub: false | ||||
Require: multiple-refer, norefersub | ||||
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY | ||||
Allow-Events: dialog | ||||
Accept: application/sdp, message/sipfrag | ||||
Content-Type: application/resource-lists+xml | ||||
Content-Disposition: recipient-list | ||||
Content-Length: 362 | ||||
Content-ID: <cn35t8jf02@example.com> | ||||
<?xml version="1.0" encoding="UTF-8"?> | ||||
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" | ||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> | ||||
<list> | ||||
<entry uri="sip:bill@example.com?method=BYE" /> | ||||
<entry uri="sip:joe@example.org?method=BYE" /> | ||||
<entry uri="sip:ted@example.net?method=BYE" /> | ||||
</list> | ||||
</resource-lists> | ||||
4. Update to RFC 5621 | 4. Update to RFC 5621 | |||
This section updates section 9.1 of [RFC5621], by allowing a Content- | This section updates section 9.1 of [RFC5621], by allowing a Content- | |||
ID URL to reference a message-body and the related metadata | ID URL to reference a message-body and the related metadata | |||
(Section 3.3), in addition to allowing a reference to a body part. | (Section 3.3), in addition to allowing a reference to a body part. | |||
OLD TEXT: | OLD TEXT: | |||
Content-ID URLs allow creating references to body parts. A given | Content-ID URLs allow creating references to body parts. A given | |||
Content-ID URL [RFC2392], which can appear in a header field or | Content-ID URL [RFC2392], which can appear in a header field or | |||
skipping to change at page 7, line 24 ¶ | skipping to change at page 9, line 9 ¶ | |||
Header Name: Content-ID | Header Name: Content-ID | |||
compact: | compact: | |||
Reference: RFCXXXX | Reference: RFCXXXX | |||
7. Change log | 7. Change log | |||
[RFC EDITOR NOTE: Please remove this section when publishing] | [RFC EDITOR NOTE: Please remove this section when publishing] | |||
Changes from draft-ietf-sipcore-content-id-05 | ||||
o Changes based on AD comments from Ben Campell: | ||||
o - Clarifying that Content-ID header field value is unique within | ||||
the scope of a SIP message. | ||||
Changes from draft-ietf-sipcore-content-id-04 | Changes from draft-ietf-sipcore-content-id-04 | |||
o Minor editorial fix. | o Minor editorial fix. | |||
Changes from draft-ietf-sipcore-content-id-03 | Changes from draft-ietf-sipcore-content-id-03 | |||
o Changes based on doc shepard review: | o Changes based on doc shepard review: | |||
o - Reference to RFC 5234 added. | o - Reference to RFC 5234 added. | |||
o - SIP message example added. | ||||
o - Editorial changes. | o - Editorial changes. | |||
Changes from draft-ietf-sipcore-content-id-02 | Changes from draft-ietf-sipcore-content-id-02 | |||
o Editorial changes based on comments from Paul Kyzivat. | o Editorial changes based on comments from Paul Kyzivat. | |||
Changes from draft-ietf-sipcore-content-id-01 | Changes from draft-ietf-sipcore-content-id-01 | |||
o Update to RFC 5621 added. | o Update to RFC 5621 added. | |||
o Editorial changes. | o Editorial changes. | |||
End of changes. 13 change blocks. | ||||
20 lines changed or deleted | 71 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |