idnits 2.17.1 draft-ietf-sipcore-content-id-06.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 (Using the creation date from RFC5621, updated by this document, for RFC5378 checks: 2007-08-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 5, 2017) is 2516 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 (==), 2 comments (--). 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 Updates: 5621 (if approved) Ericsson 5 Intended status: Standards Track June 5, 2017 6 Expires: December 7, 2017 8 Content-ID header field in Session Initiation Protocol (SIP) 9 draft-ietf-sipcore-content-id-06 11 Abstract 13 This document specifies the Content-ID header field for usage in the 14 Session Initiation Protocol (SIP). The document also updates RFC 15 5621, to enable a Content-ID URL to reference a complete message-body 16 and metadata provided by some additional SIP header fields. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 7, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2 54 1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3 55 1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 56 1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 3 57 1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3 58 1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 4 59 1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Content-ID header field . . . . . . . . . . . . . . . . . . . 4 62 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.4.1. UA procedures . . . . . . . . . . . . . . . . . . . . 5 67 3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 6 68 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 7 70 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 71 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. Normative references . . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 1.1. Identifying a body part 81 A SIP message consists of a start-line, one or more header fields, an 82 empty line indicating the end of the header fields, and an optional 83 message-body, as specified in [RFC3261]. 85 The message-body can be a non-multipart message-body or a multipart 86 message-body as specified in [RFC3261]. 88 [RFC5621] defines generic handling of a multipart message-body in a 89 SIP message. 91 A multipart message-body contains zero, one or several body parts, 92 encoded using [RFC2045] format. 94 A body part in the multipart message-body is described using header 95 fields such as Content-Disposition, Content-Encoding, and Content- 96 Type, which provide information on the content of the body part, as 97 specified in [RFC5621]. A body part in the multipart message-body 98 can also contain a Content-ID header field with an ID value uniquely 99 identifying the body part, as specified in [RFC2045]. 101 1.2. Referencing a body part 103 A SIP header field can reference a body part using a Content-ID URL, 104 as specified in [RFC5621]. 106 The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies 107 how to identify the body part referenced by a Content-ID URL. The 108 Content-ID URL value is included in the Content-ID header field of 109 the body part. 111 Examples of SIP header fields referencing a body part using a 112 Content-ID URL are: 114 o [RFC6442] specifies how a Geolocation header field references a 115 body part using a Content-ID URL, for providing location. 116 o [RFC5368] specifies how a Refer-To header field references a body 117 part using a Content-ID URL, to provide a list of targets. 119 1.3. Problem statement 121 It is currently not specified how to uniquely identify a complete 122 message-body of a SIP message using a Content-ID header field, and 123 how to reference a complete message-body using a Content-ID URL. 125 NOTE: In [RFC5621], the Content-ID URL references a specific body 126 part only. 128 1.4. Consequences 130 The examples below shows the consequences of the problem described 131 above. 133 1.4.1. Example 1 135 If a UAC sends an INVITE request conveying location as specified in 136 [RFC6442], if the UAC decides not to include an SDP offer, and if the 137 location is conveyed by value, then the UAC needs to include only one 138 MIME entity in the INVITE request. This MIME entity can be e.g. of 139 the application/pidf+xml MIME type. 141 However, due to [RFC6442] requiring inclusion of a Geolocation header 142 field referencing the body part with the location information, the 143 UAC includes a multipart message-body with single body part in the 144 INVITE request, and includes the location information of application/ 145 pidf+xml MIME type and an associated Content-ID header field in the 146 body part. 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 only one MIME 152 entity in the REFER request. This MIME entity is of the application/ 153 resource-lists+xml MIME type. 155 However, due to [RFC5368] requiring inclusion of a Refer-To header 156 field referencing the body part containing the list of targets, the 157 UAC includes a multipart message-body with single body part in the 158 REFER request, and includes the list of targets of application/ 159 resource-lists+xml MIME type and an associated Content-ID header 160 field in the body part. 162 1.5. Solution 164 In order to solve the problems described above, this document: 166 o Specifies and registers the Content-ID header field as a SIP 167 header field; and 168 o Specifies that, when used as a SIP header field, the Content-ID 169 header field identifies the complete message-body, and metadata 170 provided by some additional SIP header fields, of the SIP message; 171 and 172 o Updates [RFC5621], to enable a Content-ID URL to reference a 173 complete message-body and metadata provided by some additional SIP 174 header fields. 176 2. Conventions 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 3. Content-ID header field 184 3.1. Introduction 186 This section defines the usage of the Content-ID header field for 187 SIP. 189 3.2. Syntax 191 The ABNF [RFC5234] for the Content-ID header field is: 193 Content-ID = "Content-ID" HCOLON msg-id 195 msg-id = "<" id-left "@" id-right ">" 197 NOTE: id-left and id-right are specified in [RFC5322]. HCOLON is 198 defined in [RFC3261]. 200 NOTE: When used in a SIP header field, the msg-id syntax has been 201 simplified, compared to the syntax in [RFC5322], to disallow the use 202 of comments and to adopt to the SIP usage of leading white space. 204 The value of Content-Id header field value must be unique in the 205 context of a given SIP message, including any embedded MIME 206 Content-Id header field values. Note that the SIP Content-ID header 207 field value is not expected to be unique among all SIP messages; it 208 has no meaning outside of the message in which it is included. 210 3.3. Semantics 212 The Content-ID header field included in the header fields of a SIP 213 message identifies the message-body of the SIP message, and the 214 metadata provided by: 216 o a MIME-Version header field, if included in the header fields of 217 the SIP message; and 218 o any 'Content-' prefixed header fields (including the Content-ID 219 header field itself) included in the header fields of the SIP 220 message. 222 The Content-ID header field can be included in any SIP message which 223 is allowed to contain a message-body. 225 3.4. Procedures 227 3.4.1. UA procedures 229 A UA MAY include a Content-ID header field in any SIP message that is 230 allowed to contain a message-body. 232 A UA MUST NOT include a Content-ID header field in any SIP message 233 that is not allowed to contain a message-body. 235 The UA MUST set the value of the Content-ID header field to a 236 globally unique value. 238 3.4.2. Proxy procedures 240 A proxy MUST NOT add a Content-ID header field in a SIP message. 242 A proxy MUST NOT modify a Content-ID header field included in a SIP 243 message. 245 A proxy MUST NOT delete a Content-ID header field from a SIP message. 247 3.4.3. Example 249 The figure shows an example from [RFC5368], where the SIP Content-ID 250 header field is used to reference the message body (non-multipart) of 251 a SIP message. 253 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 254 Via: SIP/2.0/TCP client.chicago.example.com 255 ;branch=z9hG4bKhjhs8ass83 256 Max-Forwards: 70 257 To: "Conference 123" 258 From: Carol ;tag=32331 259 Call-ID: d432fa84b4c76e66710 260 CSeq: 2 REFER 261 Contact: 262 Refer-To: 263 Refer-Sub: false 264 Require: multiple-refer, norefersub 265 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 266 Allow-Events: dialog 267 Accept: application/sdp, message/sipfrag 268 Content-Type: application/resource-lists+xml 269 Content-Disposition: recipient-list 270 Content-Length: 362 271 Content-ID: 273 274 276 277 278 279 280 281 283 4. Update to RFC 5621 285 This section updates section 9.1 of [RFC5621], by allowing a Content- 286 ID URL to reference a message-body and the related metadata 287 (Section 3.3), in addition to allowing a reference to a body part. 289 OLD TEXT: 291 Content-ID URLs allow creating references to body parts. A given 292 Content-ID URL [RFC2392], which can appear in a header field or 293 within a body part (e.g., in an SDP attribute), points to a 294 particular body part. 296 NEW TEXT: 298 Content-ID URLs allow creating references to body parts or 299 message-bodies (and the header fields describing the 300 message-bodies). A given Content-ID URL [RFC2392], which can appear 301 in a header field or within a body part (e.g., in an SDP attribute), 302 points to a particular body part or the message-body (and the 303 header fields describing the message-body). 305 5. Security considerations 307 The Content-ID header field value MUST NOT reveal sensitive user 308 information. 310 If the message-body associated with the Content-ID header field is an 311 encrypted body, it MUST NOT be possible to derive a key that can be 312 used to decrypt the body from the Content-ID header field value. 314 6. IANA considerations 316 This specification registers a new SIP header field according to the 317 procedures in [RFC3261]. 319 6.1. Header field 321 The header field described in Section 3 has been registered in the 322 "Header Fields" sub-registry of the "Session Initiation Protocol 323 (SIP) Parameters" registry by adding a row with these values: 325 [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this 326 document when publishing] 328 Header Name: Content-ID 330 compact: 332 Reference: RFCXXXX 334 7. Change log 336 [RFC EDITOR NOTE: Please remove this section when publishing] 338 Changes from draft-ietf-sipcore-content-id-05 340 o Changes based on AD comments from Ben Campell: 341 o - Clarifying that Content-ID header field value is unique within 342 the scope of a SIP message. 344 Changes from draft-ietf-sipcore-content-id-04 346 o Minor editorial fix. 348 Changes from draft-ietf-sipcore-content-id-03 350 o Changes based on doc shepard review: 351 o - Reference to RFC 5234 added. 352 o - SIP message example added. 353 o - Editorial changes. 355 Changes from draft-ietf-sipcore-content-id-02 357 o Editorial changes based on comments from Paul Kyzivat. 359 Changes from draft-ietf-sipcore-content-id-01 361 o Update to RFC 5621 added. 362 o Editorial changes. 364 8. Normative references 366 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 367 Extensions (MIME) Part One: Format of Internet Message 368 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 369 . 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, 373 DOI 10.17487/RFC2119, March 1997, 374 . 376 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 377 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 378 . 380 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 381 Specifications: ABNF", STD 68, RFC 5234, 382 DOI 10.17487/RFC5234, January 2008, 383 . 385 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 386 DOI 10.17487/RFC5322, October 2008, 387 . 389 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 390 A., Peterson, J., Sparks, R., Handley, M., and E. 391 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 392 DOI 10.17487/RFC3261, June 2002, 393 . 395 [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., 396 and H. Khartabil, "Referring to Multiple Resources in the 397 Session Initiation Protocol (SIP)", RFC 5368, 398 DOI 10.17487/RFC5368, October 2008, 399 . 401 [RFC5621] Camarillo, G., "Message Body Handling in the Session 402 Initiation Protocol (SIP)", RFC 5621, 403 DOI 10.17487/RFC5621, September 2009, 404 . 406 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 407 for the Session Initiation Protocol", RFC 6442, 408 DOI 10.17487/RFC6442, December 2011, 409 . 411 Authors' Addresses 413 Christer Holmberg 414 Ericsson 415 Hirsalantie 11 416 Jorvas 02420 417 Finland 419 Email: christer.holmberg@ericsson.com 420 Ivo Sedlacek 421 Ericsson 422 Sokolovska 79 423 Praha 18600 424 Czech Republic 426 Email: ivo.sedlacek@ericsson.com