idnits 2.17.1 draft-ietf-appsawg-media-type-suffix-regs-03.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3023, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3023, updated by this document, for RFC5378 checks: 1999-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 11, 2012) is 4216 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2008' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X891.2005' -- Possible downref: Non-RFC (?) normative reference: ref. 'WBXML' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZIP' ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hansen 3 Internet-Draft AT&T Laboratories 4 Updates: 3023 (if approved) A. Melnikov 5 Intended status: BCP Isode Ltd 6 Expires: March 15, 2013 September 11, 2012 8 Additional Media Type Structured Syntax Suffixes 9 draft-ietf-appsawg-media-type-suffix-regs-03 11 Abstract 13 A content media type name sometimes includes partitioned meta- 14 information distinguish by a Structured Syntax, to permit noting an 15 attribute of the media as a suffix to the name. This document 16 defines several Structured Syntax Suffixes for use with media type 17 registrations. In particular, it defines and registers the "+json", 18 "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax 19 Suffixes, and updates the "+xml" Message Type Structured Syntax 20 Suffix registration. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 15, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. When to Use these Structured Syntax Suffixes . . . . . . . . . 3 58 3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 4 59 3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 4 60 3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 5 61 3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 6 62 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 8 63 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 9 64 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 10 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 [RFC3023] created the +xml suffix convention that can be used when 76 defining names for media types whose representation uses XML 77 underneath. That is, they could have been successfully parsed as if 78 the media type had been application/xml in addition to their being 79 parsed as their media type that is using the +xml suffix. 80 [I-D.ietf-appsawg-media-type-regs] defines the Message Type 81 Structured Syntax Suffixes registry to be used for such Structured 82 Syntax Suffixes. 84 A variety of Structured Syntax Suffixes have already been used in 85 some media type registrations, in particular "+json", "+der", 86 "+fastinfoset" and "+wbxml". This document defines and registers 87 these Structured Syntax Suffixes in the Structured Syntax Suffix 88 registry, along with "+ber" and "+zip". In addition, this document 89 updates the "+xml" Structured Syntax Suffix registration. 91 Discussion of this document should occur in the Apps Area Working 92 Group (apps-discuss@ietf.org). [RFC Editor note: remove this 93 paragraph.] 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. When to Use these Structured Syntax Suffixes 101 Each of the Structured Syntax Suffixes defined in this document is 102 appropriate for use when the media type identifies the semantics of 103 the protocol payload. That is, knowing the semantics of the specific 104 media type provides for more specific processing of the content than 105 that afforded by generic processing of the underlying representation. 107 At the same time, using the suffix allows receivers of the media 108 types to do generic processing of the underlying representation in 109 cases where 111 they do not need to perform special handling of the particular 112 semantics of the exact media type, and, 114 there is no special knowledge needed by such a generic processor 115 in order to parse that underlying representation other than what 116 would be needed to parse any example of that underlying 117 representation. 119 3. Initial Structured Syntax Suffix Definitions 121 3.1. The +json Structured Syntax Suffix 123 [RFC4627] defines the "application/json" media type. The suffix 124 "+json" MAY be used with any media type whose representation follows 125 that established for "application/json". The Message Type Structured 126 Syntax Suffix registration form follows. See 127 [I-D.ietf-appsawg-media-type-regs] for definitions of each of the 128 registration form headings. 130 Name: JavaScript Object Notation (JSON) 132 +suffix: +json 134 References: [RFC4627] 136 Encoding considerations: Per [RFC4627], JSON is allowed to be 137 represented using UTF-8, UTF-16, or UTF-32. When 138 JSON is written in UTF-8, JSON is 8bit compatible 139 ([RFC2045]). When JSON is written in UTF-16 or 140 UTF-32, JSON is binary ([RFC2045]). 142 Fragment identifier considerations: 144 The syntax and semantics of fragment 145 identifiers specified for +json SHOULD be as 146 specified for "application/json". (At 147 publication of this document, there is no 148 fragment identification syntax defined for 149 "application/json".) 151 The syntax and semantics for fragment 152 identifiers for a specific "xxx/yyy+json" 153 SHOULD be processed as follows: 155 For cases defined in +json, where the 156 fragment identifier resolves per the +json 157 rules, then as specified in +json. 159 For cases defined in +json, where the 160 fragment identifier does not resolve per 161 the +json rules, then as specified in "xxx/ 162 yyy+json". 164 For cases not defined in +json, then as 165 specified in "xxx/yyy+json". 167 Interoperability considerations: n/a 169 Security considerations: See [RFC4627] 171 Contact: Apps Area Working Group (apps-discuss@ietf.org) 173 Author/Change controller: The Apps Area Working Group has change 174 control over this registration. 176 3.2. The +ber Structured Syntax Suffixes 178 The ITU defined the Basic Encoding Rules (BER) message transfer 179 syntax in [ITU.X690.2008]. The suffix "+ber" MAY be used with any 180 media type whose representation follows the BER message transfer 181 syntax. The Message Type Structured Syntax Suffix registration form 182 for +ber follows: 184 Name: Basic Encoding Rules (BER) message transfer 185 syntax 187 +suffix: +ber 189 References: [ITU.X690.2008] 191 Encoding considerations: BER is a binary encoding. 193 Fragment identifier considerations: 195 At publication of this document, there is no 196 fragment identification syntax defined for 197 +ber. 199 The syntax and semantics for fragment 200 identifiers for a specific "xxx/yyy+ber" 201 SHOULD be processed as follows: 203 For cases defined in +ber, where the 204 fragment identifier resolves per the +ber 205 rules, then as specified in +ber. 207 For cases defined in +ber, where the 208 fragment identifier does not resolve per 209 the +ber rules, then as specified in "xxx/ 210 yyy+ber". 212 For cases not defined in +ber, then as 213 specified in "xxx/yyy+ber". 215 Interoperability considerations: n/a 217 Security considerations: Each individual media type registered with 218 a +ber suffix can have additional security 219 considerations. 221 BER has a type-length-value structure, and it is 222 easy to construct malicious content with invalid 223 length fields that can cause buffer overrun 224 conditions. 226 Some BER schema allow for arbitrary levels of 227 nesting, which may make it possible to construct 228 malicious content that will cause a stack 229 overflow. 231 Interpreters of the BER structures should be 232 aware of these issues and should take appropriate 233 measures to guard against buffer overflows and 234 stack overruns in particular and malicious 235 content in general. 237 Contact: Apps Area Working Group (apps-discuss@ietf.org) 239 Author/Change controller: The Apps Area Working Group has change 240 control over this registration. 242 3.3. The +der Structured Syntax Suffixes 244 The ITU defined the Distinguished Encoding Rules (DER) message 245 transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used 246 with any media type whose representation follows the DER message 247 transfer syntax. The Message Type Structured Syntax Suffix 248 registration form for +der follows: 250 Name: Distinguished Encoding Rules (DER) message 251 transfer syntax 253 +suffix: +der 255 References: [ITU.X690.2008] 256 Encoding considerations: DER is a binary encoding. 258 Fragment identifier considerations: 260 At publication of this document, there is no 261 fragment identification syntax defined for 262 +der. 264 The syntax and semantics for fragment 265 identifiers for a specific "xxx/yyy+der" 266 SHOULD be processed as follows: 268 For cases defined in +der, where the 269 fragment identifier resolves per the +der 270 rules, then as specified in +der. 272 For cases defined in +der, where the 273 fragment identifier does not resolve per 274 the +der rules, then as specified in "xxx/ 275 yyy+der". 277 For cases not defined in +der, then as 278 specified in "xxx/yyy+der". 280 Interoperability considerations: n/a 282 Security considerations: Each individual media type registered with 283 a +der suffix can have additional security 284 considerations. 286 DER has a type-length-value structure, and it is 287 easy to construct malicious content with invalid 288 length fields that can cause buffer overrun 289 conditions. 291 Some DER schema allow for arbitrary levels of 292 nesting, which may make it possible to construct 293 malicious content that will cause a stack 294 overflow. 296 Interpreters of the DER structures should be 297 aware of these issues and should take appropriate 298 measures to guard against buffer overflows and 299 stack overruns in particular and malicious 300 content in general. 302 Contact: Apps Area Working Group (apps-discuss@ietf.org) 304 Author/Change controller: The Apps Area Working Group has change 305 control over this registration. 307 3.4. The +fastinfoset Structured Syntax Suffix 309 The ITU defined the Fast Infoset document format as a binary 310 representation of the XML Information Set in [ITU.X891.2005]. These 311 documents further define the "application/fastinfoset" media type. 312 The suffix "+fastinfoset" MAY be used with any media type whose 313 representation follows that established for "application/ 314 fastinfoset". The Message Type Structured Syntax Suffix registration 315 form follows: 317 Name: Fast Infoset document format 319 +suffix: +fastinfoset 321 References: [ITU.X891.2005] 323 Encoding considerations: Fast Infoset is a binary encoding. The 324 binary, quoted-printable and base64 content- 325 transfer-encodings are suitable for use with Fast 326 Infoset. 328 Fragment identifier considerations: 330 The syntax and semantics of fragment 331 identifiers specified for +fastinfoset SHOULD 332 be as specified for "application/fastinfoset". 333 (At publication of this document, there is no 334 fragment identification syntax defined for 335 "application/fastinfoset".) 337 The syntax and semantics for fragment 338 identifiers for a specific "xxx/ 339 yyy+fastinfoset" SHOULD be processed as 340 follows: 342 For cases defined in +fastinfoset, where 343 the fragment identifier resolves per the 344 +fastinfoset rules, then as specified in 345 +fastinfoset. 347 For cases defined in +fastinfoset, where 348 the fragment identifier does not resolve 349 per the +fastinfoset rules, then as 350 specified in "xxx/yyy+fastinfoset". 352 For cases not defined in +fastinfoset, then 353 as specified in "xxx/yyy+fastinfoset". 355 Interoperability considerations: n/a 357 Security considerations: There are no security considerations 358 inherent in Fast Infoset. Each individual media 359 type registered with a +fastinfoset suffix can 360 have additional security considerations. 362 Contact: Apps Area Working Group (apps-discuss@ietf.org) 364 Author/Change controller: The Apps Area Working Group has change 365 control over this registration. 367 3.5. The +wbxml Structured Syntax Suffix 369 The WAP Forum has defined the WAP Binary XML (WBXML) document format 370 as a binary representation of XML in [WBXML]. This document further 371 defines the "application/vnd.wap.wbxml" media type. The suffix 372 "+wbxml" MAY be used with any media type whose representation follows 373 that established for "application/vnd.wap.wbxml". The Message Type 374 Structured Syntax Suffix registration form follows: 376 Name: WAP Binary XML (WBXML) document format 378 +suffix: +wbxml 380 References: [WBXML] 382 Encoding considerations: WBXML is a binary encoding. 384 Fragment identifier considerations: 386 The syntax and semantics of fragment 387 identifiers specified for +wbxml SHOULD be as 388 specified for "application/vnd.wap.wbxml". 389 (At publication of this document, there is no 390 fragment identification syntax defined for 391 "application/vnd.wap.wbxml".) 392 The syntax and semantics for fragment 393 identifiers for a specific "xxx/yyy+wbxml" 394 SHOULD be processed as follows: 396 For cases defined in +wbxml, where the 397 fragment identifier resolves per the +wbxml 398 rules, then as specified in +wbxml. 400 For cases defined in +wbxml, where the 401 fragment identifier does not resolve per 402 the +wbxml rules, then as specified in 403 "xxx/yyy+wbxml". 405 For cases not defined in +wbxml, then as 406 specified in "xxx/yyy+wbxml". 408 Interoperability considerations: n/a 410 Security considerations: There are no security considerations 411 inherent in WBXML. Each individual media type 412 registered with a +wbxml suffix can have 413 additional security considerations. 415 Contact: Apps Area Working Group (apps-discuss@ietf.org) 417 Author/Change controller: The Apps Area Working Group has change 418 control over this registration. 420 3.6. The +zip Structured Syntax Suffix 422 The ZIP format is a public domain, cross-platform, interoperable file 423 storage and transfer format, originally defined by PKWARE, Inc.; it 424 supports compression and encryption and is used as the underlying 425 representation by a variety of file formats. The media type 426 "application/zip" has been registered for such files. The suffix 427 "+zip" MAY be used with any media type whose representation follows 428 that established for "application/zip". The Message Type Structured 429 Syntax Suffix registration form follows: 431 Name: ZIP file storage and transfer format 433 +suffix: +zip 435 References: [ZIP] 436 Encoding considerations: ZIP is a binary encoding. 438 Fragment identifier considerations: 440 The syntax and semantics of fragment 441 identifiers specified for +zip SHOULD be as 442 specified for "application/zip". (At 443 publication of this document, there is no 444 fragment identification syntax defined for 445 "application/zip".) 447 The syntax and semantics for fragment 448 identifiers for a specific "xxx/yyy+zip" 449 SHOULD be processed as follows: 451 For cases defined in +zip, where the 452 fragment identifier resolves per the +zip 453 rules, then as specified in +zip. 455 For cases defined in +zip, where the 456 fragment identifier does not resolve per 457 the +zip rules, then as specified in "xxx/ 458 yyy+zip". 460 For cases not defined in +zip, then as 461 specified in "xxx/yyy+zip". 463 Interoperability considerations: n/a 465 Security considerations: ZIP files support two forms of encryption: 466 Strong Encryption and AES 128-bit, 192-bit and 467 256-bit encryption; see the specification for 468 further details. Each individual media type 469 registered with a +zip suffix can have additional 470 security considerations. 472 Contact: Apps Area Working Group (apps-discuss@ietf.org) 474 Author/Change controller: The Apps Area Working Group has change 475 control over this registration. 477 4. IANA Considerations 479 See the Message Type Structured Syntax Suffix registration forms in 480 Section 3.1 - Section 3.6. 482 The existing Structured Syntax Suffix registration for "+xml" is 483 modified to include the following 485 Fragment identifier considerations: 487 The syntax and semantics of fragment 488 identifiers specified for +xml SHOULD be as 489 specified for "application/xml". (At 490 publication of this document, the fragment 491 identification syntax considerations for 492 "application/xml" are defined in [RFC3023], 493 sections 5 and 7.) 495 The syntax and semantics for fragment 496 identifiers for a specific "xxx/yyy+xml" 497 SHOULD be processed as follows: 499 For cases defined in +xml, where the 500 fragment identifier resolves per the +xml 501 rules, then as specified in +xml. 503 For cases defined in +xml, where the 504 fragment identifier does not resolve per 505 the +xml rules, then as specified in "xxx/ 506 yyy+xml". 508 For cases not defined in +xml, then as 509 specified in "xxx/yyy+xml". 511 5. Security Considerations 513 See the Security considerations sections found in the Message Type 514 Structured Syntax Suffix registration forms from Section 3.1 - 515 Section 3.5. 517 When updating a + registration care should be taken to review 518 all previously registered xxx/yyy+ media types regarding 519 whether they might be affected by the updated + registration, 520 in particular by introduction of new or changing generic fragment 521 identifier processing rules, as such rules take precedence over 522 media-type-specific rules and thus might break existing registrations 523 of specific media types, as well as particular implementations of 524 applications that process affected media types. Such changes can 525 introduce interoperability and security issues. 527 6. References 528 6.1. Normative References 530 [RFC4627] Crockford, D., "The application/json Media Type for 531 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 533 [ITU.X690.2008] 534 International Telecommunications Union, "Recommendation 535 ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules: 536 Specification of basic encoding Rules (BER), Canonical 537 encoding rules (CER) and Distinguished encoding rules 538 (DER)", ITU-T Recommendation X.690, November 2008. 540 [ITU.X891.2005] 541 International Telecommunications Union, "Recommendation 542 ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications 543 of ASN.1: Fast infoset", ITU-T Recommendation X.891, 544 May 2005. 546 [WBXML] Open Mobile Alliance, "Binary XML Content Format 547 Specification", OMA Wireless Access Protocol WAP-192- 548 WBXML-20010725-a, July 2001. 550 [ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format 551 Specification", PKWARE .ZIP File Format Specification - 552 Version 6.3.2, September 2007. 554 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 555 Extensions (MIME) Part One: Format of Internet Message 556 Bodies", RFC 2045, November 1996. 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, March 1997. 561 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 562 Types", RFC 3023, January 2001. 564 6.2. Informative References 566 [I-D.ietf-appsawg-media-type-regs] 567 Freed, N., Klensin, J., and T. Hansen, "Media Type 568 Specifications and Registration Procedures", 569 draft-ietf-appsawg-media-type-regs-14 (work in progress), 570 June 2012. 572 Appendix A. Change History 574 This section is to be removed before publication. 576 draft-ietf-appsawg-media-type-suffix-regs-02 Added BER/DER security 577 considerations. 578 Reworked fragment identifier wording some more. 580 draft-ietf-appsawg-media-type-suffix-regs-01 Reordered the sections. 581 Cleaned up some MUSTard. 582 Fixed some references. 583 Added encoding considerations. 584 Reworked fragment identifier wording. 586 draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment 587 identifier consideration sections. 588 Added a note about +xml fragment identifier 589 considerations. 591 draft-hansen-media-type-suffix-regs-02 Added +zip. 592 Fixed up the ISO document references. 593 Minor changes. 595 draft-hansen-media-type-suffix-regs-01 Added +ber. 596 Minor changes. 598 Authors' Addresses 600 Tony Hansen 601 AT&T Laboratories 602 200 Laurel Ave. South 603 Middletown, NJ 07748 604 USA 606 Email: tony+sss@maillennium.att.com 608 Alexey Melnikov 609 Isode Ltd 610 5 Castle Business Village 611 36 Station Road 612 Hampton, Middlesex TW12 2BX 613 UK 615 Email: Alexey.Melnikov@isode.com