idnits 2.17.1 draft-ietf-sipcore-content-id-08.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 RFC5368, updated by this document, for RFC5378 checks: 2006-09-24) -- 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 (August 31, 2017) is 2429 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) == Missing Reference: 'RFC4483' is mentioned on line 479, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 480, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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, 5368, 6442 (if approved) Ericsson 5 Intended status: Standards Track August 31, 2017 6 Expires: March 4, 2018 8 Content-ID header field in Session Initiation Protocol (SIP) 9 draft-ietf-sipcore-content-id-08 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 This document updates RFC 5368 and RFC 6442, by clarifying their 21 usage of the SIP Content-ID header field. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 4, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Identifying a body part . . . . . . . . . . . . . . . . . 2 59 1.2. Referencing a body part . . . . . . . . . . . . . . . . . 3 60 1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 61 1.4. Consequences . . . . . . . . . . . . . . . . . . . . . . 4 62 1.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 4 63 1.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 5 64 1.5. Solution . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1.6. Backward compatibility . . . . . . . . . . . . . . . . . 7 66 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Content-ID header field . . . . . . . . . . . . . . . . . . . 7 68 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 7 69 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.4. Procedures . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.4.1. User Agent (UA) procedures . . . . . . . . . . . . . 8 73 3.4.2. Proxy procedures . . . . . . . . . . . . . . . . . . 9 74 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 75 4. Update to RFC 5368 . . . . . . . . . . . . . . . . . . . . . 10 76 5. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 10 77 6. Update to RFC 6442 . . . . . . . . . . . . . . . . . . . . . 11 78 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 79 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8.1. Header field . . . . . . . . . . . . . . . . . . . . . . 13 81 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 10.1. Normative references . . . . . . . . . . . . . . . . . . 14 84 10.2. Informative references . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 1.1. Identifying a body part 91 A SIP message consists of a start-line, one or more header fields, an 92 empty line indicating the end of the header fields, and an optional 93 message-body, as specified in [RFC3261]. 95 The message-body can be a non-multipart message-body or a multipart 96 message-body as specified in [RFC3261]. 98 [RFC5621] defines generic handling of a multipart message-body in a 99 SIP message. 101 A multipart message-body contains zero, one or several body parts, 102 encoded using [RFC2045] format. 104 A body part in the multipart message-body is described using header 105 fields such as Content-Disposition, Content-Encoding, and Content- 106 Type, which provide information on the content of the body part, as 107 specified in [RFC5621]. A body part in the multipart message-body 108 can also contain a Content-ID header field with an ID value uniquely 109 identifying the body part, as specified in [RFC2045]. 111 1.2. Referencing a body part 113 A SIP header field can reference a body part using a Content-ID URL, 114 as specified in [RFC5621]. 116 The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies 117 how to identify the body part referenced by a Content-ID URL. The 118 Content-ID URL value is included in the Content-ID header field of 119 the body part. 121 Examples of SIP header fields referencing a body part using a 122 Content-ID URL are: 124 o [RFC6442] specifies how a Geolocation header field references a 125 body part using a Content-ID URL, for providing location 126 information. 127 o [RFC5368] specifies how a Refer-To header field references a body 128 part using a Content-ID URL, to provide a list of targets. 130 1.3. Problem statement 132 It is currently not specified how to uniquely identify a complete 133 message-body of a SIP message using a Content-ID header field, and 134 how to reference a complete message-body using a Content-ID URL. 136 NOTE: In [RFC5621], the Content-ID URL references a specific body 137 part only. 139 Some existing specifications, for example [RFC5368], contain examples 140 that show usage of a SIP Content-ID header field referencing a 141 complete message-body, eventhough such usage has never been 142 specified. 144 1.4. Consequences 146 The examples below shows the consequences of the problem described 147 above. 149 1.4.1. Example 1 151 If a User Agent Client (UAC) sends an INVITE request conveying 152 location as specified in [RFC6442], if the UAC decides not to include 153 an SDP offer, and if the location is conveyed by value, then the UAC 154 needs to include only one MIME entity in the INVITE request. This 155 MIME entity can be, for example, of the application/pidf+xml MIME 156 type. 158 However, due to [RFC6442] requiring inclusion of a Geolocation header 159 field referencing the body part with the location information, the 160 UAC includes a multipart message-body with single body part in the 161 INVITE request, and includes the location information of application/ 162 pidf+xml MIME type and an associated Content-ID header field in the 163 body part. 165 Example message (SIP INVITE): 167 INVITE sips:bob@biloxi.example.com SIP/2.0 168 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 169 Max-Forwards: 70 170 To: Bob 171 From: Alice ;tag=9fxced76sl 172 Call-ID: 3848276298220188511@atlanta.example.com 173 Geolocation: 174 Geolocation-Routing: no 175 Accept: application/sdp, application/pidf+xml 176 CSeq: 31862 INVITE 177 Contact: 178 Content-Type: multipart/mixed; boundary=boundary1 179 Content-Length: ... 181 --boundary1 182 Content-Type: application/pidf+xml 183 Content-ID: 185 186 195 196 197 198 199 200 32.86726 -97.16054 201 202 203 204 205 false 206 207 2010-11-14T20:00:00Z 208 209 210 802.11 211 212 mac:1234567890ab 213 2010-11-04T20:57:29Z 214 215 216 --boundary1-- 218 1.4.2. Example 2 220 If a UAC sends an REFER request including a list of targets as 221 specified in [RFC5368], then the UAC needs to include only one MIME 222 entity in the REFER request. This MIME entity is of the application/ 223 resource-lists+xml MIME type. 225 However, due to [RFC5368] requiring inclusion of a Refer-To header 226 field referencing the body part containing the list of targets, the 227 UAC includes a multipart message-body with single body part in the 228 REFER request, and includes the list of targets of application/ 229 resource-lists+xml MIME type and an associated Content-ID header 230 field in the body part. 232 Example message (SIP REFER): 234 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 235 Via: SIP/2.0/TCP client.chicago.example.com;branch=z9hG4bKhjhs8ass83 236 Max-Forwards: 70 237 To: "Conference 123" 238 From: Carol ;tag=32331 239 Call-ID: d432fa84b4c76e66710 240 CSeq: 2 REFER 241 Contact: 242 Refer-To: 243 Refer-Sub: false 244 Require: multiple-refer, norefersub 245 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 246 Allow-Events: dialog 247 Accept: application/sdp, message/sipfrag 248 Content-Type: multipart/mixed; boundary=boundary1 249 Content-Length: ... 251 --boundary1 252 Content-Type: application/resource-lists+xml 253 Content-Disposition: recipient-list 254 Content-ID: 256 257 261 262 263 264 265 266 267 --boundary1-- 269 1.5. Solution 271 In order to solve the problems described above, this document: 273 o Specifies and registers the Content-ID header field as a SIP 274 header field; and 275 o Specifies that, when used as a SIP header field, the Content-ID 276 header field identifies the complete message-body, and metadata 277 provided by some additional SIP header fields, of the SIP message; 278 and 280 o Updates [RFC5621], to enable a Content-ID URL to reference a 281 complete message-body and metadata provided by some additional SIP 282 header fields. 283 o Updates [RFC5368] and [RFC6442] by adding explicit text saying 284 that a SIP Content-ID header field can be used. 286 1.6. Backward compatibility 288 If an existing specification explicitly defines the usage of a 289 multipart message-body for carrying a single body part, that 290 specification MUST be updated in order to allow usage of a non- 291 multipart message-body for carrying the MIME entity, and for 292 referencing the whole message-body using a Content-ID URL. 294 2. Conventions 296 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 297 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 298 document are to be interpreted as described in [RFC2119]. 300 3. Content-ID header field 302 3.1. Introduction 304 This section defines the usage of the Content-ID header field for 305 SIP. 307 3.2. Syntax 309 The ABNF [RFC5234] for the Content-ID header field is: 311 Content-ID = "Content-ID" HCOLON msg-id 313 msg-id = "<" id-left "@" id-right ">" 315 NOTE: id-left and id-right are specified in [RFC5322]. HCOLON is 316 defined in [RFC3261]. 318 NOTE: When used in a SIP header field, the msg-id syntax has been 319 simplified, compared to the syntax in [RFC5322], to disallow the use 320 of comments and to adopt to the SIP usage of leading white space. 322 The value of Content-Id header field value must be unique in the 323 context of a given SIP message, including any embedded MIME 324 Content-Id header field values. Note that the SIP Content-ID header 325 field value is not expected to be unique among all SIP messages; it 326 has no meaning outside of the message in which it is included. 328 3.3. Semantics 330 The Content-ID header field included in the header fields of a SIP 331 message identifies the message-body of the SIP message, and the 332 metadata provided by: 334 o a MIME-Version header field, if included in the header fields of 335 the SIP message; and 336 o any 'Content-' prefixed header fields (including the Content-ID 337 header field itself) included in the header fields of the SIP 338 message. 340 The Content-ID header field can be included in any SIP message which 341 is allowed to contain a message-body. 343 NOTE: The message-body identified by the Content-ID header field can 344 be a non-multipart message-body or a multipart message-body. 346 3.4. Procedures 348 3.4.1. User Agent (UA) procedures 350 A UA MAY include a Content-ID header field in any SIP message that is 351 allowed to contain a message-body. 353 A UA MUST NOT include a Content-ID header field in any SIP message 354 that is not allowed to contain a message-body. 356 The UA MUST set the value of the Content-ID header field to a value 357 that is unique in the context of the SIP message. 359 3.4.2. Proxy procedures 361 A proxy MUST NOT add a Content-ID header field in a SIP message. 363 A proxy MUST NOT modify a Content-ID header field included in a SIP 364 message. 366 A proxy MUST NOT delete a Content-ID header field from a SIP message. 368 3.4.3. Example 370 The figure shows an example from [RFC5368], where the SIP Content-ID 371 header field is used to reference the message-body (non-multipart) of 372 a SIP message. 374 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 375 Via: SIP/2.0/TCP client.chicago.example.com 376 ;branch=z9hG4bKhjhs8ass83 377 Max-Forwards: 70 378 To: "Conference 123" 379 From: Carol ;tag=32331 380 Call-ID: d432fa84b4c76e66710 381 CSeq: 2 REFER 382 Contact: 383 Refer-To: 384 Refer-Sub: false 385 Require: multiple-refer, norefersub 386 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 387 Allow-Events: dialog 388 Accept: application/sdp, message/sipfrag 389 Content-Type: application/resource-lists+xml 390 Content-Disposition: recipient-list 391 Content-Length: 362 392 Content-ID: 394 395 397 398 399 400 401 402 404 4. Update to RFC 5368 406 This section updates the second paragraph in section 7 of [RFC5368], 407 by allowing usage of either a MIME Content-ID header field or a SIP 408 Content-ID header field to label the body part or the message-body 409 carrying the URI list. 411 OLD TEXT: 413 The Refer-To header field of a REFER request with multiple REFER- 414 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource 415 Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part 416 that carries the URI list. The REFER-Issuer SHOULD NOT include any 417 particular URI more than once in the URI list. 419 NEW TEXT: 421 The Refer-To header field of a REFER request with multiple REFER- 422 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource 423 Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part 424 or message-body that carries the URI list. The REFER-Issuer SHOULD 425 NOT include any particular URI more than once in the URI list. The 426 REFER request can use either a MIME Content-ID header field [RFC4483] 427 or a SIP Content-ID header field [RFCXXXX] to label the body part or 428 the message-body. 430 5. Update to RFC 5621 432 This section updates section 9.1 of [RFC5621], by allowing a Content- 433 ID URL to reference a message-body and the related metadata 434 (Section 3.3), in addition to allowing a reference to a body part. 436 OLD TEXT: 438 Content-ID URLs allow creating references to body parts. A given 439 Content-ID URL [RFC2392], which can appear in a header field or 440 within a body part (e.g., in an SDP attribute), points to a 441 particular body part. 443 NEW TEXT: 445 Content-ID URLs allow the creation of references to body parts or 446 message-bodies (and the header fields describing the 447 message-bodies). A given Content-ID URL [RFC2392], which can appear 448 in a header field or within a body part (e.g., in an SDP attribute), 449 points to a particular body part or the message-body (and the 450 header fields describing the message-body). 452 6. Update to RFC 6442 454 This section updates the second paragraph in section 3.1 of 455 [RFC6442], by allowing usage of either a MIME Content-ID header field 456 or a SIP Content-ID header field to label the body part or the 457 message-body carrying the location data. 459 OLD TEXT: 461 In Figure 1, Alice is both the Target and the LS that is conveying 462 her location directly to Bob, who acts as an LR. This conveyance is 463 point-to-point: it does not pass through any SIP-layer intermediary. 464 A Location Object appears by-value in the initial SIP request as a 465 MIME body, and Bob responds to that SIP request as appropriate. 466 There is a 'Bad Location Information' response code introduced within 467 this document to specifically inform Alice if she conveys bad 468 location to Bob (e.g., Bob "cannot parse the location provided", or 469 "there is not enough location information to determine where Alice 470 is"). 472 NEW TEXT: 474 In Figure 1, Alice is both the Target and the LS that is conveying 475 her location directly to Bob, who acts as an LR. This conveyance is 476 point-to-point: it does not pass through any SIP-layer intermediary. 477 A Location Object appears by-value in the initial SIP request as a 478 MIME body, and Bob responds to that SIP request as appropriate. 479 Either a MIME Content-ID header field [RFC4483] or the SIP Content-ID 480 header field [RFCXXXX] MUST be used to label the location 481 information. There is a 'Bad Location Information' response code 482 introduced within this document to specifically inform Alice if she 483 conveys bad location to Bob (e.g., Bob "cannot parse the location 484 provided", or "there is not enough location information to determine 485 where Alice is"). 487 7. Security considerations 489 The Content-ID header field value MUST NOT reveal sensitive user 490 information. 492 If the message-body associated with the Content-ID header field is an 493 encrypted body, it MUST NOT be possible to derive a key that can be 494 used to decrypt the body from the Content-ID header field value. 496 8. IANA considerations 498 This specification registers a new SIP header field according to the 499 procedures in [RFC3261]. 501 8.1. Header field 503 The header field described in Section 3 has been registered in the 504 "Header Fields" sub-registry of the "Session Initiation Protocol 505 (SIP) Parameters" registry by adding a row with these values: 507 [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this 508 document when publishing] 510 Header Name: Content-ID 512 compact: 514 Reference: RFCXXXX 516 9. Change log 518 [RFC EDITOR NOTE: Please remove this section when publishing] 520 Changes from draft-ietf-sipcore-content-id-07 522 o Updates to affected RFCs. 523 o Editorial changes and clarifications based on IESG review. 525 Changes from draft-ietf-sipcore-content-id-06 527 o Editorial changes and clarifications based on Gen-ART review from 528 Elwyn Davies. 530 Changes from draft-ietf-sipcore-content-id-05 532 o Changes based on AD comments from Ben Campell: 533 o - Clarifying that Content-ID header field value is unique within 534 the scope of a SIP message. 536 Changes from draft-ietf-sipcore-content-id-04 538 o Minor editorial fix. 540 Changes from draft-ietf-sipcore-content-id-03 542 o Changes based on doc shepard review: 543 o - Reference to RFC 5234 added. 544 o - SIP message example added. 545 o - Editorial changes. 547 Changes from draft-ietf-sipcore-content-id-02 548 o Editorial changes based on comments from Paul Kyzivat. 550 Changes from draft-ietf-sipcore-content-id-01 552 o Update to RFC 5621 added. 553 o Editorial changes. 555 10. References 557 10.1. Normative references 559 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 560 Extensions (MIME) Part One: Format of Internet Message 561 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 562 . 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, 566 DOI 10.17487/RFC2119, March 1997, . 569 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 570 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 571 . 573 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 574 Specifications: ABNF", STD 68, RFC 5234, 575 DOI 10.17487/RFC5234, January 2008, . 578 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 579 DOI 10.17487/RFC5322, October 2008, . 582 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 583 A., Peterson, J., Sparks, R., Handley, M., and E. 584 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 585 DOI 10.17487/RFC3261, June 2002, . 588 [RFC5621] Camarillo, G., "Message Body Handling in the Session 589 Initiation Protocol (SIP)", RFC 5621, 590 DOI 10.17487/RFC5621, September 2009, . 593 10.2. Informative references 595 [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., 596 and H. Khartabil, "Referring to Multiple Resources in the 597 Session Initiation Protocol (SIP)", RFC 5368, 598 DOI 10.17487/RFC5368, October 2008, . 601 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 602 for the Session Initiation Protocol", RFC 6442, 603 DOI 10.17487/RFC6442, December 2011, . 606 Authors' Addresses 608 Christer Holmberg 609 Ericsson 610 Hirsalantie 11 611 Jorvas 02420 612 Finland 614 Email: christer.holmberg@ericsson.com 616 Ivo Sedlacek 617 Ericsson 618 Sokolovska 79 619 Praha 18600 620 Czech Republic 622 Email: ivo.sedlacek@ericsson.com