idnits 2.17.1 draft-ietf-sipcore-content-id-02.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 (April 25, 2017) is 2557 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 April 25, 2017 6 Expires: October 27, 2017 8 Content-ID header field in Session Initiation Protocol (SIP) 9 draft-ietf-sipcore-content-id-02 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 refer a complete message-body and 16 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 October 27, 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. Referring a body part . . . . . . . . . . . . . . . . . . 3 55 1.3. Problem statement . . . . . . . . . . . . . . . . . . . . 3 56 1.4. Consequencies . . . . . . . . . . . . . . . . . . . . . . 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 4. Update to RFC 5621 . . . . . . . . . . . . . . . . . . . . . 6 69 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 70 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. Header field . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8. Normative references . . . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 1.1. Identifying a body part 80 A SIP message consists of a start-line, one or more header fields, an 81 empty line indicating the end of the header fields, and an optional 82 message-body, as specified in [RFC3261]. 84 The message-body can be a non-multipart message-body or a multipart 85 message-body as specified in [RFC3261]. 87 [RFC5621] defines generic handling of a multipart message-body in a 88 SIP message. 90 A multipart message-body contains zero, one or several body parts, 91 encoded using [RFC2045] format. 93 A body part in the multipart message-body is described using header 94 fields such as Content-Disposition, Content-Encoding, and Content- 95 Type, which provide information on the content of the body part, as 96 specified in [RFC5621]. A body part in the multipart message-body 97 can also contain a Content-ID header field with an ID value uniquely 98 identifying the body part, as specified in [RFC2045]. 100 1.2. Referring a body part 102 A SIP header field can refer a body part using a Content-ID URL, as 103 specified in [RFC5621]. 105 The Content-ID URL is specified in [RFC2392]. [RFC2392] specifies 106 how to identify the body part referred by a Content-ID URL. The 107 Content-ID URL value is included in the Content-ID header field of 108 the body part. 110 Examples of SIP header fields referring a body part using a Content- 111 ID URL are: 113 o [RFC6442] specifies how a Geolocation header field refers a body 114 part using a Content-ID URL, for providing location. 115 o [RFC5368] specifies how a Refer-To header field refers a body part 116 using a Content-ID URL, to provide a list of targets. 118 1.3. Problem statement 120 It is currently not specified how to uniquely identify a complete 121 message-body of a SIP message using a Content-ID header field, and 122 how to refer a complete message-body using a Content-ID URL. 124 1.4. Consequencies 126 The examples below shows the consequencies of the problem described 127 above. 129 1.4.1. Example 1 131 If a UAC sends an INVITE request conveying location as specified in 132 [RFC6442], if the UAC decides not to include an SDP offer, and if the 133 location is conveyed by value, then the UAC needs to include one 134 content only in the INVITE request. This content can be e.g. of the 135 application/pidf+xml MIME type. 137 However, due to [RFC6442] requiring inclusion of a Geolocation header 138 field referring the body part with the location information, the UAC 139 includes a multipart message-body with single body part in the INVITE 140 request, and includes the location information of application/ 141 pidf+xml MIME type and an associated Content-ID header field in the 142 body part. 144 1.4.2. Example 2 146 If a UAC sends an REFER request including a list of targets as 147 specified in [RFC5368], then the UAC needs to include one content 148 only in the REFER request. This content is of the application/ 149 resource-lists+xml MIME type. 151 However, due to [RFC5368] requiring inclusion of a Refer-To header 152 field referring the body part containing the list of targets, the UAC 153 includes a multipart message-body with single body part in the REFER 154 request, and includes the list of targets of application/resource- 155 lists+xml MIME type and an associated Content-ID header field in the 156 body part. 158 1.5. Solution 160 In order to solve the problems described above, this document: 162 o Specifies and registers the Content-ID header field as a SIP 163 header field; and 164 o Specifies that, when used as a SIP header field, the Content-ID 165 header field identifies the complete message-body, and metadata 166 provided by some additional SIP header fields, of the SIP message; 167 and 168 o Updates [RFC5621], to enable a Content-ID URL to refer a complete 169 message-body and metadata provided by some additional SIP header 170 fields. 172 NOTE: In [RFC5621], the Content-ID URL refers a specific body part 173 only. 175 2. Conventions 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 3. Content-ID header field 183 3.1. Introduction 185 This section defines the usage of the Content-ID header field for 186 SIP. 188 3.2. Syntax 190 The ABNF for the Content-ID header fields is: 192 Content-ID = "Content-ID" HCOLON msg-id 194 msg-id = "<" id-left "@" id-right ">" 196 NOTE: id-left and id-right are specified in [RFC5322]. 198 NOTE: When used in a SIP header field, the msg-id syntax has been 199 simplified compared to the syntax in [RFC5322]. 201 3.3. Semantics 203 The Content-ID header field included in the header fields of a SIP 204 message identifies the message-body of the SIP message, and the 205 metadata provided by: 207 o the Content-ID header field itself; 208 o a MIME-Version header field, if included in the header fields of 209 the SIP message; 210 o a Content-Disposition header field, if included in the header 211 fields of the SIP message; 212 o a Content-Encoding header field, if included in the header fields 213 of the SIP message; 214 o a Content-Language header field, if included in the header fields 215 of the SIP message; 216 o a Content-Length header field, if included in the header fields of 217 the SIP message; and 218 o a Content-Type header field, if included in the header fields of 219 the SIP message. 221 The Content-ID header field can be included in any SIP message which 222 is allowed to contain a message-body. 224 3.4. Procedures 226 3.4.1. UA procedures 228 A UA MAY include a Content-ID header field in any SIP message which 229 is allowed to contain a message-body. 231 A UA MUST NOT include a Content-ID header field in any SIP message 232 which is not allowed to contain a message-body. 234 The UA MUST set the value of the Content-ID header field to a 235 globally unique value. 237 3.4.2. Proxy procedures 239 A proxy MUST NOT add a Content-ID header field in a SIP message. 241 A proxy MUST NOT modify a Content-ID header field included in a SIP 242 message. 244 A proxy MUST NOT delete a Content-ID header field from a SIP message. 246 4. Update to RFC 5621 248 This section updates section 9.1 of [RFC5621], by allowing a Content- 249 ID URL to reference a message-body and the related metadata 250 (Section 3.3), in addition to allowing to reference to a body part.A 252 OLD TEXT: 254 Content-ID URLs allow creating references to body parts. A given 255 Content-ID URL [RFC2392], which can appear in a header field or 256 within a body part (e.g., in an SDP attribute), points to a 257 particular body part. 259 NEW TEXT: 261 Content-ID URLs allow creating references to body parts or 262 message-bodies (and the header fields describing the 263 message-bodies). A given Content-ID URL [RFC2392], which can appear 264 in a header field or within a body part (e.g., in an SDP attribute), 265 points to a particular body part or the message-body (and the 266 header fields describing the message-body). 268 5. Security considerations 270 The Content-ID header field value MUST NOT reveal sensitive user 271 information. 273 If the message-body associated with the Content-ID header field is an 274 encrypted body, it MUST NOT be possible to derive a key that can be 275 used to decrypt the body from the Content-ID header field value. 277 6. IANA considerations 279 This specification registers a new SIP header field according to the 280 procedures in [RFC3261]. 282 6.1. Header field 284 [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this 285 document when publishing] 287 RFC Number: RFC XXXX 289 Header Field Name: Content-ID 291 Compact Form: none 293 7. Change log 295 [RFC EDITOR NOTE: Please remove this section when publishing] 297 Changes from draft-ietf-sipcore-content-id-01 299 o Update to RFC 5621 added. 300 o Editorial changes. 302 8. Normative references 304 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 305 Extensions (MIME) Part One: Format of Internet Message 306 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 307 . 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, 312 . 314 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 315 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 316 . 318 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 319 DOI 10.17487/RFC5322, October 2008, 320 . 322 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 323 A., Peterson, J., Sparks, R., Handley, M., and E. 324 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 325 DOI 10.17487/RFC3261, June 2002, 326 . 328 [RFC5368] Camarillo, G., Niemi, A., Isomaki, M., Garcia-Martin, M., 329 and H. Khartabil, "Referring to Multiple Resources in the 330 Session Initiation Protocol (SIP)", RFC 5368, 331 DOI 10.17487/RFC5368, October 2008, 332 . 334 [RFC5621] Camarillo, G., "Message Body Handling in the Session 335 Initiation Protocol (SIP)", RFC 5621, 336 DOI 10.17487/RFC5621, September 2009, 337 . 339 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 340 for the Session Initiation Protocol", RFC 6442, 341 DOI 10.17487/RFC6442, December 2011, 342 . 344 Authors' Addresses 346 Christer Holmberg 347 Ericsson 348 Hirsalantie 11 349 Jorvas 02420 350 Finland 352 Email: christer.holmberg@ericsson.com 354 Ivo Sedlacek 355 Ericsson 356 Sokolovska 79 357 Praha 18600 358 Czech Republic 360 Email: ivo.sedlacek@ericsson.com