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/