draft-ietf-sipcore-content-id-01.txt | draft-ietf-sipcore-content-id-02.txt | |||
---|---|---|---|---|
SIPCORE Working Group C. Holmberg | SIPCORE Working Group C. Holmberg | |||
Internet-Draft I. Sedlacek | Internet-Draft I. Sedlacek | |||
Intended status: Standards Track Ericsson | Updates: 5621 (if approved) Ericsson | |||
Expires: September 9, 2017 March 8, 2017 | Intended status: Standards Track April 25, 2017 | |||
Expires: October 27, 2017 | ||||
Content ID header field in Session Initiation Protocol (SIP) | Content-ID header field in Session Initiation Protocol (SIP) | |||
draft-ietf-sipcore-content-id-01 | draft-ietf-sipcore-content-id-02 | |||
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). | Session Initiation Protocol (SIP). The document also updates RFC | |||
5621, to enable a Content-ID URL to refer 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 September 9, 2017. | This Internet-Draft will expire on October 27, 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 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Setting up ID value uniquely identifying body . . . . . . 2 | 1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2 | |||
1.2. Referencing the ID value uniquely identifying body . . . 3 | 1.2. Referring a body part . . . . . . . . . . . . . . . . . . 3 | |||
1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 | 1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 | |||
1.4. Examples of the problem . . . . . . . . . . . . . . . . . 3 | 1.4. Consequencies . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3 | 1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4 | 1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Content-ID header field . . . . . . . . . . . . . . . . . . . 5 | 3. Content-ID header field . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.3. Semantic . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 6 | 3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5 | |||
3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6 | 3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 | |||
5.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 6 | 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 7 | |||
7. Normative References . . . . . . . . . . . . . . . . . . . . 7 | 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
8. Normative references . . . . . . . . . . . . . . . . . . . . 7 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
1. Introduction | 1. Introduction | |||
1.1. Setting up ID value uniquely identifying body | 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]. | |||
A message-body of the SIP message can contain one body only or can | The message-body can be a non-multipart message-body or a multipart | |||
contain several body parts, as specified in [RFC3261] and [RFC5621]. | message-body as specified in [RFC3261]. | |||
A body part encoded using [RFC2045] can contain a Content-ID header | [RFC5621] defines generic handling of a multipart message-body in a | |||
field with an ID value uniquely identifying the body part, as | SIP message. | |||
specified in [RFC2045]. | ||||
However, when the message-body of the SIP message contains one body | A multipart message-body contains zero, one or several body parts, | |||
only, there is no body part specified. Thus, there is also no | encoded using [RFC2045] format. | |||
defined method how to convey an ID value uniquely identifying the | ||||
body part. | ||||
1.2. Referencing the ID value uniquely identifying body | A body part in the multipart message-body is described using header | |||
fields such as Content-Disposition, Content-Encoding, and Content- | ||||
Type, which provide information on the content of the body part, as | ||||
specified in [RFC5621]. A body part in the multipart message-body | ||||
can also contain a Content-ID header field with an ID value uniquely | ||||
identifying the body part, as specified in [RFC2045]. | ||||
A SIP header field can contain a reference to a body part using a | 1.2. Referring a body part | |||
Content-ID URL, as specified in [RFC5621]. | ||||
The Content-ID URL is specified in [RFC2392]. [RFC2392] also | A SIP header field can refer a body part using a Content-ID URL, as | |||
specifies how to discover the body part referenced by a Content-ID | specified in [RFC5621]. | |||
URL. | ||||
Examples of a SIP header field referencing a body part using a | The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies | |||
Content-ID URL are: | how to identify the body part referred by a Content-ID URL. The | |||
Content-ID URL value is included in the Content-ID header field of | ||||
the body part. | ||||
o [RFC6442] specifies how a Geolocation header field references a | Examples of SIP header fields referring a body part using a Content- | |||
body part using a Content-ID URL, for providing location. | ID URL are: | |||
o [RFC5368] specifies how a Refer-To header field references a body | ||||
part using a Content-ID URL, to provide a list of targets. | o [RFC6442] specifies how a Geolocation header field refers a body | |||
part using a Content-ID URL, for providing location. | ||||
o [RFC5368] specifies how a Refer-To header field refers a body part | ||||
using a Content-ID URL, to provide a list of targets. | ||||
1.3. Problem statement | 1.3. Problem statement | |||
Since the Content-ID header field is not a defined SIP header field: | It is currently not specified how to uniquely identify a complete | |||
message-body of a SIP message using a Content-ID header field, and | ||||
how to refer a complete message-body using a Content-ID URL. | ||||
o If solely one body needs to be transported in a SIP message and | 1.4. Consequencies | |||
the UAC does not need to include in the SIP message a SIP header | ||||
field referencing the body part, then the UAC sets the message- | ||||
body to the body. | ||||
o However, if solely one body needs to be transported in a SIP | ||||
message and the UAC needs to include in the SIP message a SIP | ||||
header field referencing the body part, then the UAC sets the | ||||
message-body to be of the "multipart" MIME type and includes one | ||||
body part and associated Content-ID header field. | ||||
1.4. Examples of the problem | The examples below shows the consequencies of the problem described | |||
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 one body | location is conveyed by value, then the UAC needs to include one | |||
only in the INVITE request. | content only in the INVITE request. This content can be e.g. of the | |||
This body contains the location information and can be e.g. of the | ||||
application/pidf+xml MIME type. | 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 containing the location information, | field referring the body part with the location information, the UAC | |||
the UAC needs to include a message-body of "multipart/mixed" MIME | includes a multipart message-body with single body part in the INVITE | |||
type in the INVITE request, and the UAC needs to include a body part | request, and includes the location information of application/ | |||
of the application/pidf+xml MIME type and associated Content-ID | pidf+xml MIME type and an associated Content-ID header field in the | |||
header field in the message-body of the "multipart/mixed" MIME type. | body part. | |||
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 one body only | specified in [RFC5368], then the UAC needs to include one content | |||
in the REFER request. | only in the REFER request. This content is of the application/ | |||
This body contains the list of targets and 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 referring the body part containing the list of targets, the UAC | |||
UAC needs to include a message-body of the "multipart/mixed" MIME | includes a multipart message-body with single body part in the REFER | |||
type in the REFER request and the UAC needs to include a body part of | request, and includes the list of targets of application/resource- | |||
the application/resource-lists+xml MIME type and associated Content- | lists+xml MIME type and an associated Content-ID header field in the | |||
ID header field in the message-body of the "multipart/mixed" MIME | body part. | |||
type. | ||||
1.5. Solution | 1.5. Solution | |||
To avoid the unnecessary usage of a message-body of a "multipart" | In order to solve the problems described above, this document: | |||
MIME type when only one body needs to be included in a SIP message, | ||||
this document specifies a Content-ID header field as a SIP header | ||||
field. | ||||
The Content-ID header field included in header fields of a SIP | o Specifies and registers the Content-ID header field as a SIP | |||
message identifies a body part consisting of the message-body of the | header field; and | |||
SIP message and: | o Specifies that, when used as a SIP header field, the Content-ID | |||
header field identifies the complete message-body, and metadata | ||||
provided by some additional SIP header fields, of the SIP message; | ||||
and | ||||
o Updates [RFC5621], to enable a Content-ID URL to refer a complete | ||||
message-body and metadata provided by some additional SIP header | ||||
fields. | ||||
o a MIME-Version header field, if included in the header fields of | NOTE: In [RFC5621], the Content-ID URL refers a specific body part | |||
the SIP message; | only. | |||
o a Content-Disposition header field, if included in the header | ||||
fields of the SIP message; | ||||
o a Content-Encoding header field, if included in the header fields | ||||
of the SIP message; | ||||
o a Content-ID header field, if included in the header fields of the | ||||
SIP message; | ||||
o a Content-Language header field, if included in the header fields | ||||
of the SIP message; | ||||
o a Content-Length header field, if included in the header fields of | ||||
the SIP message; | ||||
o a Content-Type header field, if included in the header fields of | ||||
the SIP message. | ||||
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 for the Content-ID header fields is: | The ABNF for the Content-ID header fields is: | |||
Content-ID = "Content-ID" HCOLON msg-id | Content-ID = "Content-ID" HCOLON msg-id | |||
NOTE: msg-id is specified in [RFC5322]. | msg-id = "<" id-left "@" id-right ">" | |||
3.3. Semantic | NOTE: id-left and id-right are specified in [RFC5322]. | |||
A Content-ID header field included in header fields of a SIP message | NOTE: When used in a SIP header field, the msg-id syntax has been | |||
indicates a globally unique identification of a body part consisting | simplified compared to the syntax in [RFC5322]. | |||
of the message-body of the SIP message and: | ||||
3.3. Semantics | ||||
The Content-ID header field included in the header fields of a SIP | ||||
message identifies the message-body of the SIP message, and the | ||||
metadata provided by: | ||||
o the Content-ID header field itself; | ||||
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; | the SIP message; | |||
o a Content-Disposition header field, if included in the header | o a Content-Disposition header field, if included in the header | |||
fields of the SIP message; | fields of the SIP message; | |||
o a Content-Encoding header field, if included in the header fields | o a Content-Encoding header field, if included in the header fields | |||
of the SIP message; | of the SIP message; | |||
o a Content-ID header field, if included in the header fields of the | ||||
SIP message; | ||||
o a Content-Language header field, if included in the header fields | o a Content-Language header field, if included in the header fields | |||
of the SIP message; | of the SIP message; | |||
o a Content-Length header field, if included in the header fields of | o a Content-Length header field, if included in the header fields of | |||
the SIP message; | the SIP message; and | |||
o a Content-Type header field, if included in the header fields of | o a Content-Type header field, if included in the header fields of | |||
the SIP message. | the SIP 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. | |||
3.4. Procedures | 3.4. Procedures | |||
3.4.1. UA procedures | 3.4.1. UA procedures | |||
skipping to change at page 6, line 27 ¶ | 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. | |||
4. Security Considerations | 4. Update to RFC 5621 | |||
This section updates section 9.1 of [RFC5621], by allowing a Content- | ||||
ID URL to reference a message-body and the related metadata | ||||
(Section 3.3), in addition to allowing to reference to a body part.A | ||||
OLD TEXT: | ||||
Content-ID URLs allow creating references to body parts. A given | ||||
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 | ||||
particular body part. | ||||
NEW TEXT: | ||||
Content-ID URLs allow creating references to body parts or | ||||
message-bodies (and the header fields describing the | ||||
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), | ||||
points to a particular body part or the message-body (and the | ||||
header fields describing the message-body). | ||||
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. | |||
If the message-body associated with the Content-ID header field | If the message-body associated with the Content-ID header field is an | |||
contains encrypted content, it MUST NOT be possible to derive a key | encrypted body, it MUST NOT be possible to derive a key that can be | |||
that can be used to decrypt the message-body content from the | used to decrypt the body from the Content-ID header field value. | |||
Content-ID header field value. | ||||
5. IANA Considerations | 6. 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 in [RFC3261]. | |||
5.1. Header Field | 6.1. Header field | |||
[RFC EDITOR NOTE: Please replace XXXX with the RFC number of this | [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this | |||
document when publishing] | document when publishing] | |||
RFC Number: RFC XXXX | RFC Number: RFC XXXX | |||
Header Field Name: Content-ID | Header Field Name: Content-ID | |||
Compact Form: none | Compact Form: none | |||
6. Change Log | 7. Change log | |||
[RFC EDITOR NOTE: Please remove this section when publishing] | [RFC EDITOR NOTE: Please remove this section when publishing] | |||
Changes in draft-ietf-sipcore-content-id-01: | Changes from draft-ietf-sipcore-content-id-01 | |||
o Clean up of section 1, including shortening introduction and | o Update to RFC 5621 added. | |||
cleaning up of "body" and "body part" usages. | o Editorial changes. | |||
o Clarify that the SIP header fields forming the body part are not | ||||
required to be present in the SIP message. | ||||
o MIME-Version header field included as one of the SIP header fields | ||||
forming the body part; | ||||
7. Normative References | 8. 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, | |||
<http://www.rfc-editor.org/info/rfc2045>. | <http://www.rfc-editor.org/info/rfc2045>. | |||
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | ||||
Extensions (MIME) Part Two: Media Types", RFC 2046, | ||||
DOI 10.17487/RFC2046, November 1996, | ||||
<http://www.rfc-editor.org/info/rfc2046>. | ||||
[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, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://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, | |||
<http://www.rfc-editor.org/info/rfc2392>. | <http://www.rfc-editor.org/info/rfc2392>. | |||
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, | |||
End of changes. 44 change blocks. | ||||
123 lines changed or deleted | 129 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/ |