idnits 2.17.1 draft-ietf-appsawg-media-type-suffix-regs-06.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 (October 5, 2012) is 4214 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: April 8, 2013 October 5, 2012 8 Additional Media Type Structured Syntax Suffixes 9 draft-ietf-appsawg-media-type-suffix-regs-06 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 April 8, 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 . . . . . . . . . . . . . . . . . . 14 70 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 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 [RFC3023] to formally register the "+xml" Structured Syntax 90 Suffix according to procedure defined in 91 [I-D.ietf-appsawg-media-type-regs]. 93 Discussion of this document should occur in the Apps Area Working 94 Group (apps-discuss@ietf.org). [RFC Editor note: remove this 95 paragraph.] 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. When to Use these Structured Syntax Suffixes 103 Each of the Structured Syntax Suffixes defined in this document is 104 appropriate for use when the media type identifies the semantics of 105 the protocol payload. That is, knowing the semantics of the specific 106 media type provides for more specific processing of the content than 107 that afforded by generic processing of the underlying representation. 109 At the same time, using the suffix allows receivers of the media 110 types to do generic processing of the underlying representation in 111 cases where 113 they do not need to perform special handling of the particular 114 semantics of the exact media type, and, 116 there is no special knowledge needed by such a generic processor 117 in order to parse that underlying representation other than what 118 would be needed to parse any example of that underlying 119 representation. 121 3. Initial Structured Syntax Suffix Definitions 123 3.1. The +json Structured Syntax Suffix 125 [RFC4627] defines the "application/json" media type. The suffix 126 "+json" MAY be used with any media type whose representation follows 127 that established for "application/json". The Message Type Structured 128 Syntax Suffix registration form follows. See 129 [I-D.ietf-appsawg-media-type-regs] for definitions of each of the 130 registration form headings. 132 Name: JavaScript Object Notation (JSON) 134 +suffix: +json 136 References: [RFC4627] 138 Encoding considerations: Per [RFC4627], JSON is allowed to be 139 represented using UTF-8, UTF-16, or UTF-32. When 140 JSON is written in UTF-8, JSON is 8bit compatible 141 ([RFC2045]). When JSON is written in UTF-16 or 142 UTF-32, JSON is binary ([RFC2045]). 144 Fragment identifier considerations: 146 The syntax and semantics of fragment 147 identifiers specified for +json SHOULD be as 148 specified for "application/json". (At 149 publication of this document, there is no 150 fragment identification syntax defined for 151 "application/json".) 153 The syntax and semantics for fragment 154 identifiers for a specific "xxx/yyy+json" 155 SHOULD be processed as follows: 157 For cases defined in +json, where the 158 fragment identifier resolves per the +json 159 rules, then as specified in +json. 161 For cases defined in +json, where the 162 fragment identifier does not resolve per 163 the +json rules, then as specified in "xxx/ 164 yyy+json". 166 For cases not defined in +json, then as 167 specified in "xxx/yyy+json". 169 Interoperability considerations: n/a 171 Security considerations: See [RFC4627] 173 Contact: Apps Area Working Group (apps-discuss@ietf.org) 175 Author/Change controller: The Apps Area Working Group has change 176 control over this registration. 178 3.2. The +ber Structured Syntax Suffixes 180 The ITU defined the Basic Encoding Rules (BER) message transfer 181 syntax in [ITU.X690.2008]. The suffix "+ber" MAY be used with any 182 media type whose representation follows the BER message transfer 183 syntax. The Message Type Structured Syntax Suffix registration form 184 for +ber follows: 186 Name: Basic Encoding Rules (BER) message transfer 187 syntax 189 +suffix: +ber 191 References: [ITU.X690.2008] 193 Encoding considerations: BER is a binary encoding. 195 Fragment identifier considerations: 197 At publication of this document, there is no 198 fragment identification syntax defined for 199 +ber. 201 The syntax and semantics for fragment 202 identifiers for a specific "xxx/yyy+ber" 203 SHOULD be processed as follows: 205 For cases defined in +ber, where the 206 fragment identifier resolves per the +ber 207 rules, then as specified in +ber. 209 For cases defined in +ber, where the 210 fragment identifier does not resolve per 211 the +ber rules, then as specified in "xxx/ 212 yyy+ber". 214 For cases not defined in +ber, then as 215 specified in "xxx/yyy+ber". 217 Interoperability considerations: n/a 219 Security considerations: Each individual media type registered with 220 a +ber suffix can have additional security 221 considerations. 223 BER has a type-length-value structure, and it is 224 easy to construct malicious content with invalid 225 length fields that can cause buffer overrun 226 conditions. 228 Some BER schema allow for arbitrary levels of 229 nesting, which may make it possible to construct 230 malicious content that will cause a stack 231 overflow. 233 Interpreters of the BER structures should be 234 aware of these issues and should take appropriate 235 measures to guard against buffer overflows and 236 stack overruns in particular and malicious 237 content in general. 239 Contact: Apps Area Working Group (apps-discuss@ietf.org) 241 Author/Change controller: The Apps Area Working Group has change 242 control over this registration. 244 3.3. The +der Structured Syntax Suffixes 246 The ITU defined the Distinguished Encoding Rules (DER) message 247 transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used 248 with any media type whose representation follows the DER message 249 transfer syntax. The Message Type Structured Syntax Suffix 250 registration form for +der follows: 252 Name: Distinguished Encoding Rules (DER) message 253 transfer syntax 255 +suffix: +der 257 References: [ITU.X690.2008] 258 Encoding considerations: DER is a binary encoding. 260 Fragment identifier considerations: 262 At publication of this document, there is no 263 fragment identification syntax defined for 264 +der. 266 The syntax and semantics for fragment 267 identifiers for a specific "xxx/yyy+der" 268 SHOULD be processed as follows: 270 For cases defined in +der, where the 271 fragment identifier resolves per the +der 272 rules, then as specified in +der. 274 For cases defined in +der, where the 275 fragment identifier does not resolve per 276 the +der rules, then as specified in "xxx/ 277 yyy+der". 279 For cases not defined in +der, then as 280 specified in "xxx/yyy+der". 282 Interoperability considerations: n/a 284 Security considerations: Each individual media type registered with 285 a +der suffix can have additional security 286 considerations. 288 DER has a type-length-value structure, and it is 289 easy to construct malicious content with invalid 290 length fields that can cause buffer overrun 291 conditions. 293 Some DER schema allow for arbitrary levels of 294 nesting, which may make it possible to construct 295 malicious content that will cause a stack 296 overflow. 298 Interpreters of the DER structures should be 299 aware of these issues and should take appropriate 300 measures to guard against buffer overflows and 301 stack overruns in particular and malicious 302 content in general. 304 Contact: Apps Area Working Group (apps-discuss@ietf.org) 306 Author/Change controller: The Apps Area Working Group has change 307 control over this registration. 309 3.4. The +fastinfoset Structured Syntax Suffix 311 The ITU defined the Fast Infoset document format as a binary 312 representation of the XML Information Set in [ITU.X891.2005]. These 313 documents further define the "application/fastinfoset" media type. 314 The suffix "+fastinfoset" MAY be used with any media type whose 315 representation follows that established for "application/ 316 fastinfoset". The Message Type Structured Syntax Suffix registration 317 form follows: 319 Name: Fast Infoset document format 321 +suffix: +fastinfoset 323 References: [ITU.X891.2005] 325 Encoding considerations: Fast Infoset is a binary encoding. The 326 binary, quoted-printable and base64 content- 327 transfer-encodings are suitable for use with Fast 328 Infoset. 330 Fragment identifier considerations: 332 The syntax and semantics of fragment 333 identifiers specified for +fastinfoset SHOULD 334 be as specified for "application/fastinfoset". 335 (At publication of this document, there is no 336 fragment identification syntax defined for 337 "application/fastinfoset".) 339 The syntax and semantics for fragment 340 identifiers for a specific "xxx/ 341 yyy+fastinfoset" SHOULD be processed as 342 follows: 344 For cases defined in +fastinfoset, where 345 the fragment identifier resolves per the 346 +fastinfoset rules, then as specified in 347 +fastinfoset. 349 For cases defined in +fastinfoset, where 350 the fragment identifier does not resolve 351 per the +fastinfoset rules, then as 352 specified in "xxx/yyy+fastinfoset". 354 For cases not defined in +fastinfoset, then 355 as specified in "xxx/yyy+fastinfoset". 357 Interoperability considerations: n/a 359 Security considerations: There are no security considerations 360 inherent in Fast Infoset. Each individual media 361 type registered with a +fastinfoset suffix can 362 have additional security considerations. 364 Contact: Apps Area Working Group (apps-discuss@ietf.org) 366 Author/Change controller: The Apps Area Working Group has change 367 control over this registration. 369 3.5. The +wbxml Structured Syntax Suffix 371 The WAP Forum has defined the WAP Binary XML (WBXML) document format 372 as a binary representation of XML in [WBXML]. This document further 373 defines the "application/vnd.wap.wbxml" media type. The suffix 374 "+wbxml" MAY be used with any media type whose representation follows 375 that established for "application/vnd.wap.wbxml". The Message Type 376 Structured Syntax Suffix registration form follows: 378 Name: WAP Binary XML (WBXML) document format 380 +suffix: +wbxml 382 References: [WBXML] 384 Encoding considerations: WBXML is a binary encoding. 386 Fragment identifier considerations: 388 The syntax and semantics of fragment 389 identifiers specified for +wbxml SHOULD be as 390 specified for "application/vnd.wap.wbxml". 391 (At publication of this document, there is no 392 fragment identification syntax defined for 393 "application/vnd.wap.wbxml".) 394 The syntax and semantics for fragment 395 identifiers for a specific "xxx/yyy+wbxml" 396 SHOULD be processed as follows: 398 For cases defined in +wbxml, where the 399 fragment identifier resolves per the +wbxml 400 rules, then as specified in +wbxml. 402 For cases defined in +wbxml, where the 403 fragment identifier does not resolve per 404 the +wbxml rules, then as specified in 405 "xxx/yyy+wbxml". 407 For cases not defined in +wbxml, then as 408 specified in "xxx/yyy+wbxml". 410 Interoperability considerations: n/a 412 Security considerations: There are no security considerations 413 inherent in WBXML. Each individual media type 414 registered with a +wbxml suffix can have 415 additional security considerations. 417 Contact: Apps Area Working Group (apps-discuss@ietf.org) 419 Author/Change controller: The Apps Area Working Group has change 420 control over this registration. 422 3.6. The +zip Structured Syntax Suffix 424 The ZIP format is a public domain, cross-platform, interoperable file 425 storage and transfer format, originally defined by PKWARE, Inc.; it 426 supports compression and encryption and is used as the underlying 427 representation by a variety of file formats. The media type 428 "application/zip" has been registered for such files. The suffix 429 "+zip" MAY be used with any media type whose representation follows 430 that established for "application/zip". The Message Type Structured 431 Syntax Suffix registration form follows: 433 Name: ZIP file storage and transfer format 435 +suffix: +zip 437 References: [ZIP] 438 Encoding considerations: ZIP is a binary encoding. 440 Fragment identifier considerations: 442 The syntax and semantics of fragment 443 identifiers specified for +zip SHOULD be as 444 specified for "application/zip". (At 445 publication of this document, there is no 446 fragment identification syntax defined for 447 "application/zip".) 449 The syntax and semantics for fragment 450 identifiers for a specific "xxx/yyy+zip" 451 SHOULD be processed as follows: 453 For cases defined in +zip, where the 454 fragment identifier resolves per the +zip 455 rules, then as specified in +zip. 457 For cases defined in +zip, where the 458 fragment identifier does not resolve per 459 the +zip rules, then as specified in "xxx/ 460 yyy+zip". 462 For cases not defined in +zip, then as 463 specified in "xxx/yyy+zip". 465 Interoperability considerations: n/a 467 Security considerations: ZIP files support two forms of encryption: 468 Strong Encryption and AES 128-bit, 192-bit and 469 256-bit encryption; see the specification for 470 further details. Each individual media type 471 registered with a +zip suffix can have additional 472 security considerations. 474 Contact: Apps Area Working Group (apps-discuss@ietf.org) 476 Author/Change controller: The Apps Area Working Group has change 477 control over this registration. 479 4. IANA Considerations 481 See the Message Type Structured Syntax Suffix registration forms in 482 Section 3.1 - Section 3.6. 484 The existing Structured Syntax Suffix registration for "+xml" is 485 modified to include the following 487 Fragment identifier considerations: 489 The syntax and semantics of fragment 490 identifiers specified for +xml SHOULD be as 491 specified for "application/xml". (At 492 publication of this document, the fragment 493 identification syntax considerations for 494 "application/xml" are defined in [RFC3023], 495 sections 5 and 7.) 497 The syntax and semantics for fragment 498 identifiers for a specific "xxx/yyy+xml" 499 SHOULD be processed as follows: 501 For cases defined in +xml, where the 502 fragment identifier resolves per the +xml 503 rules, then as specified in +xml. 505 For cases defined in +xml, where the 506 fragment identifier does not resolve per 507 the +xml rules, then as specified in "xxx/ 508 yyy+xml". 510 For cases not defined in +xml, then as 511 specified in "xxx/yyy+xml". 513 5. Security Considerations 515 See the Security considerations sections found in the Message Type 516 Structured Syntax Suffix registration forms from Section 3.1 - 517 Section 3.5. 519 When updating a + registration, care should be taken to 520 review all previously-registered xxx/yyy+ media types as to 521 whether they might be affected by the updated + registration. 522 Because the generic fragment identifier processing rules take 523 precedence over media-type-specific rules, introducing new or 524 changing existing definitions may break the existing registrations of 525 specific media types, as well as particular implementations of 526 applications that process affected media types. Such changes can 527 introduce interoperability and security issues. 529 When updating the fragment identifier processing rules for a specific 530 xxx/yyy+ media type, care should be taken to review the 531 generic fragment identifier processing rules for the + 532 registration and not introduce any conflicts. Because the generic 533 fragment identifier processing rules take precedence over media-type- 534 specific rules, such conflicting processing requirements should be 535 ignored by an implementation, but such conflicts can introduce 536 interoperability and security issues. 538 Note that [FRAGID-BP] provides additional advice to designers of 539 fragment identifier rules for media type suffixes and specific media 540 types. 542 6. References 544 6.1. Normative References 546 [RFC4627] Crockford, D., "The application/json Media Type for 547 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 549 [ITU.X690.2008] 550 International Telecommunications Union, "Recommendation 551 ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules: 552 Specification of basic encoding Rules (BER), Canonical 553 encoding rules (CER) and Distinguished encoding rules 554 (DER)", ITU-T Recommendation X.690, November 2008. 556 [ITU.X891.2005] 557 International Telecommunications Union, "Recommendation 558 ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications 559 of ASN.1: Fast infoset", ITU-T Recommendation X.891, 560 May 2005. 562 [WBXML] Open Mobile Alliance, "Binary XML Content Format 563 Specification", OMA Wireless Access Protocol WAP-192- 564 WBXML-20010725-a, July 2001. 566 [ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format 567 Specification", PKWARE .ZIP File Format Specification - 568 Version 6.3.2, September 2007. 570 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 571 Extensions (MIME) Part One: Format of Internet Message 572 Bodies", RFC 2045, November 1996. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 578 Types", RFC 3023, January 2001. 580 6.2. Informative References 582 [I-D.ietf-appsawg-media-type-regs] 583 Freed, N., Klensin, J., and T. Hansen, "Media Type 584 Specifications and Registration Procedures", 585 draft-ietf-appsawg-media-type-regs-14 (work in progress), 586 June 2012. 588 [FRAGID-BP] 589 Tennison, J., "Best Practices for Fragment Identifiers and 590 Media Type Definitions", July 2012, 591 . 593 Appendix A. Change History 595 This section is to be removed before publication. 597 draft-ietf-appsawg-media-type-suffix-regs-06 Clarified why this 598 document updates RFC 3023. 600 draft-ietf-appsawg-media-type-suffix-regs-05 Added an Informative 601 reference to 602 http://www.w3.org/TR/fragid-best-practices/. 603 Minor editorial changes. 605 draft-ietf-appsawg-media-type-suffix-regs-03 Added generic fragment 606 idenfier rules to +ber/+der to make them 607 consistant with other registrations. 608 Added some warning about how adding/changing 609 fragment identifier rules for a +suffix can 610 affect fragment identifier processing rules for 611 previously registered xxx/yyy+suffix media types. 613 draft-ietf-appsawg-media-type-suffix-regs-02 Added BER/DER security 614 considerations. 615 Reworked fragment identifier wording some more. 617 draft-ietf-appsawg-media-type-suffix-regs-01 Reordered the sections. 618 Cleaned up some MUSTard. 619 Fixed some references. 620 Added encoding considerations. 621 Reworked fragment identifier wording. 623 draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment 624 identifier consideration sections. 625 Added a note about +xml fragment identifier 626 considerations. 628 draft-hansen-media-type-suffix-regs-02 Added +zip. 629 Fixed up the ISO document references. 630 Minor changes. 632 draft-hansen-media-type-suffix-regs-01 Added +ber. 633 Minor changes. 635 Authors' Addresses 637 Tony Hansen 638 AT&T Laboratories 639 200 Laurel Ave. South 640 Middletown, NJ 07748 641 USA 643 Email: tony+sss@maillennium.att.com 645 Alexey Melnikov 646 Isode Ltd 647 5 Castle Business Village 648 36 Station Road 649 Hampton, Middlesex TW12 2BX 650 UK 652 Email: Alexey.Melnikov@isode.com