draft-ietf-sipcore-content-id-00.txt   draft-ietf-sipcore-content-id-01.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft I. Sedlacek Internet-Draft I. Sedlacek
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: August 3, 2017 January 30, 2017 Expires: September 9, 2017 March 8, 2017
Content ID header field in Session Initiation Protocol (SIP) Content ID header field in Session Initiation Protocol (SIP)
draft-ietf-sipcore-content-id-00 draft-ietf-sipcore-content-id-01
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).
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.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 August 3, 2017. This Internet-Draft will expire on September 9, 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 the body . . . . 2 1.1. Setting up ID value uniquely identifying body . . . . . . 2
1.2. Referencing the ID value uniquely identifying the body . 3 1.2. Referencing the ID value uniquely identifying body . . . 3
1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3
1.4. Examples of the problem . . . . . . . . . . . . . . . . . 3 1.4. Examples of the problem . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Content-ID header field . . . . . . . . . . . . . . . . . . . 5 3. Content-ID header field . . . . . . . . . . . . . . . . . . . 5
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Semantic . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Semantic . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6
3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5 3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 6
3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6 3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 6
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
1.1. Setting up ID value uniquely identifying the body 1.1. Setting up ID value uniquely identifying body
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 A message-body of the SIP message can contain one body only or can
contain several bodies, as specified in [RFC3261]. contain several body parts, as specified in [RFC3261] and [RFC5621].
When the message-body of the SIP message contains several bodies, A body part encoded using [RFC2045] can contain a Content-ID header
each body is included in a body part encoded using [RFC2045] format field with an ID value uniquely identifying the body part, as
in the message-body of the SIP message, as specified in [RFC5621]. A
body part encoded using [RFC2045] format can contain a Content-ID
header field with an ID value uniquely identifying the body part, as
specified in [RFC2045]. specified in [RFC2045].
However, when the message-body of the SIP message contains one body However, when the message-body of the SIP message contains one body
only, there are no body parts and there is also no defined method how only, there is no body part specified. Thus, there is also no
to convey an ID value uniquely identifying the body part. Also, the defined method how to convey an ID value uniquely identifying the
Content-ID header field is not a defined SIP header field and thus body part.
the Content-ID header field cannot be included in the header fields
of a SIP message.
1.2. Referencing the ID value uniquely identifying the body 1.2. Referencing the ID value uniquely identifying body
A SIP header field can contain a reference to a body part using a A SIP header field can contain a reference to a body part using a
Content-ID URL, as specified in [RFC5621]. Content-ID URL, as specified in [RFC5621].
The Content-ID URL is specified in [RFC2392]. [RFC2392] also The Content-ID URL is specified in [RFC2392]. [RFC2392] also
specifies how to discover the body part referenced by a Content-ID specifies how to discover the body part referenced by a Content-ID
URL. URL.
Examples of a SIP header field referencing a body part using a Examples of a SIP header field 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.
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
Since the Content-ID header field is not a defined SIP header field: Since the Content-ID header field is not a defined SIP header field:
o When solely one body needs to be transported in a SIP message, if o If solely one body needs to be transported in a SIP message and
a UAC does not need to include in the SIP message a SIP header the UAC does not need to include in the SIP message a SIP header
field referencing the body part, the UAC sets the message-body to field referencing the body part, then the UAC sets the message-
the body. body to the body.
o However, when solely one body needs to be transported in a SIP o However, if solely one body needs to be transported in a SIP
message, if a UAC needs to include in the SIP message a SIP header message and the UAC needs to include in the SIP message a SIP
field referencing the body part, then the UAC needs to include the header field referencing the body part, then the UAC sets the
body in a body part encoded using the [RFC2045] format. I.e., the message-body to be of the "multipart" MIME type and includes one
UAC sets the message-body using [RFC2045] format and includes one body part and associated Content-ID header field.
body part with the body and associated Content-ID header field.
1.4. Examples of the problem 1.4. Examples of the problem
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 body
only in the INVITE request. only in the INVITE request.
This body contains the location information and 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 with the body containing the location field referencing the body part containing the location information,
information, the UAC needs to include a message-body of multipart/ the UAC needs to include a message-body of "multipart/mixed" MIME
mixed MIME type in the INVITE request, and the UAC needs to include a type in the INVITE request, and the UAC needs to include a body part
body part with the application/pidf+xml body and associated Content- of the application/pidf+xml MIME type and associated Content-ID
ID header field in the multipart/mixed body. header field in the message-body of the "multipart/mixed" MIME type.
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 body only
in the REFER request. in the REFER request.
This body contains the list of targets and 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 referencing the body part containing the list of targets, the
UAC needs to include a message-body of the multipart/mixed MIME type UAC needs to include a message-body of the "multipart/mixed" MIME
in the REFER request and the UE needs to include a body part with the type in the REFER request and the UAC needs to include a body part of
application/resource-lists+xml body and associated Content-ID header the application/resource-lists+xml MIME type and associated Content-
field in the multipart/mixed body. ID header field in the message-body of the "multipart/mixed" MIME
type.
1.5. Solution 1.5. Solution
To avoid the unnecessary usage of the [RFC2045] format when only one To avoid the unnecessary usage of a message-body of a "multipart"
body needs to be included in a SIP message, this document specifies a MIME type when only one body needs to be included in a SIP message,
Content-ID header field as a SIP header field. 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 The Content-ID header field included in header fields of a SIP
message identifies a body part consisting of the message-body of the message identifies a body part consisting of the message-body of the
SIP message and: SIP message and:
o a Content-Disposition header field; o a MIME-Version header field, if included in the header fields of
o a Content-Encoding header field; the SIP message;
o a Content-Language header field; o a Content-Disposition header field, if included in the header
o a Content-Length header field; fields of the SIP message;
o a Content-Type header field; and o a Content-Encoding header field, if included in the header fields
o a Content-ID header field; of the SIP message;
o a Content-ID header field, if included in the header fields of the
included in the header fields of the SIP message. 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
skipping to change at page 5, line 26 skipping to change at page 5, line 32
Content-ID = "Content-ID" HCOLON msg-id Content-ID = "Content-ID" HCOLON msg-id
NOTE: msg-id is specified in [RFC5322]. NOTE: msg-id is specified in [RFC5322].
3.3. Semantic 3.3. Semantic
A Content-ID header field included in header fields of a SIP message A Content-ID header field included in header fields of a SIP message
indicates a globally unique identification of a body part consisting indicates a globally unique identification of a body part consisting
of the message-body of the SIP message and: of the message-body of the SIP message and:
o a Content-Disposition header field; o a MIME-Version header field, if included in the header fields of
o a Content-Encoding header field; the SIP message;
o a Content-Language header field; o a Content-Disposition header field, if included in the header
o a Content-Length header field; fields of the SIP message;
o a Content-Type header field; and o a Content-Encoding header field, if included in the header fields
o a Content-ID header field; of the SIP message;
o a Content-ID header field, if included in the header fields of the
included in header fields of the SIP message. 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.
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
A UA MAY include a Content-ID header field in any SIP message which A UA MAY include a Content-ID header field in any SIP message which
is allowed to contain a message-body. is allowed to contain a message-body.
skipping to change at page 6, line 44 skipping to change at page 7, line 9
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 6. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
TBD Changes in draft-ietf-sipcore-content-id-01:
o Clean up of section 1, including shortening introduction and
cleaning up of "body" and "body part" usages.
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 7. 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. 20 change blocks. 
63 lines changed or deleted 83 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/