--- 1/draft-ietf-appsawg-media-type-suffix-regs-01.txt 2012-07-17 02:14:22.241811429 +0200 +++ 2/draft-ietf-appsawg-media-type-suffix-regs-02.txt 2012-07-17 02:14:22.265759750 +0200 @@ -1,79 +1,81 @@ Network Working Group T. Hansen Internet-Draft AT&T Laboratories -Updates: 3023 (if approved) May 23, 2012 -Intended status: Standards Track -Expires: November 22, 2012 +Updates: 3023 (if approved) July 17, 2012 +Intended status: Best Current Practice +Expires: January 16, 2013 Additional Media Type Structured Syntax Suffixes - draft-ietf-appsawg-media-type-suffix-regs-01 + draft-ietf-appsawg-media-type-suffix-regs-02 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. -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 November 22, 2012. + This Internet-Draft will expire on January 16, 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. + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 4 - 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 5 - 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 6 - 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 6 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 - Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 9 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 5 + 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 6 + 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 7 + 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 8 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 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. @@ -128,32 +131,44 @@ +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 ([RFC2045]). When JSON is written in UTF-16 or UTF-32, JSON is binary ([RFC2045]). - Fragment identifier considerations: Media types using "+json" SHOULD - process any fragment identifiers defined for - "application/json" in the same way as defined for - that media type. (At publication of this - document, there is no fragment identification - syntax defined for "application/json".) Specific - media types using "+json" MAY identify additional - fragment identifier considerations, MAY define - processing for fragment identifiers that are - classed as errors for "application/json" and MAY - designate fragment identifiers defined for - "application/json" that SHOULD NOT be used. + Fragment identifier considerations: + + The syntax and semantics of fragment + identifiers specified for +json SHOULD be as + specified for "application/json". (At + publication of this document, there is no + fragment identification syntax defined for + "application/json".) + + The syntax and semantics for fragment + identifiers for a specific "xxx/yyy+json" + SHOULD be processed as follows: + + For cases defined in +json, where the + fragment identifier resolves per the +json + rules, then as specified in +json. + + For cases defined in +json, where the + fragment identifier does not resolve per + the +json rules, then as specified in "xxx/ + yyy+json". + + For cases not defined in +json, then as + specified in "xxx/yyy+json". Interoperability considerations: n/a Security considerations: See [RFC4627] Contact: Apps Area Working Group (apps-discuss@ietf.org) Author/Change controller: The Apps Area Working Group has change control over this registration. @@ -171,24 +186,39 @@ +suffix: +ber References: [ITU.X690.2008] Encoding considerations: BER is a binary encoding. Fragment identifier considerations: n/a Interoperability considerations: n/a - Security considerations: There are no security considerations - inherent in BER. Each individual media type - registered with a +ber suffix can have additional - security considerations. + 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. + + 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 @@ -201,24 +231,40 @@ +suffix: +der References: [ITU.X690.2008] Encoding considerations: DER is a binary encoding. Fragment identifier considerations: n/a Interoperability considerations: n/a - Security considerations: There are no security considerations - inherent in DER. Each individual media type - registered with a +der suffix can have additional - security considerations. + + Security considerations: Each individual media type registered with a + +ber 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. + + 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 control over this registration. 3.4. The +fastinfoset Structured Syntax Suffix The ITU defined the Fast Infoset document format as a binary representation of the XML Information Set in [ITU.X891.2005]. These @@ -232,34 +278,46 @@ +suffix: +fastinfoset References: [ITU.X891.2005] Encoding considerations: Fast Infoset is a binary encoding. The binary, quoted-printable and base64 content- transfer-encodings are suitable for use with Fast Infoset. - Fragment identifier considerations: Media types using "+fastinfoset" - SHOULD process any fragment identifiers defined - for "application/fastinfoset" in the same way as - defined for that media type. (At publication of - this document, there is no fragment - identification syntax defined for "application/ - fastinfoset".) Specific media types using - "+fastinfoset" MAY identify additional fragment - identifier considerations, MAY define processing - for fragment identifiers that are classed as - errors for "application/fastinfoset" and MAY - designate fragment identifiers defined for - "application/fastinfoset" that SHOULD NOT be - used. + Fragment identifier considerations: + + The syntax and semantics of fragment + identifiers specified for +fastinfoset SHOULD + be as specified for "application/fastinfoset". + (At publication of this document, there is no + fragment identification syntax defined for + "application/fastinfoset".) + + The syntax and semantics for fragment + identifiers for a specific "xxx/ + yyy+fastinfoset" SHOULD be processed as + follows: + + For cases defined in +fastinfoset, where + the fragment identifier resolves per the + +fastinfoset rules, then as specified in + +fastinfoset. + + For cases defined in +fastinfoset, where + the fragment identifier does not resolve + per the +fastinfoset rules, then as + specified in "xxx/yyy+fastinfoset". + + For cases not defined in +fastinfoset, then + as specified in "xxx/yyy+fastinfoset". Interoperability considerations: n/a Security considerations: There are no security considerations inherent in Fast Infoset. Each individual media type registered with a +fastinfoset suffix can have additional security considerations. Contact: Apps Area Working Group (apps-discuss@ietf.org) @@ -276,34 +334,44 @@ Structured Syntax Suffix registration form follows: Name: WAP Binary XML (WBXML) document format +suffix: +wbxml References: [WBXML] Encoding considerations: WBXML is a binary encoding. - Fragment identifier considerations: Media types using "+wbxml" SHOULD - process any fragment identifiers defined for - "application/vnd.wap.wbxml" in the same way as - defined for that media type. (At publication of - this document, there is no fragment - identification syntax defined for "application/ - vnd.wap.wbxml".) Specific media types using - "+wbxml" MAY identify additional fragment - identifier considerations, MAY define processing - for fragment identifiers that are classed as - errors for "application/vnd.wap.wbxml" and MAY - designate fragment identifiers defined for - "application/vnd.wap.wbxml" that SHOULD NOT be - used. + Fragment identifier considerations: + + The syntax and semantics of fragment + identifiers specified for +wbxml SHOULD be as + specified for "application/vnd.wap.wbxml". + (At publication of this document, there is no + fragment identification syntax defined for + "application/vnd.wap.wbxml".) + + 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". + + 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) @@ -322,32 +390,44 @@ Syntax Suffix registration form follows: Name: ZIP file storage and transfer format +suffix: +zip References: [ZIP] Encoding considerations: ZIP is a binary encoding. - Fragment identifier considerations: Media types using "+zip" SHOULD - process any fragment identifiers defined for - "application/zip" in the same way as defined for - that media type. (At publication of this - document, there is no fragment identification - syntax defined for "application/zip".) Specific - media types using "+zip" MAY identify additional - fragment identifier considerations, MAY define - processing for fragment identifiers that are - classed as errors for "application/zip" and MAY - designate fragment identifiers defined for - "application/zip" that SHOULD NOT be used. + Fragment identifier considerations: + + The syntax and semantics of fragment + identifiers specified for +zip SHOULD be as + specified for "application/zip". (At + publication of this document, there is no + fragment identification syntax defined for + "application/zip".) + + The syntax and semantics for fragment + identifiers for a specific "xxx/yyy+zip" + SHOULD be processed as follows: + + For cases defined in +zip, where the + fragment identifier resolves per the +zip + rules, then as specified in +zip. + + For cases defined in +zip, where the + fragment identifier does not resolve per + the +zip rules, then as specified in "xxx/ + yyy+zip". + + For cases not defined in +zip, then as + specified in "xxx/yyy+zip". Interoperability considerations: n/a Security considerations: ZIP files support two forms of encryption: Strong Encryption and AES 128-bit, 192-bit and 256-bit encryption; see the specification for further details. Each individual media type registered with a +zip suffix can have additional security considerations. @@ -356,33 +436,46 @@ 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 - Fragment identifier considerations: Media types using "+xml" SHOULD - process any fragment identifiers defined for - "application/xml" in the same way as defined for - that media type. (At publication of this - document, the fragment identification syntax - considerations for "application/xml" are defined - in [RFC3023], sections 5 and 7.) Specific media - types using "+xml" MAY identify additional - fragment identifier considerations, MAY define - processing for fragment identifiers that are - classed as errors for "application/xml" and MAY - designate fragment identifiers defined for - "application/xml" that SHOULD NOT be used. + + 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.) + + The syntax and semantics for fragment + identifiers for a specific "xxx/yyy+xml" + SHOULD be processed as follows: + + For cases defined in +xml, where the + fragment identifier resolves per the +xml + 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". 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. 6. References 6.1. Normative References @@ -419,33 +512,47 @@ Requirement Levels", BCP 14, RFC 2119, March 1997. [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", Internet- - Draft draft-ietf-appsawg-media-type-regs-09, May 2012. + Draft draft-ietf-appsawg-media-type-regs-14, June 2012. Appendix A. Change History This section is to be removed before publication. + draft-ietf-appsawg-media-type-suffix-regs-02 Added BER/DER security + considerations. + 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. + 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. Author's Address Tony Hansen AT&T Laboratories 200 Laurel Ave. South