draft-ietf-sipcore-content-id-06.txt | draft-ietf-sipcore-content-id-07.txt | |||
---|---|---|---|---|
SIPCORE Working Group C. Holmberg | SIPCORE Working Group C. Holmberg | |||
Internet-Draft I. Sedlacek | Internet-Draft I. Sedlacek | |||
Updates: 5621 (if approved) Ericsson | Updates: 5621 (if approved) Ericsson | |||
Intended status: Standards Track June 5, 2017 | Intended status: Standards Track June 28, 2017 | |||
Expires: December 7, 2017 | Expires: December 30, 2017 | |||
Content-ID header field in Session Initiation Protocol (SIP) | Content-ID header field in Session Initiation Protocol (SIP) | |||
draft-ietf-sipcore-content-id-06 | draft-ietf-sipcore-content-id-07 | |||
Abstract | Abstract | |||
This document specifies the Content-ID header field for usage in the | This document specifies the Content-ID header field for usage in the | |||
Session Initiation Protocol (SIP). The document also updates RFC | Session Initiation Protocol (SIP). The document also updates RFC | |||
5621, to enable a Content-ID URL to reference a complete message-body | 5621, which only allows a Content-ID URL to reference a body-part | |||
and metadata provided by some additional SIP header fields. | that is part of a multipart message-body. This update enables a | |||
Content-ID URL to reference a complete message-body and metadata | ||||
provided by some additional SIP header fields. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on December 7, 2017. | This Internet-Draft will expire on December 30, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 13 ¶ | skipping to change at page 2, line 15 ¶ | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2 | 1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2 | |||
1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3 | 1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3 | |||
1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 | 1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 | |||
1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 3 | 1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3 | 1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4 | 1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3. Content-ID header field . . . . . . . . . . . . . . . . . . . 4 | 3. Content-ID header field . . . . . . . . . . . . . . . . . . . 7 | |||
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5 | 3.4.1. User Agent (UA) procedures . . . . . . . . . . . . . 8 | |||
3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6 | 3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 8 | |||
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 7 | 4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 9 | |||
5. Security considerations . . . . . . . . . . . . . . . . . . . 8 | 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 | |||
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 | 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 8 | 6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 10 | |||
7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
8. Normative references . . . . . . . . . . . . . . . . . . . . 9 | 8. Normative references . . . . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1. Introduction | 1. Introduction | |||
1.1. Identifying a body part | 1.1. Identifying a body part | |||
A SIP message consists of a start-line, one or more header fields, an | A SIP message consists of a start-line, one or more header fields, an | |||
empty line indicating the end of the header fields, and an optional | empty line indicating the end of the header fields, and an optional | |||
message-body, as specified in [RFC3261]. | message-body, as specified in [RFC3261]. | |||
The message-body can be a non-multipart message-body or a multipart | The message-body can be a non-multipart message-body or a multipart | |||
skipping to change at page 3, line 21 ¶ | skipping to change at page 3, line 26 ¶ | |||
The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies | The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies | |||
how to identify the body part referenced by a Content-ID URL. The | how to identify the body part referenced by a Content-ID URL. The | |||
Content-ID URL value is included in the Content-ID header field of | Content-ID URL value is included in the Content-ID header field of | |||
the body part. | the body part. | |||
Examples of SIP header fields referencing a body part using a | Examples of SIP header fields referencing a body part using a | |||
Content-ID URL are: | Content-ID URL are: | |||
o [RFC6442] specifies how a Geolocation header field references a | o [RFC6442] specifies how a Geolocation header field references a | |||
body part using a Content-ID URL, for providing location. | body part using a Content-ID URL, for providing location | |||
information. | ||||
o [RFC5368] specifies how a Refer-To header field references a body | o [RFC5368] specifies how a Refer-To header field references a body | |||
part using a Content-ID URL, to provide a list of targets. | part using a Content-ID URL, to provide a list of targets. | |||
1.3. Problem statement | 1.3. Problem statement | |||
It is currently not specified how to uniquely identify a complete | It is currently not specified how to uniquely identify a complete | |||
message-body of a SIP message using a Content-ID header field, and | message-body of a SIP message using a Content-ID header field, and | |||
how to reference a complete message-body using a Content-ID URL. | how to reference a complete message-body using a Content-ID URL. | |||
NOTE: In [RFC5621], the Content-ID URL references a specific body | NOTE: In [RFC5621], the Content-ID URL references a specific body | |||
part only. | part only. | |||
1.4. Consequences | 1.4. Consequences | |||
The examples below shows the consequences of the problem described | The examples below shows the consequences of the problem described | |||
above. | above. | |||
1.4.1. Example 1 | 1.4.1. Example 1 | |||
If a UAC sends an INVITE request conveying location as specified in | If a User Agent Client (UAC) sends an INVITE request conveying | |||
[RFC6442], if the UAC decides not to include an SDP offer, and if the | location as specified in [RFC6442], if the UAC decides not to include | |||
location is conveyed by value, then the UAC needs to include only one | an SDP offer, and if the location is conveyed by value, then the UAC | |||
MIME entity in the INVITE request. This MIME entity can be e.g. of | needs to include only one MIME entity in the INVITE request. This | |||
the application/pidf+xml MIME type. | MIME entity can be, for example, of the application/pidf+xml MIME | |||
type. | ||||
However, due to [RFC6442] requiring inclusion of a Geolocation header | However, due to [RFC6442] requiring inclusion of a Geolocation header | |||
field referencing the body part with the location information, the | field referencing the body part with the location information, the | |||
UAC includes a multipart message-body with single body part in the | UAC includes a multipart message-body with single body part in the | |||
INVITE request, and includes the location information of application/ | INVITE request, and includes the location information of application/ | |||
pidf+xml MIME type and an associated Content-ID header field in the | pidf+xml MIME type and an associated Content-ID header field in the | |||
body part. | body part. | |||
Example message (SIP INVITE): | ||||
INVITE sips:bob@biloxi.example.com SIP/2.0 | ||||
Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 | ||||
Max-Forwards: 70 | ||||
To: Bob <sips:bob@biloxi.example.com> | ||||
From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl | ||||
Call-ID: 3848276298220188511@atlanta.example.com | ||||
Geolocation: <cid:target123@atlanta.example.com> | ||||
Geolocation-Routing: no | ||||
Accept: application/sdp, application/pidf+xml | ||||
CSeq: 31862 INVITE | ||||
Contact: <sips:alice@atlanta.example.com> | ||||
Content-Type: multipart/mixed; boundary=boundary1 | ||||
Content-Length: ... | ||||
--boundary1 | ||||
Content-Type: application/pidf+xml | ||||
Content-ID: <target123@atlanta.example.com> | ||||
<?xml version="1.0" encoding="UTF-8"?> | ||||
<presence | ||||
xmlns="urn:ietf:params:xml:ns:pidf" | ||||
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" | ||||
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" | ||||
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" | ||||
xmlns:gml="http://www.opengis.net/gml" | ||||
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" | ||||
entity="pres:alice@atlanta.example.com" | ||||
> | ||||
<dm:device id="target123-1"> | ||||
<gp:geopriv> | ||||
<gp:location-info> | ||||
<gml:location> | ||||
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> | ||||
<gml:pos>32.86726 -97.16054</gml:pos> | ||||
</gml:Point> | ||||
</gml:location> | ||||
</gp:location-info> | ||||
<gp:usage-rules> | ||||
<gbp:retransmission-allowed>false | ||||
</gbp:retransmission-allowed> | ||||
<gbp:retention-expiry>2010-11-14T20:00:00Z | ||||
</gbp:retention-expiry> | ||||
</gp:usage-rules> | ||||
<gp:method>802.11</gp:method> | ||||
</gp:geopriv> | ||||
<dm:deviceID>mac:1234567890ab</dm:deviceID> | ||||
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> | ||||
</dm:device> | ||||
</presence> | ||||
--boundary1-- | ||||
1.4.2. Example 2 | 1.4.2. Example 2 | |||
If a UAC sends an REFER request including a list of targets as | If a UAC sends an REFER request including a list of targets as | |||
specified in [RFC5368], then the UAC needs to include only one MIME | specified in [RFC5368], then the UAC needs to include only one MIME | |||
entity in the REFER request. This MIME entity is of the application/ | entity in the REFER request. This MIME entity is of the application/ | |||
resource-lists+xml MIME type. | resource-lists+xml MIME type. | |||
However, due to [RFC5368] requiring inclusion of a Refer-To header | However, due to [RFC5368] requiring inclusion of a Refer-To header | |||
field referencing the body part containing the list of targets, the | field referencing the body part containing the list of targets, the | |||
UAC includes a multipart message-body with single body part in the | UAC includes a multipart message-body with single body part in the | |||
REFER request, and includes the list of targets of application/ | REFER request, and includes the list of targets of application/ | |||
resource-lists+xml MIME type and an associated Content-ID header | resource-lists+xml MIME type and an associated Content-ID header | |||
field in the body part. | field in the body part. | |||
Example message (SIP REFER): | ||||
REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 | ||||
Via: SIP/2.0/TCP client.chicago.example.com;branch=z9hG4bKhjhs8ass83 | ||||
Max-Forwards: 70 | ||||
To: "Conference 123" <sip:conf-123@example.com> | ||||
From: Carol <sip:carol@chicago.example.com>;tag=32331 | ||||
Call-ID: d432fa84b4c76e66710 | ||||
CSeq: 2 REFER | ||||
Contact: <sip:carol@client.chicago.example.com> | ||||
Refer-To: <cid:cn35t8jf02@example.com> | ||||
Refer-Sub: false | ||||
Require: multiple-refer, norefersub | ||||
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY | ||||
Allow-Events: dialog | ||||
Accept: application/sdp, message/sipfrag | ||||
Content-Type: multipart/mixed; boundary=boundary1 | ||||
Content-Length: ... | ||||
--boundary1 | ||||
Content-Type: application/resource-lists+xml | ||||
Content-Disposition: recipient-list | ||||
Content-ID: <cn35t8jf02@example.com> | ||||
<?xml version="1.0" encoding="UTF-8"?> | ||||
<resource-lists | ||||
xmlns="urn:ietf:params:xml:ns:resource-lists" | ||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | ||||
> | ||||
<list> | ||||
<entry uri="sip:bill@example.com?method=BYE"/> | ||||
<entry uri="sip:joe@example.org?method=BYE"/> | ||||
<entry uri="sip:ted@example.net?method=BYE"/> | ||||
</list> | ||||
</resource-lists> | ||||
--boundary1-- | ||||
1.5. Solution | 1.5. Solution | |||
In order to solve the problems described above, this document: | In order to solve the problems described above, this document: | |||
o Specifies and registers the Content-ID header field as a SIP | o Specifies and registers the Content-ID header field as a SIP | |||
header field; and | header field; and | |||
o Specifies that, when used as a SIP header field, the Content-ID | o Specifies that, when used as a SIP header field, the Content-ID | |||
header field identifies the complete message-body, and metadata | header field identifies the complete message-body, and metadata | |||
provided by some additional SIP header fields, of the SIP message; | provided by some additional SIP header fields, of the SIP message; | |||
and | and | |||
skipping to change at page 5, line 34 ¶ | skipping to change at page 8, line 4 ¶ | |||
has no meaning outside of the message in which it is included. | has no meaning outside of the message in which it is included. | |||
3.3. Semantics | 3.3. Semantics | |||
The Content-ID header field included in the header fields of a SIP | The Content-ID header field included in the header fields of a SIP | |||
message identifies the message-body of the SIP message, and the | message identifies the message-body of the SIP message, and the | |||
metadata provided by: | metadata provided by: | |||
o a MIME-Version header field, if included in the header fields of | o a MIME-Version header field, if included in the header fields of | |||
the SIP message; and | the SIP message; and | |||
o any 'Content-' prefixed header fields (including the Content-ID | o any 'Content-' prefixed header fields (including the Content-ID | |||
header field itself) included in the header fields of the SIP | header field itself) included in the header fields of the SIP | |||
message. | message. | |||
The Content-ID header field can be included in any SIP message which | The Content-ID header field can be included in any SIP message which | |||
is allowed to contain a message-body. | is allowed to contain a message-body. | |||
NOTE: The message body identified by the Content-ID header field can | ||||
be a non-multipart message-body or a multipart message-body. | ||||
3.4. Procedures | 3.4. Procedures | |||
3.4.1. UA procedures | 3.4.1. User Agent (UA) procedures | |||
A UA MAY include a Content-ID header field in any SIP message that is | A UA MAY include a Content-ID header field in any SIP message that is | |||
allowed to contain a message-body. | allowed to contain a message-body. | |||
A UA MUST NOT include a Content-ID header field in any SIP message | A UA MUST NOT include a Content-ID header field in any SIP message | |||
that is not allowed to contain a message-body. | that is not allowed to contain a message-body. | |||
The UA MUST set the value of the Content-ID header field to a | The UA MUST set the value of the Content-ID header field to a value | |||
globally unique value. | that is unique in the context of the SIP message. | |||
3.4.2. Proxy procedures | 3.4.2. Proxy procedures | |||
A proxy MUST NOT add a Content-ID header field in a SIP message. | A proxy MUST NOT add a Content-ID header field in a SIP message. | |||
A proxy MUST NOT modify a Content-ID header field included in a SIP | A proxy MUST NOT modify a Content-ID header field included in a SIP | |||
message. | message. | |||
A proxy MUST NOT delete a Content-ID header field from a SIP message. | A proxy MUST NOT delete a Content-ID header field from a SIP message. | |||
skipping to change at page 8, line 14 ¶ | skipping to change at page 10, line 14 ¶ | |||
OLD TEXT: | OLD TEXT: | |||
Content-ID URLs allow creating references to body parts. A given | Content-ID URLs allow creating references to body parts. A given | |||
Content-ID URL [RFC2392], which can appear in a header field or | Content-ID URL [RFC2392], which can appear in a header field or | |||
within a body part (e.g., in an SDP attribute), points to a | within a body part (e.g., in an SDP attribute), points to a | |||
particular body part. | particular body part. | |||
NEW TEXT: | NEW TEXT: | |||
Content-ID URLs allow creating references to body parts or | Content-ID URLs allow the creation of references to body parts or | |||
message-bodies (and the header fields describing the | message-bodies (and the header fields describing the | |||
message-bodies). A given Content-ID URL [RFC2392], which can appear | message-bodies). A given Content-ID URL [RFC2392], which can appear | |||
in a header field or within a body part (e.g., in an SDP attribute), | in a header field or within a body part (e.g., in an SDP attribute), | |||
points to a particular body part or the message-body (and the | points to a particular body part or the message-body (and the | |||
header fields describing the message-body). | header fields describing the message-body). | |||
5. Security considerations | 5. Security considerations | |||
The Content-ID header field value MUST NOT reveal sensitive user | The Content-ID header field value MUST NOT reveal sensitive user | |||
information. | information. | |||
skipping to change at page 9, line 9 ¶ | skipping to change at page 11, line 9 ¶ | |||
Header Name: Content-ID | Header Name: Content-ID | |||
compact: | compact: | |||
Reference: RFCXXXX | Reference: RFCXXXX | |||
7. Change log | 7. Change log | |||
[RFC EDITOR NOTE: Please remove this section when publishing] | [RFC EDITOR NOTE: Please remove this section when publishing] | |||
Changes from draft-ietf-sipcore-content-id-06 | ||||
o Editorial changes and clarifications based on Gen-ART review from | ||||
Elwyn Davies. | ||||
Changes from draft-ietf-sipcore-content-id-05 | Changes from draft-ietf-sipcore-content-id-05 | |||
o Changes based on AD comments from Ben Campell: | o Changes based on AD comments from Ben Campell: | |||
o - Clarifying that Content-ID header field value is unique within | o - Clarifying that Content-ID header field value is unique within | |||
the scope of a SIP message. | the scope of a SIP message. | |||
Changes from draft-ietf-sipcore-content-id-04 | Changes from draft-ietf-sipcore-content-id-04 | |||
o Minor editorial fix. | o Minor editorial fix. | |||
End of changes. 15 change blocks. | ||||
34 lines changed or deleted | 137 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |