idnits 2.17.1 draft-ietf-sipcore-content-id-10.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 (September 2, 2017) is 2426 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 483, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 484, 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 September 2, 2017 6 Expires: March 6, 2018 8 Content-ID header field in Session Initiation Protocol (SIP) 9 draft-ietf-sipcore-content-id-10 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 6, 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, such as [RFC5368], contain examples 140 that show usage of a SIP Content-ID header field referencing a 141 complete message-body, even though such usage has never been 142 specified. Many implementors have interpreted these examples to 143 indicate that such usage is allowed by the corresponding 144 specification, despite the absence of language allowing it. This 145 document updates the normative language in the affected documents to 146 explicitly allow such usage. 148 1.4. Consequences 150 The examples below shows the consequences of the problem described 151 above. 153 1.4.1. Example 1 155 If a User Agent Client (UAC) sends an INVITE request conveying 156 location as specified in [RFC6442], if the UAC decides not to include 157 an SDP offer, and if the location is conveyed by value, then the UAC 158 needs to include only one MIME entity in the INVITE request. This 159 MIME entity can be, for example, of the application/pidf+xml MIME 160 type. 162 However, due to [RFC6442] requiring inclusion of a Geolocation header 163 field referencing the body part with the location information, the 164 UAC includes a multipart message-body with single body part in the 165 INVITE request, and includes the location information of application/ 166 pidf+xml MIME type and an associated Content-ID header field in the 167 body part. 169 Example message (SIP INVITE): 171 INVITE sips:bob@biloxi.example.com SIP/2.0 172 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 173 Max-Forwards: 70 174 To: Bob 175 From: Alice ;tag=9fxced76sl 176 Call-ID: 3848276298220188511@atlanta.example.com 177 Geolocation: 178 Geolocation-Routing: no 179 Accept: application/sdp, application/pidf+xml 180 CSeq: 31862 INVITE 181 Contact: 182 Content-Type: multipart/mixed; boundary=boundary1 183 Content-Length: ... 185 --boundary1 186 Content-Type: application/pidf+xml 187 Content-ID: 189 190 199 200 201 202 203 204 32.86726 -97.16054 205 206 207 208 209 false 210 211 2010-11-14T20:00:00Z 212 213 214 802.11 215 216 mac:1234567890ab 217 2010-11-04T20:57:29Z 218 219 220 --boundary1-- 222 1.4.2. Example 2 224 If a UAC sends an REFER request including a list of targets as 225 specified in [RFC5368], then the UAC needs to include only one MIME 226 entity in the REFER request. This MIME entity is of the application/ 227 resource-lists+xml MIME type. 229 However, due to [RFC5368] requiring inclusion of a Refer-To header 230 field referencing the body part containing the list of targets, the 231 UAC includes a multipart message-body with single body part in the 232 REFER request, and includes the list of targets of application/ 233 resource-lists+xml MIME type and an associated Content-ID header 234 field in the body part. 236 Example message (SIP REFER): 238 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 239 Via: SIP/2.0/TCP client.chicago.example.com;branch=z9hG4bKhjhs8ass83 240 Max-Forwards: 70 241 To: "Conference 123" 242 From: Carol ;tag=32331 243 Call-ID: d432fa84b4c76e66710 244 CSeq: 2 REFER 245 Contact: 246 Refer-To: 247 Refer-Sub: false 248 Require: multiple-refer, norefersub 249 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 250 Allow-Events: dialog 251 Accept: application/sdp, message/sipfrag 252 Content-Type: multipart/mixed; boundary=boundary1 253 Content-Length: ... 255 --boundary1 256 Content-Type: application/resource-lists+xml 257 Content-Disposition: recipient-list 258 Content-ID: 260 261 265 266 267 268 269 270 271 --boundary1-- 273 1.5. Solution 275 In order to solve the problems described above, this document: 277 o Specifies and registers the Content-ID header field as a SIP 278 header field; and 279 o Specifies that, when used as a SIP header field, the Content-ID 280 header field identifies the complete message-body, and metadata 281 provided by some additional SIP header fields, of the SIP message; 282 and 284 o Updates [RFC5621], to enable a Content-ID URL to reference a 285 complete message-body and metadata provided by some additional SIP 286 header fields. 287 o Updates [RFC5368] and [RFC6442] by adding explicit text saying 288 that a SIP Content-ID header field can be used. 290 1.6. Backward compatibility 292 If an existing specification only defines the usage of a multipart 293 message-body for carrying a single body part to be referenced by a 294 Content-ID URL, implementations MUST NOT carry the MIME entity in a 295 non-multipart message-body unless the specification is updated to 296 explicitly allow it. 298 2. Conventions 300 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 301 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 302 document are to be interpreted as described in [RFC2119]. 304 3. Content-ID header field 306 3.1. Introduction 308 This section defines the usage of the Content-ID header field for 309 SIP. 311 3.2. Syntax 313 The ABNF [RFC5234] for the Content-ID header field is: 315 Content-ID = "Content-ID" HCOLON msg-id 317 msg-id = "<" id-left "@" id-right ">" 319 NOTE: id-left and id-right are specified in [RFC5322]. HCOLON is 320 defined in [RFC3261]. 322 NOTE: When used in a SIP header field, the msg-id syntax has been 323 simplified, compared to the syntax in [RFC5322], to disallow the use 324 of comments and to adopt to the SIP usage of leading white space. 326 The value of Content-Id header field value must be unique in the 327 context of a given SIP message, including any embedded MIME 328 Content-Id header field values. Note that the SIP Content-ID header 329 field value is not expected to be unique among all SIP messages; it 330 has no meaning outside of the message in which it is included. 332 3.3. Semantics 334 The Content-ID header field included in the header fields of a SIP 335 message identifies the message-body of the SIP message, and the 336 metadata provided by: 338 o a MIME-Version header field, if included in the header fields of 339 the SIP message; and 340 o any 'Content-' prefixed header fields (including the Content-ID 341 header field itself) included in the header fields of the SIP 342 message. 344 The Content-ID header field can be included in any SIP message which 345 is allowed to contain a message-body. 347 NOTE: The message-body identified by the Content-ID header field can 348 be a non-multipart message-body or a multipart message-body. 350 3.4. Procedures 352 3.4.1. User Agent (UA) procedures 354 A UA MAY include a Content-ID header field in any SIP message that is 355 allowed to contain a message-body. 357 A UA MUST NOT include a Content-ID header field in any SIP message 358 that is not allowed to contain a message-body. 360 The UA MUST set the value of the Content-ID header field to a value 361 that is unique in the context of the SIP message. 363 3.4.2. Proxy procedures 365 A proxy MUST NOT add a Content-ID header field in a SIP message. 367 A proxy MUST NOT modify a Content-ID header field included in a SIP 368 message. 370 A proxy MUST NOT delete a Content-ID header field from a SIP message. 372 3.4.3. Example 374 The figure shows an example from [RFC5368], where the SIP Content-ID 375 header field is used to reference the message-body (non-multipart) of 376 a SIP message. 378 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 379 Via: SIP/2.0/TCP client.chicago.example.com 380 ;branch=z9hG4bKhjhs8ass83 381 Max-Forwards: 70 382 To: "Conference 123" 383 From: Carol ;tag=32331 384 Call-ID: d432fa84b4c76e66710 385 CSeq: 2 REFER 386 Contact: 387 Refer-To: 388 Refer-Sub: false 389 Require: multiple-refer, norefersub 390 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 391 Allow-Events: dialog 392 Accept: application/sdp, message/sipfrag 393 Content-Type: application/resource-lists+xml 394 Content-Disposition: recipient-list 395 Content-Length: 362 396 Content-ID: 398 399 401 402 403 404 405 406 408 4. Update to RFC 5368 410 This section updates the second paragraph in section 7 of [RFC5368], 411 by allowing usage of either a MIME Content-ID header field or a SIP 412 Content-ID header field to label the body part or the message-body 413 carrying the URI list. 415 OLD TEXT: 417 The Refer-To header field of a REFER request with multiple REFER- 418 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource 419 Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part 420 that carries the URI list. The REFER-Issuer SHOULD NOT include any 421 particular URI more than once in the URI list. 423 NEW TEXT: 425 The Refer-To header field of a REFER request with multiple REFER- 426 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource 427 Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part 428 or message-body that carries the URI list. The REFER-Issuer SHOULD 429 NOT include any particular URI more than once in the URI list. The 430 REFER request can use either a MIME Content-ID header field [RFC4483] 431 or a SIP Content-ID header field [RFCXXXX] to label the body part or 432 the message-body. 434 5. Update to RFC 5621 436 This section updates section 9.1 of [RFC5621], by allowing a Content- 437 ID URL to reference a message-body and the related metadata 438 (Section 3.3), in addition to allowing a reference to a body part. 440 OLD TEXT: 442 Content-ID URLs allow creating references to body parts. A given 443 Content-ID URL [RFC2392], which can appear in a header field or 444 within a body part (e.g., in an SDP attribute), points to a 445 particular body part. 447 NEW TEXT: 449 Content-ID URLs allow the creation of references to body parts or 450 message-bodies (and the header fields describing the 451 message-bodies). A given Content-ID URL [RFC2392], which can appear 452 in a header field or within a body part (e.g., in an SDP attribute), 453 points to a particular body part or the message-body (and the 454 header fields describing the message-body). 456 6. Update to RFC 6442 458 This section updates the second paragraph in section 3.1 of 459 [RFC6442], by allowing usage of either a MIME Content-ID header field 460 or a SIP Content-ID header field to label the body part or the 461 message-body carrying the location data. 463 OLD TEXT: 465 In Figure 1, Alice is both the Target and the LS that is conveying 466 her location directly to Bob, who acts as an LR. This conveyance is 467 point-to-point: it does not pass through any SIP-layer intermediary. 468 A Location Object appears by-value in the initial SIP request as a 469 MIME body, and Bob responds to that SIP request as appropriate. 470 There is a 'Bad Location Information' response code introduced within 471 this document to specifically inform Alice if she conveys bad 472 location to Bob (e.g., Bob "cannot parse the location provided", or 473 "there is not enough location information to determine where Alice 474 is"). 476 NEW TEXT: 478 In Figure 1, Alice is both the Target and the LS that is conveying 479 her location directly to Bob, who acts as an LR. This conveyance is 480 point-to-point: it does not pass through any SIP-layer intermediary. 481 A Location Object appears by-value in the initial SIP request as a 482 MIME body, and Bob responds to that SIP request as appropriate. 483 Either a MIME Content-ID header field [RFC4483] or the SIP Content-ID 484 header field [RFCXXXX] MUST be used to label the location 485 information. There is a 'Bad Location Information' response code 486 introduced within this document to specifically inform Alice if she 487 conveys bad location to Bob (e.g., Bob "cannot parse the location 488 provided", or "there is not enough location information to determine 489 where Alice is"). 491 7. Security considerations 493 The Content-ID header field value MUST NOT reveal sensitive user 494 information. 496 If the message-body associated with the Content-ID header field is an 497 encrypted body, it MUST NOT be possible to derive a key that can be 498 used to decrypt the body from the Content-ID header field value. 500 8. IANA considerations 502 This specification registers a new SIP header field according to the 503 procedures in [RFC3261]. 505 8.1. Header field 507 The header field described in Section 3 has been registered in the 508 "Header Fields" sub-registry of the "Session Initiation Protocol 509 (SIP) Parameters" registry by adding a row with these values: 511 [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this 512 document when publishing] 514 Header Name: Content-ID 516 compact: 518 Reference: RFCXXXX 520 9. Change log 522 [RFC EDITOR NOTE: Please remove this section when publishing] 524 Changes from draft-ietf-sipcore-content-id-09 526 o Editorial change based on comment from Adam Roach. 528 Changes from draft-ietf-sipcore-content-id-08 530 o Editorial change based on comment from Ben Campbell. 532 Changes from draft-ietf-sipcore-content-id-07 534 o Updates to affected RFCs. 535 o Editorial changes and clarifications based on IESG review. 537 Changes from draft-ietf-sipcore-content-id-06 539 o Editorial changes and clarifications based on Gen-ART review from 540 Elwyn Davies. 542 Changes from draft-ietf-sipcore-content-id-05 544 o Changes based on AD comments from Ben Campbell: 545 o - Clarifying that Content-ID header field value is unique within 546 the scope of a SIP message. 548 Changes from draft-ietf-sipcore-content-id-04 550 o Minor editorial fix. 552 Changes from draft-ietf-sipcore-content-id-03 553 o Changes based on doc shepherd review: 554 o - Reference to RFC 5234 added. 555 o - SIP message example added. 556 o - Editorial changes. 558 Changes from draft-ietf-sipcore-content-id-02 560 o Editorial changes based on comments from Paul Kyzivat. 562 Changes from draft-ietf-sipcore-content-id-01 564 o Update to RFC 5621 added. 565 o Editorial changes. 567 10. References 569 10.1. Normative references 571 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 572 Extensions (MIME) Part One: Format of Internet Message 573 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 574 . 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, 578 DOI 10.17487/RFC2119, March 1997, . 581 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 582 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 583 . 585 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 586 Specifications: ABNF", STD 68, RFC 5234, 587 DOI 10.17487/RFC5234, January 2008, . 590 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 591 DOI 10.17487/RFC5322, October 2008, . 594 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 595 A., Peterson, J., Sparks, R., Handley, M., and E. 596 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 597 DOI 10.17487/RFC3261, June 2002, . 600 [RFC5621] Camarillo, G., "Message Body Handling in the Session 601 Initiation Protocol (SIP)", RFC 5621, 602 DOI 10.17487/RFC5621, September 2009, . 605 10.2. Informative references 607 [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., 608 and H. Khartabil, "Referring to Multiple Resources in the 609 Session Initiation Protocol (SIP)", RFC 5368, 610 DOI 10.17487/RFC5368, October 2008, . 613 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 614 for the Session Initiation Protocol", RFC 6442, 615 DOI 10.17487/RFC6442, December 2011, . 618 Authors' Addresses 620 Christer Holmberg 621 Ericsson 622 Hirsalantie 11 623 Jorvas 02420 624 Finland 626 Email: christer.holmberg@ericsson.com 628 Ivo Sedlacek 629 Ericsson 630 Sokolovska 79 631 Praha 18600 632 Czech Republic 634 Email: ivo.sedlacek@ericsson.com