RFC 6839

Additional Media Type Structured Syntax Suffixes

📅 published January 2013, from ietf

RFC 6839: Additional Media Type Structured Syntax Suffixes 🎀

okay bestie, this one is the RFC that gives media type names their little suffix tags 🦋 the rest of the doc is in a fenced block to keep it accurate. Here's the title block tea:

  • RFC number: 6839
  • Title: Additional Media Type Structured Syntax Suffixes
  • Authors: T. Hansen (AT&T Laboratories) and A. Melnikov (Isode Ltd)
  • Category: Informational
  • ISSN: 2070-1721
  • Date: January 2013
  • Updates: 3023

Abstract

so a media type name sometimes carries extra info about the format, kind of like a tag on the end of the name ✨ this doc defines a bunch of those structured syntax suffixes for media type registrations 💅 specifically it defines and registers "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip", and it gives a registration form for "+xml" 🌸

Status of This Memo

not gonna lie, this part is a bit formal 🙈 but the gist is: this is not an Internet Standards Track spec, it's just published for info purposes 💖

it is a product of the IETF, it reflects IETF community consensus, got public review, and was approved by the IESG. not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🧚

for the current status, errata, or to send feedback, go to http://www.rfc-editor.org/info/rfc6839 🍓

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. ✨

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. read those carefully, they explain your rights and restrictions 🫶 and if you pull code out of this doc, it has to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and it comes with no warranty as described in that 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

1. Introduction ✨

okay so [RFC3023] is where the "+xml" suffix convention came from 🌈 it's for media type names whose representation is XML underneath. the vibe is that those things could be parsed successfully as application/xml, even while they're also being parsed as their own suffixed media type 💅 [RFC6838] sets up the media type "Structured Syntax Suffix Registry" for these suffixes 🎀

a bunch of suffixes are already floating around in media type registrations, especially "+json", "+der", "+fastinfoset", and "+wbxml" 🦋 this doc defines and registers them in the Structured Syntax Suffix Registry, plus "+ber" and "+zip" 💖 it also updates [RFC3023] so that "+xml" gets formally registered under the [RFC6838] procedure 🧚

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 🌸

every suffix defined here is a good fit when the media type tells you what the protocol payload means 💜 knowing the exact semantics lets you do more specific processing than you could with generic processing of the underlying representation ✨

the suffix also lets receivers do generic processing of the underlying representation when:

  • they don't need any special handling for the specific semantics of the exact media type, and
  • the generic processor doesn't need any special knowledge to parse that underlying representation beyond what it would need for any example of that representation.

3. Initial Structured Syntax Suffix Definitions 🍓

3.1. The +json Structured Syntax Suffix 🫶

[RFC4627] defines "application/json" 💅 the suffix "+json" MAY be used with any media type whose representation follows the one set up for "application/json" ✨ the registration form is below, and [RFC6838] has the definitions for each heading 🎀

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)

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 these registrations ought to know how BER and DER relate, so they can pick the right suffix 🧠) here's the registration form for +ber:

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.

   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.
⚠️ heads up, BER's security section is serious business 😭 it has a type-length-value structure, so malicious content with bad length fields can cause buffer overrun conditions. it also allows arbitrary nesting, which could let someone build content that causes a stack overflow. anyone interpreting BER structures should be aware of this and take steps to guard against buffer overflows, stack overruns, and malicious content in general 🛡️

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 ✨ (same deal as before: the Expert Reviewer ought to understand how BER and DER relate to pick the right suffix 🫶) the registration form for +der is here:

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.

         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.
⚠️ DER has the same security vibes as BER 😭 type-length-value structures with invalid lengths can cause buffer overrun conditions, and arbitrary nesting could lead to a stack overflow. if you're interpreting DER structures, be aware of this and guard against overflows, stack overruns, and malicious content in general 🛡️

3.4. The +fastinfoset Structured Syntax Suffix ✨

okay so the ITU made the Fast Infoset document format, which is a binary way to represent the XML Information Set 🧚 ([ITU.X891.2005]). These docs also define the "application/fastinfoset" media type 💜. The suffix "+fastinfoset" MAY be used with any media type whose representation follows the one set up for "application/fastinfoset" 🫶. Here's the registration form:

  • Name: Fast Infoset document format
  • +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: The syntax and semantics of fragment identifiers for +fastinfoset SHOULD be the same as for "application/fastinfoset" 🔗. (Right now, when this was published, there is no fragment identification syntax defined for "application/fastinfoset", so no cap there, lol.)

The syntax and semantics for fragment identifiers on a specific "xxx/yyy+fastinfoset" SHOULD be processed like this:

  • For cases defined in +fastinfoset, if the fragment identifier resolves under the +fastinfoset rules, process it as specified in +fastinfoset.
  • For cases defined in +fastinfoset, if the fragment identifier does not resolve under the +fastinfoset rules, process it as specified in "xxx/yyy+fastinfoset".
  • For cases not defined in +fastinfoset, process it 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.

3.5. The +wbxml Structured Syntax Suffix 🦋

The WAP Forum came up with WAP Binary XML (WBXML), a binary representation of XML ([WBXML]) 🌸. This doc also defines the "application/vnd.wap.wbxml" media type. The suffix "+wbxml" MAY be used with any media type whose representation follows the one set up for "application/vnd.wap.wbxml" 💖. Registration form time:

  • 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 for +wbxml SHOULD be the same as 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 on a specific "xxx/yyy+wbxml" SHOULD be processed like this:

  • For cases defined in +wbxml, if the fragment identifier resolves under the +wbxml rules, process it as specified in +wbxml.
  • For cases defined in +wbxml, if the fragment identifier does not resolve under the +wbxml rules, process it as specified in "xxx/yyy+wbxml".
  • For cases not defined in +wbxml, process it 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. IESG has change control over this registration.

3.6. The +zip Structured Syntax Suffix 📦

ZIP is a public domain, cross-platform, interoperable file storage and transfer format that was first defined by PKWARE, Inc. 🌈 It supports compression and encryption, and a bunch of file formats use it as their underlying representation. The media type "application/zip" has been registered for these files. The suffix "+zip" MAY be used with any media type whose representation follows the one set up for "application/zip" ✨. Here's the form:

  • 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 for +zip SHOULD be the same as 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 on a specific "xxx/yyy+zip" SHOULD be processed like this:

  • For cases defined in +zip, if the fragment identifier resolves under the +zip rules, process it as specified in +zip.
  • For cases defined in +zip, if the fragment identifier does not resolve under the +zip rules, process it as specified in "xxx/yyy+zip".
  • For cases not defined in +zip, process it as specified in "xxx/yyy+zip".
  • Interoperability considerations: n/a
  • Security considerations: IP files support two forms of encryption: Strong Encryption and AES 128-bit, 192-bit, and 256-bit encryption 🔐. Check the specification for the 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 +xml registration below shall be used to reflect the info in [RFC3023], plus the addition of fragment identifier considerations. (Heads up: [RFC3023] is currently getting 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 for +xml SHOULD be the same as 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 on a specific "xxx/yyy+xml" SHOULD be processed like this:

  • For cases defined in +xml, if the fragment identifier resolves under the +xml rules, process it as specified in +xml.
  • For cases defined in +xml, if the fragment identifier does not resolve under the +xml rules, process it as specified in "xxx/yyy+xml".
  • For cases not defined in +xml, process it 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 🔥

Check out the Security Considerations sections in the media type structured syntax suffix registration forms from Sections 3 and 4. This is a big deal, bestie 😭.

When you update a +<suffix> registration, you need to carefully review every previously-registered xxx/yyy+<suffix> media type to see whether any of them might be affected by the updated +<suffix> registration. The generic fragment identifier processing rules take precedence over media-type-specific rules, so introducing new definitions or changing existing ones may break existing media type registrations, plus particular implementations of applications that process the affected media types. Those changes can cause interoperability and security issues 💀.

When you update the fragment identifier processing rules for a specific xxx/yyy+<suffix> media type, you should check the generic fragment identifier processing rules for the +<suffix> registration and make sure you don't introduce any conflicts. Because the generic rules take precedence over media-type-specific rules, any conflicting processing requirements should be ignored by an implementation, but those conflicts can still cause interoperability and security issues 🙈.

Also, [FRAGID-BP] gives extra 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.
  • [FRAGID-BP] Tennison, J., "Best Practices for Fragment Identifiers and Media Type Definitions", July 2012, <http://www.w3.org/TR/fragid-best-practices/>.
  • [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
📦 where this page comes from