idnits 2.17.1 draft-ietf-appsawg-media-type-suffix-regs-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 : ---------------------------------------------------------------------------- -- 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 (July 17, 2012) is 4295 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) == Unused Reference: 'I-D.ietf-appsawg-media-type-regs' is defined on line 519, but no explicit reference was found in the text ** 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 (~~), 2 warnings (==), 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) July 17, 2012 5 Intended status: Best Current Practice 6 Expires: January 16, 2013 8 Additional Media Type Structured Syntax Suffixes 9 draft-ietf-appsawg-media-type-suffix-regs-02 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 January 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. When to Use these Structured Syntax Suffixes . . . . . . . . . 2 58 3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 3 59 3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 3 60 3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 4 61 3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 5 62 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 6 63 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 7 64 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 8 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 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. [I-D.ietf- 80 appsawg-media-type-regs] defines the Message Type Structured Syntax 81 Suffixes registry to be used for such Structured Syntax Suffixes. 83 A variety of Structured Syntax Suffixes have already been used in 84 some media type registrations, in particular "+json", "+der", 85 "+fastinfoset" and "+wbxml". This document defines and registers 86 these Structured Syntax Suffixes in the Structured Syntax Suffix 87 registry, along with "+ber" and "+zip". In addition, this document 88 updates the "+xml" Structured Syntax Suffix registration. 90 Discussion of this document should occur in the Apps Area Working 91 Group (apps-discuss@ietf.org). [RFC Editor note: remove this 92 paragraph.] 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. When to Use these Structured Syntax Suffixes 100 Each of the Structured Syntax Suffixes defined in this document is 101 appropriate for use when the media type identifies the semantics of 102 the protocol payload. That is, knowing the semantics of the specific 103 media type provides for more specific processing of the content than 104 that afforded by generic processing of the underlying representation. 106 At the same time, using the suffix allows receivers of the media 107 types to do generic processing of the underlying representation in 108 cases where 110 they do not need to perform special handling of the particular 111 semantics of the exact media type, and, 113 there is no special knowledge needed by such a generic processor 114 in order to parse that underlying representation other than what 115 would be needed to parse any example of that underlying 116 representation. 118 3. Initial Structured Syntax Suffix Definitions 120 3.1. The +json Structured Syntax Suffix 122 [RFC4627] defines the "application/json" media type. The suffix 123 "+json" MAY be used with any media type whose representation follows 124 that established for "application/json". The Message Type Structured 125 Syntax Suffix registration form follows. See [I-D.ietf-appsawg- 126 media-type-regs] for definitions of each of the registration form 127 headings. 129 Name: JavaScript Object Notation (JSON) 131 +suffix: +json 133 References: [RFC4627] 135 Encoding considerations: Per [RFC4627], JSON is allowed to be 136 represented using UTF-8, UTF-16, or UTF-32. When 137 JSON is written in UTF-8, JSON is 8bit compatible 138 ([RFC2045]). When JSON is written in UTF-16 or 139 UTF-32, JSON is binary ([RFC2045]). 141 Fragment identifier considerations: 143 The syntax and semantics of fragment 144 identifiers specified for +json SHOULD be as 145 specified for "application/json". (At 146 publication of this document, there is no 147 fragment identification syntax defined for 148 "application/json".) 150 The syntax and semantics for fragment 151 identifiers for a specific "xxx/yyy+json" 152 SHOULD be processed as follows: 154 For cases defined in +json, where the 155 fragment identifier resolves per the +json 156 rules, then as specified in +json. 158 For cases defined in +json, where the 159 fragment identifier does not resolve per 160 the +json rules, then as specified in "xxx/ 161 yyy+json". 163 For cases not defined in +json, then as 164 specified in "xxx/yyy+json". 166 Interoperability considerations: n/a 168 Security considerations: See [RFC4627] 170 Contact: Apps Area Working Group (apps-discuss@ietf.org) 172 Author/Change controller: The Apps Area Working Group has change 173 control over this registration. 175 3.2. The +ber Structured Syntax Suffixes 177 The ITU defined the Basic Encoding Rules (BER) message transfer 178 syntax in [ITU.X690.2008]. The suffix "+ber" MAY be used with any 179 media type whose representation follows the BER message transfer 180 syntax. The Message Type Structured Syntax Suffix registration form 181 for +ber follows: 183 Name: Basic Encoding Rules (BER) message transfer 184 syntax 186 +suffix: +ber 188 References: [ITU.X690.2008] 190 Encoding considerations: BER is a binary encoding. 192 Fragment identifier considerations: n/a 194 Interoperability considerations: n/a 196 Security considerations: Each individual media type registered with a 197 +ber suffix can have additional security 198 considerations. 200 BER has a type-length-value structure, and it is 201 easy to construct malicious content with invalid 202 length fields that can cause buffer overrun 203 conditions. 205 Some BER schema allow for arbitrary levels of 206 nesting, which may make it possible to construct 207 malicious content that will cause a stack 208 overflow. 210 Interpreters of the BER structures should be 211 aware of these issues and should take appropriate 212 measures to guard against buffer overflows and 213 stack overruns in particular and malicious 214 content in general. 216 Contact: Apps Area Working Group (apps-discuss@ietf.org) 218 Author/Change controller: The Apps Area Working Group has change 219 control over this registration. 221 3.3. The +der Structured Syntax Suffixes 223 The ITU defined the Distinguished Encoding Rules (DER) message 224 transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used 225 with any media type whose representation follows the DER message 226 transfer syntax. The Message Type Structured Syntax Suffix 227 registration form for +der follows: 229 Name: Distinguished Encoding Rules (DER) message 230 transfer syntax 232 +suffix: +der 234 References: [ITU.X690.2008] 236 Encoding considerations: DER is a binary encoding. 238 Fragment identifier considerations: n/a 240 Interoperability considerations: n/a 242 Security considerations: Each individual media type registered with a 243 +ber suffix can have additional security 244 considerations. 246 DER has a type-length-value structure, and it is 247 easy to construct malicious content with invalid 248 length fields that can cause buffer overrun 249 conditions. 251 Some DER schema allow for arbitrary levels of 252 nesting, which may make it possible to construct 253 malicious content that will cause a stack 254 overflow. 256 Interpreters of the DER structures should be 257 aware of these issues and should take appropriate 258 measures to guard against buffer overflows and 259 stack overruns in particular and malicious 260 content in general. 262 Contact: Apps Area Working Group (apps-discuss@ietf.org) 264 Author/Change controller: The Apps Area Working Group has change 265 control over this registration. 267 3.4. The +fastinfoset Structured Syntax Suffix 269 The ITU defined the Fast Infoset document format as a binary 270 representation of the XML Information Set in [ITU.X891.2005]. These 271 documents further define the "application/fastinfoset" media type. 272 The suffix "+fastinfoset" MAY be used with any media type whose 273 representation follows that established for "application/ 274 fastinfoset". The Message Type Structured Syntax Suffix registration 275 form follows: 277 Name: Fast Infoset document format 279 +suffix: +fastinfoset 281 References: [ITU.X891.2005] 283 Encoding considerations: Fast Infoset is a binary encoding. The 284 binary, quoted-printable and base64 content- 285 transfer-encodings are suitable for use with Fast 286 Infoset. 288 Fragment identifier considerations: 290 The syntax and semantics of fragment 291 identifiers specified for +fastinfoset SHOULD 292 be as specified for "application/fastinfoset". 293 (At publication of this document, there is no 294 fragment identification syntax defined for 295 "application/fastinfoset".) 297 The syntax and semantics for fragment 298 identifiers for a specific "xxx/ 299 yyy+fastinfoset" SHOULD be processed as 300 follows: 302 For cases defined in +fastinfoset, where 303 the fragment identifier resolves per the 304 +fastinfoset rules, then as specified in 305 +fastinfoset. 307 For cases defined in +fastinfoset, where 308 the fragment identifier does not resolve 309 per the +fastinfoset rules, then as 310 specified in "xxx/yyy+fastinfoset". 312 For cases not defined in +fastinfoset, then 313 as specified in "xxx/yyy+fastinfoset". 315 Interoperability considerations: n/a 317 Security considerations: There are no security considerations 318 inherent in Fast Infoset. Each individual media 319 type registered with a +fastinfoset suffix can 320 have additional security considerations. 322 Contact: Apps Area Working Group (apps-discuss@ietf.org) 324 Author/Change controller: The Apps Area Working Group has change 325 control over this registration. 327 3.5. The +wbxml Structured Syntax Suffix 329 The WAP Forum has defined the WAP Binary XML (WBXML) document format 330 as a binary representation of XML in [WBXML]. This document further 331 defines the "application/vnd.wap.wbxml" media type. The suffix 332 "+wbxml" MAY be used with any media type whose representation follows 333 that established for "application/vnd.wap.wbxml". The Message Type 334 Structured Syntax Suffix registration form follows: 336 Name: WAP Binary XML (WBXML) document format 338 +suffix: +wbxml 340 References: [WBXML] 342 Encoding considerations: WBXML is a binary encoding. 344 Fragment identifier considerations: 346 The syntax and semantics of fragment 347 identifiers specified for +wbxml SHOULD be as 348 specified for "application/vnd.wap.wbxml". 349 (At publication of this document, there is no 350 fragment identification syntax defined for 351 "application/vnd.wap.wbxml".) 353 The syntax and semantics for fragment 354 identifiers for a specific "xxx/yyy+wbxml" 355 SHOULD be processed as follows: 357 For cases defined in +wbxml, where the 358 fragment identifier resolves per the +wbxml 359 rules, then as specified in +wbxml. 361 For cases defined in +wbxml, where the 362 fragment identifier does not resolve per 363 the +wbxml rules, then as specified in "xxx 364 /yyy+wbxml". 366 For cases not defined in +wbxml, then as 367 specified in "xxx/yyy+wbxml". 369 Interoperability considerations: n/a 371 Security considerations: There are no security considerations 372 inherent in WBXML. Each individual media type 373 registered with a +wbxml suffix can have 374 additional security considerations. 376 Contact: Apps Area Working Group (apps-discuss@ietf.org) 378 Author/Change controller: The Apps Area Working Group has change 379 control over this registration. 381 3.6. The +zip Structured Syntax Suffix 383 The ZIP format is a public domain, cross-platform, interoperable file 384 storage and transfer format, originally defined by PKWARE, Inc.; it 385 supports compression and encryption and is used as the underlying 386 representation by a variety of file formats. The media type 387 "application/zip" has been registered for such files. The suffix 388 "+zip" MAY be used with any media type whose representation follows 389 that established for "application/zip". The Message Type Structured 390 Syntax Suffix registration form follows: 392 Name: ZIP file storage and transfer format 394 +suffix: +zip 396 References: [ZIP] 398 Encoding considerations: ZIP is a binary encoding. 400 Fragment identifier considerations: 402 The syntax and semantics of fragment 403 identifiers specified for +zip SHOULD be as 404 specified for "application/zip". (At 405 publication of this document, there is no 406 fragment identification syntax defined for 407 "application/zip".) 409 The syntax and semantics for fragment 410 identifiers for a specific "xxx/yyy+zip" 411 SHOULD be processed as follows: 413 For cases defined in +zip, where the 414 fragment identifier resolves per the +zip 415 rules, then as specified in +zip. 417 For cases defined in +zip, where the 418 fragment identifier does not resolve per 419 the +zip rules, then as specified in "xxx/ 420 yyy+zip". 422 For cases not defined in +zip, then as 423 specified in "xxx/yyy+zip". 425 Interoperability considerations: n/a 427 Security considerations: ZIP files support two forms of encryption: 428 Strong Encryption and AES 128-bit, 192-bit and 429 256-bit encryption; see the specification for 430 further details. Each individual media type 431 registered with a +zip suffix can have additional 432 security considerations. 434 Contact: Apps Area Working Group (apps-discuss@ietf.org) 436 Author/Change controller: The Apps Area Working Group has change 437 control over this registration. 439 4. IANA Considerations 441 See the Message Type Structured Syntax Suffix registration forms in 442 Section 3.1 - Section 3.6. 444 The existing Structured Syntax Suffix registration for "+xml" is 445 modified to include the following 447 Fragment identifier considerations: 449 The syntax and semantics of fragment 450 identifiers specified for +xml SHOULD be as 451 specified for "application/xml". (At 452 publication of this document, the fragment 453 identification syntax considerations for 454 "application/xml" are defined in [RFC3023], 455 sections 5 and 7.) 457 The syntax and semantics for fragment 458 identifiers for a specific "xxx/yyy+xml" 459 SHOULD be processed as follows: 461 For cases defined in +xml, where the 462 fragment identifier resolves per the +xml 463 rules, then as specified in +xml. 465 For cases defined in +xml, where the 466 fragment identifier does not resolve per 467 the +xml rules, then as specified in "xxx/ 468 yyy+xml". 470 For cases not defined in +xml, then as 471 specified in "xxx/yyy+xml". 473 5. Security Considerations 475 See the Security considerations sections found in the Message Type 476 Structured Syntax Suffix registration forms from Section 3.1 - 477 Section 3.5. 479 6. References 481 6.1. Normative References 483 [RFC4627] Crockford, D., "The application/json Media Type for 484 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 486 [ITU.X690.2008] 487 International Telecommunications Union, "Recommendation 488 ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules: 489 Specification of basic encoding Rules (BER), Canonical 490 encoding rules (CER) and Distinguished encoding rules 491 (DER)", ITU-T Recommendation X.690, November 2008. 493 [ITU.X891.2005] 494 International Telecommunications Union, "Recommendation 495 ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications 496 of ASN.1: Fast infoset", ITU-T Recommendation X.891, May 497 2005. 499 [WBXML] Open Mobile Alliance, "Binary XML Content Format 500 Specification", OMA Wireless Access Protocol 501 WAP-192-WBXML-20010725-a, July 2001. 503 [ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format 504 Specification", PKWARE .ZIP File Format Specification - 505 Version 6.3.2, September 2007. 507 [RFC2045] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail 508 Extensions (MIME) Part One: Format of Internet Message 509 Bodies", RFC 2045, November 1996. 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 515 Types", RFC 3023, January 2001. 517 6.2. Informative References 519 [I-D.ietf-appsawg-media-type-regs] 520 Freed, N., Klensin, J. and T. Hansen, "Media Type 521 Specifications and Registration Procedures", Internet- 522 Draft draft-ietf-appsawg-media-type-regs-14, June 2012. 524 Appendix A. Change History 526 This section is to be removed before publication. 528 draft-ietf-appsawg-media-type-suffix-regs-02 Added BER/DER security 529 considerations. 530 Reworked fragment 531 identifier wording some more. 533 draft-ietf-appsawg-media-type-suffix-regs-01 Reordered the sections. 534 Cleaned up some MUSTard. 535 Fixed some references. 536 Added encoding 537 considerations. 538 Reworked fragment 539 identifier wording. 541 draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment 542 identifier consideration sections. 543 Added a note about +xml 544 fragment identifier considerations. 546 draft-hansen-media-type-suffix-regs-02 Added +zip. 547 Fixed up the ISO document 548 references. 549 Minor changes. 551 draft-hansen-media-type-suffix-regs-01 Added +ber. 552 Minor changes. 554 Author's Address 556 Tony Hansen 557 AT&T Laboratories 558 200 Laurel Ave. South 559 Middletown, NJ 07748 560 USA 562 Email: tony+sss@maillennium.att.com