idnits 2.17.1 draft-ietf-sipcore-content-id-07.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 28, 2017) is 2494 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 28, 2017 6 Expires: December 30, 2017 8 Content-ID header field in Session Initiation Protocol (SIP) 9 draft-ietf-sipcore-content-id-07 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, which only allows a Content-ID URL to reference a body-part 16 that is part of a multipart message-body. This update enables a 17 Content-ID URL to reference a complete message-body and metadata 18 provided by some additional SIP header fields. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 30, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2 56 1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3 57 1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 58 1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 3 59 1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 3 60 1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 5 61 1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Content-ID header field . . . . . . . . . . . . . . . . . . . 7 64 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.4.1. User Agent (UA) procedures . . . . . . . . . . . . . 8 69 3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 8 70 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 71 4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 9 72 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 73 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 10 75 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8. Normative references . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 1.1. Identifying a body part 83 A SIP message consists of a start-line, one or more header fields, an 84 empty line indicating the end of the header fields, and an optional 85 message-body, as specified in [RFC3261]. 87 The message-body can be a non-multipart message-body or a multipart 88 message-body as specified in [RFC3261]. 90 [RFC5621] defines generic handling of a multipart message-body in a 91 SIP message. 93 A multipart message-body contains zero, one or several body parts, 94 encoded using [RFC2045] format. 96 A body part in the multipart message-body is described using header 97 fields such as Content-Disposition, Content-Encoding, and Content- 98 Type, which provide information on the content of the body part, as 99 specified in [RFC5621]. A body part in the multipart message-body 100 can also contain a Content-ID header field with an ID value uniquely 101 identifying the body part, as specified in [RFC2045]. 103 1.2. Referencing a body part 105 A SIP header field can reference a body part using a Content-ID URL, 106 as specified in [RFC5621]. 108 The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies 109 how to identify the body part referenced by a Content-ID URL. The 110 Content-ID URL value is included in the Content-ID header field of 111 the body part. 113 Examples of SIP header fields referencing a body part using a 114 Content-ID URL are: 116 o [RFC6442] specifies how a Geolocation header field references a 117 body part using a Content-ID URL, for providing location 118 information. 119 o [RFC5368] specifies how a Refer-To header field references a body 120 part using a Content-ID URL, to provide a list of targets. 122 1.3. Problem statement 124 It is currently not specified how to uniquely identify a complete 125 message-body of a SIP message using a Content-ID header field, and 126 how to reference a complete message-body using a Content-ID URL. 128 NOTE: In [RFC5621], the Content-ID URL references a specific body 129 part only. 131 1.4. Consequences 133 The examples below shows the consequences of the problem described 134 above. 136 1.4.1. Example 1 138 If a User Agent Client (UAC) sends an INVITE request conveying 139 location as specified in [RFC6442], if the UAC decides not to include 140 an SDP offer, and if the location is conveyed by value, then the UAC 141 needs to include only one MIME entity in the INVITE request. This 142 MIME entity can be, for example, of the application/pidf+xml MIME 143 type. 145 However, due to [RFC6442] requiring inclusion of a Geolocation header 146 field referencing the body part with the location information, the 147 UAC includes a multipart message-body with single body part in the 148 INVITE request, and includes the location information of application/ 149 pidf+xml MIME type and an associated Content-ID header field in the 150 body part. 152 Example message (SIP INVITE): 154 INVITE sips:bob@biloxi.example.com SIP/2.0 155 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 156 Max-Forwards: 70 157 To: Bob 158 From: Alice ;tag=9fxced76sl 159 Call-ID: 3848276298220188511@atlanta.example.com 160 Geolocation: 161 Geolocation-Routing: no 162 Accept: application/sdp, application/pidf+xml 163 CSeq: 31862 INVITE 164 Contact: 165 Content-Type: multipart/mixed; boundary=boundary1 166 Content-Length: ... 168 --boundary1 169 Content-Type: application/pidf+xml 170 Content-ID: 172 173 182 183 184 185 186 187 32.86726 -97.16054 188 189 190 191 192 false 193 194 2010-11-14T20:00:00Z 195 196 197 802.11 198 199 mac:1234567890ab 200 2010-11-04T20:57:29Z 201 202 203 --boundary1-- 205 1.4.2. Example 2 207 If a UAC sends an REFER request including a list of targets as 208 specified in [RFC5368], then the UAC needs to include only one MIME 209 entity in the REFER request. This MIME entity is of the application/ 210 resource-lists+xml MIME type. 212 However, due to [RFC5368] requiring inclusion of a Refer-To header 213 field referencing the body part containing the list of targets, the 214 UAC includes a multipart message-body with single body part in the 215 REFER request, and includes the list of targets of application/ 216 resource-lists+xml MIME type and an associated Content-ID header 217 field in the body part. 219 Example message (SIP REFER): 221 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 222 Via: SIP/2.0/TCP client.chicago.example.com;branch=z9hG4bKhjhs8ass83 223 Max-Forwards: 70 224 To: "Conference 123" 225 From: Carol ;tag=32331 226 Call-ID: d432fa84b4c76e66710 227 CSeq: 2 REFER 228 Contact: 229 Refer-To: 230 Refer-Sub: false 231 Require: multiple-refer, norefersub 232 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 233 Allow-Events: dialog 234 Accept: application/sdp, message/sipfrag 235 Content-Type: multipart/mixed; boundary=boundary1 236 Content-Length: ... 238 --boundary1 239 Content-Type: application/resource-lists+xml 240 Content-Disposition: recipient-list 241 Content-ID: 243 244 248 249 250 251 252 253 254 --boundary1-- 256 1.5. Solution 258 In order to solve the problems described above, this document: 260 o Specifies and registers the Content-ID header field as a SIP 261 header field; and 262 o Specifies that, when used as a SIP header field, the Content-ID 263 header field identifies the complete message-body, and metadata 264 provided by some additional SIP header fields, of the SIP message; 265 and 267 o Updates [RFC5621], to enable a Content-ID URL to reference a 268 complete message-body and metadata provided by some additional SIP 269 header fields. 271 2. Conventions 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 275 document are to be interpreted as described in [RFC2119]. 277 3. Content-ID header field 279 3.1. Introduction 281 This section defines the usage of the Content-ID header field for 282 SIP. 284 3.2. Syntax 286 The ABNF [RFC5234] for the Content-ID header field is: 288 Content-ID = "Content-ID" HCOLON msg-id 290 msg-id = "<" id-left "@" id-right ">" 292 NOTE: id-left and id-right are specified in [RFC5322]. HCOLON is 293 defined in [RFC3261]. 295 NOTE: When used in a SIP header field, the msg-id syntax has been 296 simplified, compared to the syntax in [RFC5322], to disallow the use 297 of comments and to adopt to the SIP usage of leading white space. 299 The value of Content-Id header field value must be unique in the 300 context of a given SIP message, including any embedded MIME 301 Content-Id header field values. Note that the SIP Content-ID header 302 field value is not expected to be unique among all SIP messages; it 303 has no meaning outside of the message in which it is included. 305 3.3. Semantics 307 The Content-ID header field included in the header fields of a SIP 308 message identifies the message-body of the SIP message, and the 309 metadata provided by: 311 o a MIME-Version header field, if included in the header fields of 312 the SIP message; and 314 o any 'Content-' prefixed header fields (including the Content-ID 315 header field itself) included in the header fields of the SIP 316 message. 318 The Content-ID header field can be included in any SIP message which 319 is allowed to contain a message-body. 321 NOTE: The message body identified by the Content-ID header field can 322 be a non-multipart message-body or a multipart message-body. 324 3.4. Procedures 326 3.4.1. User Agent (UA) procedures 328 A UA MAY include a Content-ID header field in any SIP message that is 329 allowed to contain a message-body. 331 A UA MUST NOT include a Content-ID header field in any SIP message 332 that is not allowed to contain a message-body. 334 The UA MUST set the value of the Content-ID header field to a value 335 that is unique in the context of the SIP message. 337 3.4.2. Proxy procedures 339 A proxy MUST NOT add a Content-ID header field in a SIP message. 341 A proxy MUST NOT modify a Content-ID header field included in a SIP 342 message. 344 A proxy MUST NOT delete a Content-ID header field from a SIP message. 346 3.4.3. Example 348 The figure shows an example from [RFC5368], where the SIP Content-ID 349 header field is used to reference the message body (non-multipart) of 350 a SIP message. 352 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 353 Via: SIP/2.0/TCP client.chicago.example.com 354 ;branch=z9hG4bKhjhs8ass83 355 Max-Forwards: 70 356 To: "Conference 123" 357 From: Carol ;tag=32331 358 Call-ID: d432fa84b4c76e66710 359 CSeq: 2 REFER 360 Contact: 361 Refer-To: 362 Refer-Sub: false 363 Require: multiple-refer, norefersub 364 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 365 Allow-Events: dialog 366 Accept: application/sdp, message/sipfrag 367 Content-Type: application/resource-lists+xml 368 Content-Disposition: recipient-list 369 Content-Length: 362 370 Content-ID: 372 373 375 376 377 378 379 380 382 4. Update to RFC 5621 384 This section updates section 9.1 of [RFC5621], by allowing a Content- 385 ID URL to reference a message-body and the related metadata 386 (Section 3.3), in addition to allowing a reference to a body part. 388 OLD TEXT: 390 Content-ID URLs allow creating references to body parts. A given 391 Content-ID URL [RFC2392], which can appear in a header field or 392 within a body part (e.g., in an SDP attribute), points to a 393 particular body part. 395 NEW TEXT: 397 Content-ID URLs allow the creation of references to body parts or 398 message-bodies (and the header fields describing the 399 message-bodies). A given Content-ID URL [RFC2392], which can appear 400 in a header field or within a body part (e.g., in an SDP attribute), 401 points to a particular body part or the message-body (and the 402 header fields describing the message-body). 404 5. Security considerations 406 The Content-ID header field value MUST NOT reveal sensitive user 407 information. 409 If the message-body associated with the Content-ID header field is an 410 encrypted body, it MUST NOT be possible to derive a key that can be 411 used to decrypt the body from the Content-ID header field value. 413 6. IANA considerations 415 This specification registers a new SIP header field according to the 416 procedures in [RFC3261]. 418 6.1. Header field 420 The header field described in Section 3 has been registered in the 421 "Header Fields" sub-registry of the "Session Initiation Protocol 422 (SIP) Parameters" registry by adding a row with these values: 424 [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this 425 document when publishing] 427 Header Name: Content-ID 429 compact: 431 Reference: RFCXXXX 433 7. Change log 435 [RFC EDITOR NOTE: Please remove this section when publishing] 437 Changes from draft-ietf-sipcore-content-id-06 439 o Editorial changes and clarifications based on Gen-ART review from 440 Elwyn Davies. 442 Changes from draft-ietf-sipcore-content-id-05 444 o Changes based on AD comments from Ben Campell: 445 o - Clarifying that Content-ID header field value is unique within 446 the scope of a SIP message. 448 Changes from draft-ietf-sipcore-content-id-04 450 o Minor editorial fix. 452 Changes from draft-ietf-sipcore-content-id-03 454 o Changes based on doc shepard review: 455 o - Reference to RFC 5234 added. 456 o - SIP message example added. 457 o - Editorial changes. 459 Changes from draft-ietf-sipcore-content-id-02 461 o Editorial changes based on comments from Paul Kyzivat. 463 Changes from draft-ietf-sipcore-content-id-01 465 o Update to RFC 5621 added. 466 o Editorial changes. 468 8. Normative references 470 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 471 Extensions (MIME) Part One: Format of Internet Message 472 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 473 . 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 481 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 482 . 484 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 485 Specifications: ABNF", STD 68, RFC 5234, 486 DOI 10.17487/RFC5234, January 2008, 487 . 489 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 490 DOI 10.17487/RFC5322, October 2008, 491 . 493 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 494 A., Peterson, J., Sparks, R., Handley, M., and E. 495 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 496 DOI 10.17487/RFC3261, June 2002, 497 . 499 [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., 500 and H. Khartabil, "Referring to Multiple Resources in the 501 Session Initiation Protocol (SIP)", RFC 5368, 502 DOI 10.17487/RFC5368, October 2008, 503 . 505 [RFC5621] Camarillo, G., "Message Body Handling in the Session 506 Initiation Protocol (SIP)", RFC 5621, 507 DOI 10.17487/RFC5621, September 2009, 508 . 510 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 511 for the Session Initiation Protocol", RFC 6442, 512 DOI 10.17487/RFC6442, December 2011, 513 . 515 Authors' Addresses 517 Christer Holmberg 518 Ericsson 519 Hirsalantie 11 520 Jorvas 02420 521 Finland 523 Email: christer.holmberg@ericsson.com 524 Ivo Sedlacek 525 Ericsson 526 Sokolovska 79 527 Praha 18600 528 Czech Republic 530 Email: ivo.sedlacek@ericsson.com