--- 1/draft-ietf-appsawg-media-type-suffix-regs-06.txt 2012-10-22 23:14:23.901425469 +0200 +++ 2/draft-ietf-appsawg-media-type-suffix-regs-07.txt 2012-10-22 23:14:23.937346998 +0200 @@ -1,101 +1,100 @@ Network Working Group T. Hansen Internet-Draft AT&T Laboratories Updates: 3023 (if approved) A. Melnikov -Intended status: BCP Isode Ltd -Expires: April 8, 2013 October 5, 2012 +Intended status: Best Current Practice Isode Ltd +Expires: April 23, 2013 October 22, 2012 Additional Media Type Structured Syntax Suffixes - draft-ietf-appsawg-media-type-suffix-regs-06 + draft-ietf-appsawg-media-type-suffix-regs-07 Abstract A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax - Suffixes, and updates the "+xml" Message Type Structured Syntax - Suffix registration. + Suffixes, and provides a Message Type Structured Syntax Suffix + registration form for the "+xml" Structured Syntax Suffix. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 8, 2013. + This Internet-Draft will expire on April 23, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. When to Use these Structured Syntax Suffixes . . . . . . . . . 3 - 3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 4 - 3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 4 - 3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 5 - 3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 6 - 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 8 - 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 9 - 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 10 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 - Appendix A. Change History . . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. When to Use these Structured Syntax Suffixes . . . . . . . . . 2 + 3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 3 + 3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 3 + 3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 4 + 3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 5 + 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 7 + 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 8 + 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 9 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 + Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction [RFC3023] created the +xml suffix convention that can be used when defining names for media types whose representation uses XML underneath. That is, they could have been successfully parsed as if the media type had been application/xml in addition to their being - parsed as their media type that is using the +xml suffix. - [I-D.ietf-appsawg-media-type-regs] defines the Message Type - Structured Syntax Suffixes registry to be used for such Structured - Syntax Suffixes. + parsed as their media type that is using the +xml suffix. [I-D.ietf- + appsawg-media-type-regs] defines the Message Type Structured Syntax + Suffixes registry to be used for such Structured Syntax Suffixes. A variety of Structured Syntax Suffixes have already been used in some media type registrations, in particular "+json", "+der", "+fastinfoset" and "+wbxml". This document defines and registers these Structured Syntax Suffixes in the Structured Syntax Suffix registry, along with "+ber" and "+zip". In addition, this document updates [RFC3023] to formally register the "+xml" Structured Syntax - Suffix according to procedure defined in - [I-D.ietf-appsawg-media-type-regs]. + Suffix according to procedure defined in [I-D.ietf-appsawg-media- + type-regs]. Discussion of this document should occur in the Apps Area Working Group (apps-discuss@ietf.org). [RFC Editor note: remove this paragraph.] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. When to Use these Structured Syntax Suffixes @@ -118,23 +116,23 @@ would be needed to parse any example of that underlying representation. 3. Initial Structured Syntax Suffix Definitions 3.1. The +json Structured Syntax Suffix [RFC4627] defines the "application/json" media type. The suffix "+json" MAY be used with any media type whose representation follows that established for "application/json". The Message Type Structured - Syntax Suffix registration form follows. See - [I-D.ietf-appsawg-media-type-regs] for definitions of each of the - registration form headings. + Syntax Suffix registration form follows. See [I-D.ietf-appsawg- + media-type-regs] for definitions of each of the registration form + headings. Name: JavaScript Object Notation (JSON) +suffix: +json References: [RFC4627] Encoding considerations: Per [RFC4627], JSON is allowed to be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible @@ -173,22 +171,24 @@ Contact: Apps Area Working Group (apps-discuss@ietf.org) Author/Change controller: The Apps Area Working Group has change control over this registration. 3.2. The +ber Structured Syntax Suffixes The ITU defined the Basic Encoding Rules (BER) message transfer syntax in [ITU.X690.2008]. The suffix "+ber" MAY be used with any media type whose representation follows the BER message transfer - syntax. The Message Type Structured Syntax Suffix registration form - for +ber follows: + syntax. (The expert reviewer for Message Type Structured Syntax + Suffix registrations ought to be aware of the relationship between + BER and DER to aid in selecting the proper suffix.) The Message Type + Structured Syntax Suffix registration form for +ber follows: Name: Basic Encoding Rules (BER) message transfer syntax +suffix: +ber References: [ITU.X690.2008] Encoding considerations: BER is a binary encoding. @@ -209,59 +209,62 @@ For cases defined in +ber, where the fragment identifier does not resolve per the +ber rules, then as specified in "xxx/ yyy+ber". For cases not defined in +ber, then as specified in "xxx/yyy+ber". Interoperability considerations: n/a - Security considerations: Each individual media type registered with - a +ber suffix can have additional security + Security considerations: Each individual media type registered with a + +ber suffix can have additional security considerations. BER has a type-length-value structure, and it is easy to construct malicious content with invalid length fields that can cause buffer overrun conditions. - Some BER schema allow for arbitrary levels of - nesting, which may make it possible to construct - malicious content that will cause a stack - overflow. + BER allows for arbitrary levels of nesting, which + may make it possible to construct malicious + content that will cause a stack overflow. Interpreters of the BER structures should be aware of these issues and should take appropriate measures to guard against buffer overflows and stack overruns in particular and malicious content in general. Contact: Apps Area Working Group (apps-discuss@ietf.org) Author/Change controller: The Apps Area Working Group has change control over this registration. 3.3. The +der Structured Syntax Suffixes The ITU defined the Distinguished Encoding Rules (DER) message transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used with any media type whose representation follows the DER message - transfer syntax. The Message Type Structured Syntax Suffix - registration form for +der follows: + transfer syntax. (The expert reviewer for Message Type Structured + Syntax Suffix registrations ought to be aware of the relationship + between BER and DER to aid in selecting the proper suffix.) The + Message Type Structured Syntax Suffix registration form for +der + follows: Name: Distinguished Encoding Rules (DER) message transfer syntax +suffix: +der References: [ITU.X690.2008] + Encoding considerations: DER is a binary encoding. Fragment identifier considerations: At publication of this document, there is no fragment identification syntax defined for +der. The syntax and semantics for fragment identifiers for a specific "xxx/yyy+der" @@ -274,33 +277,32 @@ For cases defined in +der, where the fragment identifier does not resolve per the +der rules, then as specified in "xxx/ yyy+der". For cases not defined in +der, then as specified in "xxx/yyy+der". Interoperability considerations: n/a - Security considerations: Each individual media type registered with - a +der suffix can have additional security + Security considerations: Each individual media type registered with a + +der suffix can have additional security considerations. DER has a type-length-value structure, and it is easy to construct malicious content with invalid length fields that can cause buffer overrun conditions. - Some DER schema allow for arbitrary levels of - nesting, which may make it possible to construct - malicious content that will cause a stack - overflow. + DER allows for arbitrary levels of nesting, which + may make it possible to construct malicious + content that will cause a stack overflow. Interpreters of the DER structures should be aware of these issues and should take appropriate measures to guard against buffer overflows and stack overruns in particular and malicious content in general. Contact: Apps Area Working Group (apps-discuss@ietf.org) Author/Change controller: The Apps Area Working Group has change @@ -394,28 +396,27 @@ The syntax and semantics for fragment identifiers for a specific "xxx/yyy+wbxml" SHOULD be processed as follows: For cases defined in +wbxml, where the fragment identifier resolves per the +wbxml rules, then as specified in +wbxml. For cases defined in +wbxml, where the fragment identifier does not resolve per - the +wbxml rules, then as specified in - "xxx/yyy+wbxml". + the +wbxml rules, then as specified in "xxx + /yyy+wbxml". For cases not defined in +wbxml, then as specified in "xxx/yyy+wbxml". Interoperability considerations: n/a - Security considerations: There are no security considerations inherent in WBXML. Each individual media type registered with a +wbxml suffix can have additional security considerations. Contact: Apps Area Working Group (apps-discuss@ietf.org) Author/Change controller: The Apps Area Working Group has change control over this registration. @@ -474,22 +476,35 @@ Contact: Apps Area Working Group (apps-discuss@ietf.org) Author/Change controller: The Apps Area Working Group has change control over this registration. 4. IANA Considerations See the Message Type Structured Syntax Suffix registration forms in Section 3.1 - Section 3.6. - The existing Structured Syntax Suffix registration for "+xml" is - modified to include the following + The following Structured Syntax Suffix registration for "+xml" shall + be used to reflect the information found in [RFC3023], with the + addition of fragment identifier considerations: + + Name: Extensible Markup Language (XML) + + +suffix: +xml + + References: [RFC3023] + + Encoding considerations: Per [RFC3023], XML is allowed to be + represented using both 7-bit and 8-bit encodings. + When XML is written in UTF-8, XML is 8bit + compatible ([RFC2045]). When XML is written in + UTF-16 or UTF-32, XML is binary ([RFC2045]). Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +xml SHOULD be as specified for "application/xml". (At publication of this document, the fragment identification syntax considerations for "application/xml" are defined in [RFC3023], sections 5 and 7.) @@ -503,20 +518,29 @@ rules, then as specified in +xml. For cases defined in +xml, where the fragment identifier does not resolve per the +xml rules, then as specified in "xxx/ yyy+xml". For cases not defined in +xml, then as specified in "xxx/yyy+xml". + Interoperability considerations: See [RFC3023]. + + Security considerations: See [RFC3023] + + Contact: Apps Area Working Group (apps-discuss@ietf.org) + + Author/Change controller: The Apps Area Working Group has change + control over this registration. + 5. Security Considerations See the Security considerations sections found in the Message Type Structured Syntax Suffix registration forms from Section 3.1 - Section 3.5. When updating a + registration, care should be taken to review all previously-registered xxx/yyy+ media types as to whether they might be affected by the updated + registration. Because the generic fragment identifier processing rules take @@ -549,91 +573,98 @@ [ITU.X690.2008] International Telecommunications Union, "Recommendation ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", ITU-T Recommendation X.690, November 2008. [ITU.X891.2005] International Telecommunications Union, "Recommendation ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications - of ASN.1: Fast infoset", ITU-T Recommendation X.891, - May 2005. + of ASN.1: Fast infoset", ITU-T Recommendation X.891, May + 2005. [WBXML] Open Mobile Alliance, "Binary XML Content Format - Specification", OMA Wireless Access Protocol WAP-192- - WBXML-20010725-a, July 2001. + Specification", OMA Wireless Access Protocol + WAP-192-WBXML-20010725-a, July 2001. [ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format Specification", PKWARE .ZIP File Format Specification - Version 6.3.2, September 2007. - [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + [RFC2045] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media + [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. 6.2. Informative References [I-D.ietf-appsawg-media-type-regs] - Freed, N., Klensin, J., and T. Hansen, "Media Type - Specifications and Registration Procedures", - draft-ietf-appsawg-media-type-regs-14 (work in progress), - June 2012. + Freed, N., Klensin, J. and T. Hansen, "Media Type + Specifications and Registration Procedures", Internet- + Draft draft-ietf-appsawg-media-type-regs-14, June 2012. [FRAGID-BP] Tennison, J., "Best Practices for Fragment Identifiers and - Media Type Definitions", July 2012, - . + Media Type Definitions", July 2012, . Appendix A. Change History This section is to be removed before publication. + draft-ietf-appsawg-media-type-suffix-regs-07 Added information based + on IANA and GEN-ART reviews. + draft-ietf-appsawg-media-type-suffix-regs-06 Clarified why this document updates RFC 3023. draft-ietf-appsawg-media-type-suffix-regs-05 Added an Informative - reference to - http://www.w3.org/TR/fragid-best-practices/. + reference to http://www.w3.org/TR/fragid-best- + practices/. Minor editorial changes. draft-ietf-appsawg-media-type-suffix-regs-03 Added generic fragment idenfier rules to +ber/+der to make them consistant with other registrations. - Added some warning about how adding/changing - fragment identifier rules for a +suffix can - affect fragment identifier processing rules for - previously registered xxx/yyy+suffix media types. + Added some warning about + how adding/changing fragment identifier rules for + a +suffix can affect fragment identifier + processing rules for previously registered xxx/ + yyy+suffix media types. draft-ietf-appsawg-media-type-suffix-regs-02 Added BER/DER security considerations. - Reworked fragment identifier wording some more. + Reworked fragment + identifier wording some more. draft-ietf-appsawg-media-type-suffix-regs-01 Reordered the sections. Cleaned up some MUSTard. Fixed some references. - Added encoding considerations. - Reworked fragment identifier wording. + Added encoding + considerations. + Reworked fragment + identifier wording. draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment identifier consideration sections. - Added a note about +xml fragment identifier - considerations. + Added a note about +xml + fragment identifier considerations. draft-hansen-media-type-suffix-regs-02 Added +zip. - Fixed up the ISO document references. + Fixed up the ISO document + references. Minor changes. draft-hansen-media-type-suffix-regs-01 Added +ber. Minor changes. Authors' Addresses Tony Hansen AT&T Laboratories 200 Laurel Ave. South