From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6839.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc6839.txt (limited to 'doc/rfc/rfc6839.txt') diff --git a/doc/rfc/rfc6839.txt b/doc/rfc/rfc6839.txt new file mode 100644 index 0000000..5c74022 --- /dev/null +++ b/doc/rfc/rfc6839.txt @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Hansen +Request for Comments: 6839 AT&T Laboratories +Updates: 3023 A. Melnikov +Category: Informational Isode Ltd +ISSN: 2070-1721 January 2013 + + + Additional Media Type Structured Syntax Suffixes + +Abstract + + A content media type name sometimes includes partitioned meta- + information distinguished 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 provides a media type structured syntax suffix + registration form for the "+xml" structured syntax suffix. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6839. + + + + + + + + + + + + + + + + +Hansen & Melnikov Informational [Page 1] + +RFC 6839 Additional Media Type Suffixes January 2013 + + +Copyright Notice + + Copyright (c) 2013 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 Suffix . . . . . . . . . . . . 5 + 3.3. The +der Structured Syntax Suffix . . . . . . . . . . . . 6 + 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 7 + 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 9 + 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 10 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 4.1. The +xml Structured Syntax Suffix . . . . . . . . . . . . 11 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + + + + + + + + +Hansen & Melnikov Informational [Page 2] + +RFC 6839 Additional Media Type Suffixes January 2013 + + +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. [RFC6838] + defines the media type "Structured Syntax Suffix 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 the procedure defined in [RFC6838]. + + 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 + + Each of the structured syntax suffixes defined in this document is + appropriate for use when the media type identifies the semantics of + the protocol payload. That is, knowing the semantics of the specific + media type provides for more specific processing of the content than + that afforded by generic processing of the underlying representation. + + At the same time, using the suffix allows receivers of the media + types to do generic processing of the underlying representation in + cases where + + they do not need to perform special handling of the particular + semantics of the exact media type, and + + there is no special knowledge needed by such a generic processor + in order to parse that underlying representation other than what + would be needed to parse any example of that underlying + representation. + + + + + + + + + + +Hansen & Melnikov Informational [Page 3] + +RFC 6839 Additional Media Type Suffixes January 2013 + + +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 media type structured + syntax suffix registration form follows. See [RFC6838] 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 ([RFC2045]). When JSON is written in UTF-16 or UTF-32, + JSON is binary ([RFC2045]). + + 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 process as specified in +json. + + For cases defined in +json, where the fragment identifier does + not resolve per the +json rules, then process as specified in + "xxx/yyy+json". + + For cases not defined in +json, then process as specified in + "xxx/yyy+json". + + Interoperability considerations: n/a + + Security considerations: See [RFC4627] + + Contact: Apps Area Working Group (apps-discuss@ietf.org) + + + +Hansen & Melnikov Informational [Page 4] + +RFC 6839 Additional Media Type Suffixes January 2013 + + + Author/Change controller: + + The Apps Area Working Group. IESG has change control over this + registration. + +3.2. The +ber Structured Syntax Suffix + + The ITU defined the Basic Encoding Rules (BER) transfer syntax in + [ITU.X690.2008]. The suffix "+ber" MAY be used with any media type + whose representation follows the BER transfer syntax. (The Expert + Reviewer for media type structured syntax suffix registrations ought + to be aware of the relationship between BER and DER to aid in + selecting the proper suffix.) The media type structured syntax + suffix registration form for +ber follows: + + Name: Basic Encoding Rules (BER) transfer syntax + + +suffix: +ber + + References: [ITU.X690.2008] + + Encoding considerations: BER is a binary encoding. + + Fragment identifier considerations: + + At publication of this document, there is no fragment + identification syntax defined for +ber. + + The syntax and semantics for fragment identifiers for a specific + "xxx/yyy+ber" SHOULD be processed as follows: + + For cases defined in +ber, where the fragment identifier + resolves per the +ber rules, then process as specified in +ber. + + For cases defined in +ber, where the fragment identifier does + not resolve per the +ber rules, then process as specified in + "xxx/yyy+ber". + + For cases not defined in +ber, then process 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 considerations. + + + + +Hansen & Melnikov Informational [Page 5] + +RFC 6839 Additional Media Type Suffixes January 2013 + + + 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. + + 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. IESG has change control over this + registration. + +3.3. The +der Structured Syntax Suffix + + The ITU defined the Distinguished Encoding Rules (DER) transfer + syntax in [ITU.X690.2008]. The suffix "+der" MAY be used with any + media type whose representation follows the DER transfer syntax. + (The Expert Reviewer for media type structured syntax suffix + registrations ought to be aware of the relationship between BER and + DER to aid in selecting the proper suffix.) The media type + structured syntax suffix registration form for +der follows: + + Name: Distinguished Encoding Rules (DER) 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" SHOULD be processed as follows: + + For cases defined in +der, where the fragment identifier + resolves per the +der rules, then process as specified in +der. + + + +Hansen & Melnikov Informational [Page 6] + +RFC 6839 Additional Media Type Suffixes January 2013 + + + For cases defined in +der, where the fragment identifier does + not resolve per the +der rules, then process as specified in + "xxx/yyy+der". + + For cases not defined in +der, then process 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 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. + + 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. IESG 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 + documents further define the "application/fastinfoset" media type. + The suffix "+fastinfoset" MAY be used with any media type whose + representation follows that established for "application/ + fastinfoset". The media type structured syntax suffix registration + form follows: + + Name: Fast Infoset document format + + +suffix: +fastinfoset + + + + +Hansen & Melnikov Informational [Page 7] + +RFC 6839 Additional Media Type Suffixes January 2013 + + + 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: + + 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 process as + specified in +fastinfoset. + + For cases defined in +fastinfoset, where the fragment + identifier does not resolve per the +fastinfoset rules, then + process as specified in "xxx/yyy+fastinfoset". + + For cases not defined in +fastinfoset, then process 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) + + Author/Change controller: + + The Apps Area Working Group. IESG has change control over this + registration. + + + + + + + + +Hansen & Melnikov Informational [Page 8] + +RFC 6839 Additional Media Type Suffixes January 2013 + + +3.5. The +wbxml Structured Syntax Suffix + + The Wireless Application Protocol (WAP) Forum has defined the WAP + Binary XML (WBXML) document format as a binary representation of XML + in [WBXML]. This document further defines the "application/ + vnd.wap.wbxml" media type. The suffix "+wbxml" MAY be used with any + media type whose representation follows that established for + "application/vnd.wap.wbxml". The media type 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: + + 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 process as specified in + +wbxml. + + For cases defined in +wbxml, where the fragment identifier does + not resolve per the +wbxml rules, then process as specified in + "xxx/yyy+wbxml". + + For cases not defined in +wbxml, then process 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) + + + +Hansen & Melnikov Informational [Page 9] + +RFC 6839 Additional Media Type Suffixes January 2013 + + + Author/Change controller: + + The Apps Area Working Group. IESG has change control over this + registration. + +3.6. The +zip Structured Syntax Suffix + + The ZIP format is a public domain, cross-platform, interoperable file + storage and transfer format, originally defined by PKWARE, Inc.; it + supports compression and encryption and is used as the underlying + representation by a variety of file formats. The media type + "application/zip" has been registered for such files. The suffix + "+zip" MAY be used with any media type whose representation follows + that established for "application/zip". The media type structured + 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: + + 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 process as specified in +zip. + + For cases defined in +zip, where the fragment identifier does + not resolve per the +zip rules, then process as specified in + "xxx/yyy+zip". + + For cases not defined in +zip, then process as specified in + "xxx/yyy+zip". + + Interoperability considerations: n/a + + + + + + +Hansen & Melnikov Informational [Page 10] + +RFC 6839 Additional Media Type Suffixes January 2013 + + + Security considerations: + + IP 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. + + Contact: Apps Area Working Group (apps-discuss@ietf.org) + + Author/Change controller: The Apps Area Working Group. IESG has + change control over this registration. + +4. IANA Considerations + + See the media type structured syntax suffix registration forms in + Sections 3.1 - 3.6. + +4.1. The +xml Structured Syntax Suffix + + 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. (Note that [RFC3023] + is in the process of being updated by [XML-MEDIATYPES].) + + 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.) + + + + + + +Hansen & Melnikov Informational [Page 11] + +RFC 6839 Additional Media Type Suffixes January 2013 + + + 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 process as specified in +xml. + + For cases defined in +xml, where the fragment identifier does + not resolve per the +xml rules, then process as specified in + "xxx/yyy+xml". + + For cases not defined in +xml, then process 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. IESG has change control over this + registration. + +5. Security Considerations + + See the Security Considerations sections found in the media type + structured syntax suffix registration forms from Sections 3 and 4. + + 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 + precedence over media-type-specific rules, introducing new or + changing existing definitions may break the existing registrations of + specific media types, as well as particular implementations of + applications that process affected media types. Such changes can + introduce interoperability and security issues. + + When updating the fragment identifier processing rules for a specific + xxx/yyy+ media type, care should be taken to review the + generic fragment identifier processing rules for the + + registration and not introduce any conflicts. Because the generic + fragment identifier processing rules take precedence over media-type- + specific rules, such conflicting processing requirements should be + ignored by an implementation, but such conflicts can introduce + interoperability and security issues. + + + + +Hansen & Melnikov Informational [Page 12] + +RFC 6839 Additional Media Type Suffixes January 2013 + + + Note that [FRAGID-BP] provides additional advice to designers of + fragment identifier rules for media type suffixes and specific media + types. + +6. References + +6.1. Normative References + + [RFC4627] Crockford, D., "The application/json Media Type for + JavaScript Object Notation (JSON)", RFC 4627, July 2006. + + [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. + + [WBXML] Open Mobile Alliance, "Binary XML Content Format + 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 + 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 + Types", RFC 3023, January 2001. + +6.2. Informative References + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, January 2013. + + + + +Hansen & Melnikov Informational [Page 13] + +RFC 6839 Additional Media Type Suffixes January 2013 + + + [FRAGID-BP] + Tennison, J., "Best Practices for Fragment Identifiers and + Media Type Definitions", July 2012, + . + + [XML-MEDIATYPES] + Lilley, C., Makoto, M., Melnikov, A., and H. Thompson, + "XML Media Types", Work in Progress, November 2012. + +Authors' Addresses + + Tony Hansen + AT&T Laboratories + 200 Laurel Ave. South + Middletown, NJ 07748 + USA + + EMail: tony+sss@maillennium.att.com + + + Alexey Melnikov + Isode Ltd + 5 Castle Business Village + 36 Station Road + Hampton, Middlesex TW12 2BX + UK + + EMail: Alexey.Melnikov@isode.com + + + + + + + + + + + + + + + + + + + + + + + +Hansen & Melnikov Informational [Page 14] + -- cgit v1.2.3