idnits 2.17.1 draft-ietf-sipcore-content-id-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 30, 2017) is 2643 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group C. Holmberg 3 Internet-Draft I. Sedlacek 4 Intended status: Standards Track Ericsson 5 Expires: August 3, 2017 January 30, 2017 7 Content ID header field in Session Initiation Protocol (SIP) 8 draft-ietf-sipcore-content-id-00 10 Abstract 12 This document specifies the Content-ID header field for usage in the 13 Session Initiation Protocol (SIP). 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 3, 2017. 32 Copyright Notice 34 Copyright (c) 2017 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Setting up ID value uniquely identifying the body . . . . 2 51 1.2. Referencing the ID value uniquely identifying the body . 3 52 1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 53 1.4. Examples of the problem . . . . . . . . . . . . . . . . . 3 54 1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3 55 1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4 56 1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Content-ID header field . . . . . . . . . . . . . . . . . . . 5 59 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Semantic . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5 64 3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Header Field . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 1.1. Setting up ID value uniquely identifying the body 76 A SIP message consists of a start-line, one or more header fields, an 77 empty line indicating the end of the header fields, and an optional 78 message-body, as specified in [RFC3261]. 80 A message-body of the SIP message can contain one body only or can 81 contain several bodies, as specified in [RFC3261]. 83 When the message-body of the SIP message contains several bodies, 84 each body is included in a body part encoded using [RFC2045] format 85 in the message-body of the SIP message, as specified in [RFC5621]. A 86 body part encoded using [RFC2045] format can contain a Content-ID 87 header field with an ID value uniquely identifying the body part, as 88 specified in [RFC2045]. 90 However, when the message-body of the SIP message contains one body 91 only, there are no body parts and there is also no defined method how 92 to convey an ID value uniquely identifying the body part. Also, the 93 Content-ID header field is not a defined SIP header field and thus 94 the Content-ID header field cannot be included in the header fields 95 of a SIP message. 97 1.2. Referencing the ID value uniquely identifying the body 99 A SIP header field can contain a reference to a body part using a 100 Content-ID URL, as specified in [RFC5621]. 102 The Content-ID URL is specified in [RFC2392]. [RFC2392] also 103 specifies how to discover the body part referenced by a Content-ID 104 URL. 106 Examples of a SIP header field referencing a body part using a 107 Content-ID URL are: 109 o [RFC6442] specifies how a Geolocation header field references a 110 body part using a Content-ID URL, for providing location. 111 o [RFC5368] specifies how a Refer-To header field references a body 112 part using a Content-ID URL, to provide a list of targets. 114 1.3. Problem statement 116 Since the Content-ID header field is not a defined SIP header field: 118 o When solely one body needs to be transported in a SIP message, if 119 a UAC does not need to include in the SIP message a SIP header 120 field referencing the body part, the UAC sets the message-body to 121 the body. 122 o However, when solely one body needs to be transported in a SIP 123 message, if a UAC needs to include in the SIP message a SIP header 124 field referencing the body part, then the UAC needs to include the 125 body in a body part encoded using the [RFC2045] format. I.e., the 126 UAC sets the message-body using [RFC2045] format and includes one 127 body part with the body and associated Content-ID header field. 129 1.4. Examples of the problem 131 1.4.1. Example 1 133 If a UAC sends an INVITE request conveying location as specified in 134 [RFC6442], if the UAC decides not to include an SDP offer, and if the 135 location is conveyed by value, then the UAC needs to include one body 136 only in the INVITE request. 138 This body contains the location information and can be e.g. of the 139 application/pidf+xml MIME type. 141 However, due to [RFC6442] requiring inclusion of a Geolocation header 142 field referencing the body part with the body containing the location 143 information, the UAC needs to include a message-body of multipart/ 144 mixed MIME type in the INVITE request, and the UAC needs to include a 145 body part with the application/pidf+xml body and associated Content- 146 ID header field in the multipart/mixed body. 148 1.4.2. Example 2 150 If a UAC sends an REFER request including a list of targets as 151 specified in [RFC5368], then the UAC needs to include one body only 152 in the REFER request. 154 This body contains the list of targets and is of the application/ 155 resource-lists+xml MIME type. 157 However, due to [RFC5368] requiring inclusion of a Refer-To header 158 field referencing the body part containing the list of targets, the 159 UAC needs to include a message-body of the multipart/mixed MIME type 160 in the REFER request and the UE needs to include a body part with the 161 application/resource-lists+xml body and associated Content-ID header 162 field in the multipart/mixed body. 164 1.5. Solution 166 To avoid the unnecessary usage of the [RFC2045] format when only one 167 body needs to be included in a SIP message, this document specifies a 168 Content-ID header field as a SIP header field. 170 The Content-ID header field included in header fields of a SIP 171 message identifies a body part consisting of the message-body of the 172 SIP message and: 174 o a Content-Disposition header field; 175 o a Content-Encoding header field; 176 o a Content-Language header field; 177 o a Content-Length header field; 178 o a Content-Type header field; and 179 o a Content-ID header field; 181 included in the header fields of the SIP message. 183 2. Conventions 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 3. Content-ID header field 191 3.1. Introduction 193 This section defines the usage of the Content-ID header field for 194 SIP. 196 3.2. Syntax 198 The ABNF for the Content-ID header fields is: 200 Content-ID = "Content-ID" HCOLON msg-id 202 NOTE: msg-id is specified in [RFC5322]. 204 3.3. Semantic 206 A Content-ID header field included in header fields of a SIP message 207 indicates a globally unique identification of a body part consisting 208 of the message-body of the SIP message and: 210 o a Content-Disposition header field; 211 o a Content-Encoding header field; 212 o a Content-Language header field; 213 o a Content-Length header field; 214 o a Content-Type header field; and 215 o a Content-ID header field; 217 included in header fields of the SIP message. 219 The Content-ID header field can be included in any SIP message which 220 is allowed to contain a message-body. 222 3.4. Procedures 224 3.4.1. UA procedures 226 A UA MAY include a Content-ID header field in any SIP message which 227 is allowed to contain a message-body. 229 A UA MUST NOT include a Content-ID header field in any SIP message 230 which is not allowed to contain a message-body. 232 The UA MUST set the value of the Content-ID header field to a 233 globally unique value. 235 3.4.2. Proxy procedures 237 A proxy MUST NOT add a Content-ID header field in a SIP message. 239 A proxy MUST NOT modify a Content-ID header field included in a SIP 240 message. 242 A proxy MUST NOT delete a Content-ID header field from a SIP message. 244 4. Security Considerations 246 The Content-ID header field value MUST NOT reveal sensitive user 247 information. 249 If the message-body associated with the Content-ID header field 250 contains encrypted content, it MUST NOT be possible to derive a key 251 that can be used to decrypt the message-body content from the 252 Content-ID header field value. 254 5. IANA Considerations 256 This specification registers a new SIP header field according to the 257 procedures in [RFC3261]. 259 5.1. Header Field 261 [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this 262 document when publishing] 264 RFC Number: RFC XXXX 266 Header Field Name: Content-ID 268 Compact Form: none 270 6. Change Log 272 [RFC EDITOR NOTE: Please remove this section when publishing] 274 TBD 276 7. Normative References 278 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 279 Extensions (MIME) Part One: Format of Internet Message 280 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 281 . 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 289 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 290 . 292 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 293 DOI 10.17487/RFC5322, October 2008, 294 . 296 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 297 A., Peterson, J., Sparks, R., Handley, M., and E. 298 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 299 DOI 10.17487/RFC3261, June 2002, 300 . 302 [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., 303 and H. Khartabil, "Referring to Multiple Resources in the 304 Session Initiation Protocol (SIP)", RFC 5368, 305 DOI 10.17487/RFC5368, October 2008, 306 . 308 [RFC5621] Camarillo, G., "Message Body Handling in the Session 309 Initiation Protocol (SIP)", RFC 5621, 310 DOI 10.17487/RFC5621, September 2009, 311 . 313 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 314 for the Session Initiation Protocol", RFC 6442, 315 DOI 10.17487/RFC6442, December 2011, 316 . 318 Authors' Addresses 320 Christer Holmberg 321 Ericsson 322 Hirsalantie 11 323 Jorvas 02420 324 Finland 326 Email: christer.holmberg@ericsson.com 327 Ivo Sedlacek 328 Ericsson 329 Sokolovska 79 330 Praha 18600 331 Czech Republic 333 Email: ivo.sedlacek@ericsson.com