draft-ietf-sipcore-content-id-02.txt   draft-ietf-sipcore-content-id-03.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 April 25, 2017 Intended status: Standards Track April 28, 2017
Expires: October 27, 2017 Expires: October 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-02 draft-ietf-sipcore-content-id-03
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 refer a complete message-body and 5621, to enable a Content-ID URL to reference a complete message-body
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
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 October 27, 2017. This Internet-Draft will expire on October 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
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. Identifying a body part . . . . . . . . . . . . . . . . . 2 1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2
1.2. Referring a body part . . . . . . . . . . . . . . . . . . 3 1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3
1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3
1.4. Consequencies . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 5
4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 6 4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 6
5. Security considerations . . . . . . . . . . . . . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 7
7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative references . . . . . . . . . . . . . . . . . . . . 7 8. Normative references . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
A multipart message-body contains zero, one or several body parts, A multipart message-body contains zero, one or several body parts,
encoded using [RFC2045] format. encoded using [RFC2045] format.
A body part in the multipart message-body is described using header A body part in the multipart message-body is described using header
fields such as Content-Disposition, Content-Encoding, and Content- fields such as Content-Disposition, Content-Encoding, and Content-
Type, which provide information on the content of the body part, as Type, which provide information on the content of the body part, as
specified in [RFC5621]. A body part in the multipart message-body specified in [RFC5621]. A body part in the multipart message-body
can also contain a Content-ID header field with an ID value uniquely can also contain a Content-ID header field with an ID value uniquely
identifying the body part, as specified in [RFC2045]. identifying the body part, as specified in [RFC2045].
1.2. Referring a body part 1.2. Referencing a body part
A SIP header field can refer a body part using a Content-ID URL, as A SIP header field can reference a body part using a Content-ID URL,
specified in [RFC5621]. as specified in [RFC5621].
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 referred 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 referring a body part using a Content- Examples of SIP header fields referencing a body part using a
ID URL are: Content-ID URL are:
o [RFC6442] specifies how a Geolocation header field refers a body o [RFC6442] specifies how a Geolocation header field references a
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 refers a body part o [RFC5368] specifies how a Refer-To header field references a body
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 refer a complete message-body using a Content-ID URL. how to reference a complete message-body using a Content-ID URL.
1.4. Consequencies 1.4. Consequences
The examples below shows the consequencies 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 one location is conveyed by value, then the UAC needs to include one
content only in the INVITE request. This content can be e.g. of the content only in the INVITE request. This content 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 referring the body part with the location information, the UAC field referencing the body part with the location information, the
includes a multipart message-body with single body part in the INVITE UAC includes a multipart message-body with single body part in the
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.
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 content specified in [RFC5368], then the UAC needs to include one content
only in the REFER request. This content is of the application/ only in the REFER request. This content 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 referring the body part containing the list of targets, the UAC field referencing the body part containing the list of targets, the
includes a multipart message-body with single body part in the REFER UAC includes a multipart message-body with single body part in the
request, and includes the list of targets of application/resource- REFER request, and includes the list of targets of application/
lists+xml MIME type and an associated Content-ID header field in the resource-lists+xml MIME type and an associated Content-ID header
body part. field in the body part.
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
o Updates [RFC5621], to enable a Content-ID URL to refer a complete o Updates [RFC5621], to enable a Content-ID URL to reference a
message-body and metadata provided by some additional SIP header complete message-body and metadata provided by some additional SIP
fields. header fields.
NOTE: In [RFC5621], the Content-ID URL refers a specific body part NOTE: In [RFC5621], the Content-ID URL references a specific body
only. 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
skipping to change at page 5, line 24 skipping to change at page 5, line 24
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].
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 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;
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-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; and the SIP message; and
o a Content-Type header field, if included in the header fields of o any 'Content-' prefixed header fields (including the Content-ID
the SIP message. header field itself) 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 21 skipping to change at page 6, line 14
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. 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 to reference to a body part.A (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
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:
skipping to change at page 7, line 25 skipping to change at page 7, line 20
RFC Number: RFC XXXX RFC Number: RFC XXXX
Header Field Name: Content-ID Header Field Name: Content-ID
Compact Form: none Compact Form: none
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-02
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.
8. 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,
 End of changes. 25 change blocks. 
48 lines changed or deleted 44 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/