Multipurpose Internet Mail Extensions (MIME) and Media Types 2012-07-20 2013-01-31 Expert Review Ned Freed Extensible Markup Language (XML) +xml Per , 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 (). When XML is written in UTF-16 or UTF-32, XML is binary (). See . 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 , 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". See . Apps Area Working Group (apps-discuss@ietf.org) The Apps Area Working Group. IESG has change control over this registration. JavaScript Object Notation (JSON) +json Per , 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 (). When JSON is written in UTF-16 or UTF-32, JSON is binary (). n/a 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". See . Apps Area Working Group (apps-discuss@ietf.org) The Apps Area Working Group. IESG has change control over this registration. Basic Encoding Rules (BER) message transfer syntax +ber ITU.X690.2008 BER is a binary encoding. n/a 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 as specified in +ber. 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". 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. Apps Area Working Group (apps-discuss@ietf.org) The Apps Area Working Group. IESG has change control over this registration. Distinguished Encoding Rules (DER) message transfer syntax +der ITU.X690.2008 DER is a binary encoding. n/a 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 as specified in +der. 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". 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. Apps Area Working Group (apps-discuss@ietf.org) The Apps Area Working Group. IESG has change control over this registration. Fast Infoset document format +fastinfoset ITU.X891.2005 Fast Infoset is a binary encoding. The binary, quoted-printable and base64 content- transfer-encodings are suitable for use with Fast Infoset. n/a 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". There are no security considerations inherent in Fast Infoset. Each individual media type registered with a +fastinfoset suffix can have additional security considerations. Apps Area Working Group (apps-discuss@ietf.org) The Apps Area Working Group. IESG has change control over this registration. WAP Binary XML (WBXML) document format +wbxml Open Mobile Alliance, "Binary XML Content Format Specification", OMA Wireless Access Protocol WAP-192- WBXML-20010725-a, July 2001. WBXML is a binary encoding. n/a 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". There are no security considerations inherent in WBXML. Each individual media type registered with a +wbxml suffix can have additional security considerations. Apps Area Working Group (apps-discuss@ietf.org) The Apps Area Working Group. IESG has change control over this registration. ZIP file storage and transfer format +zip PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format Specification", PKWARE .ZIP File Format Specification - Version 6.3.2, September 2007. ZIP is a binary encoding. n/a 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". 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. Apps Area Working Group (apps-discuss@ietf.org) The Apps Area Working Group. IESG has change control over this registration.