Multipurpose Internet Mail Extensions (MIME) and Media Types 2012-07-20 2026-01-15 Expert Review Alexey Melnikov, Darrel Miller Extensible Markup Language (XML) +xml Same as . Same as . See above, and also Section 3, for guidelines on the use of the 'charset' parameter. Registrations which use this '+xml' convention MUST also make reference to , specifically Section 5, in specifying fragment identifier syntax and semantics, and they MAY restrict the syntax to a specified subset of schemes, except that they MUST NOT disallow barenames or 'element' scheme pointers. They MAY further require support for other registered schemes. They also MAY add additional syntax (which MUST NOT overlap with XPointerFramework syntax) together with associated semantics, and MAY add additional semantics for barename XPointers which, as provided for in Section 5, will only apply when does not define an interpretation. In practice these constraints imply that for a fragment identifier addressed to an instance of a specific "xxx/yyy+xml" type, there are three cases: For fragment identifiers matching the syntax defined in XPointerFramework, where the fragment identifier resolves per the rules specified there, then process as specified there; For fragment identifiers matching the syntax defined in XPointerFramework, where the fragment identifier does _not_ resolve per the rules specified there, then process as specified in "xxx/yyy+xml"; For fragment identifiers _not_ matching the syntax defined in XPointerFramework, then process as specified in "xxx/ yyy+xml". A fragment identifier of the form "xywh=160,120,320,240", as defined in MediaFrags, which might be used in a URI for an XML-encoded image, would fall in this category. See . See Authors' Addresses section, . The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over . 2014-04-17 JavaScript Object Notation (JSON) +json JSON is encoded using UTF-8, and is binary data. See for additional encoding considerations. n/a The syntax and semantics of fragment identifiers specified for +json SHOULD be as specified for "application/json". (At publication of , 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 , 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. Concise Binary Object Representation (CBOR) +cbor CBOR is a binary format. n/a The syntax and semantics of fragment identifiers specified for +cbor SHOULD be as specified for "application/cbor". (At publication of , there is no fragment identification syntax defined for "application/ cbor".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+cbor" SHOULD be processed as follows: * For cases defined in +cbor, where the fragment identifier resolves per the +cbor rules, then process as specified in +cbor. * For cases defined in +cbor, where the fragment identifier does not resolve per the +cbor rules, then process as specified in "xxx/yyy+cbor". * For cases not defined in +cbor, then process as specified in "xxx/yyy+cbor". See IETF CBOR Working Group (cbor@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org) IETF (cbor@ietf.org) 2020-10-16 Distinguished Encoding Rules (DER) message transfer syntax +der ITU.X690.2008 DER is a binary encoding. n/a At publication of , 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 , 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 , 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 , 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. Type Length Value +tlv “Lightweight Machine to Machine Technical Specification”, OMA-TS-LightweightM2M-V1_0, especially section 6.3.3 TLV is a binary format. n/a The syntax and semantics of fragment identifiers specified for +tlv should be as specified for "application/vnd.oma.lwm2m+tlv". (At publication of this document, there is no fragment identification syntax defined for "application/vnd.oma.lwm2m+tlv".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+tlv" should be processed as follows: For cases defined in +tlv, where the fragment identifier resolves per the +tlv rules, then process as specified in +tlv. For cases defined in +tlv, where the fragment identifier does not resolve per the +tlv rules, then process as specified in "xxx/yyy+tlv". For cases not defined in +tlv, then process as specified in "xxx/yyy+tlv". Each individual media type registered with a +tlv suffix can have additional security considerations. As with any format with internal length fields, it is easy to construct malicious content with invalid length fields that can cause buffer overrun conditions. TLV allows for arbitrary levels of nesting, which may make it possible to construct malicious content that will cause a stack overflow. Interpreters of the TLV 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. (OMNA) JSON Text Sequence +json-seq See n/a The syntax and semantics of fragment identifiers specified for +json-seq SHOULD be as specified for "application/json-seq". (At publication of , there is no fragment identification syntax defined for "application/json-seq".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+json-seq" SHOULD be processed as follows: For cases defined in +json-seq, where the fragment identifier resolves per the +json-seq rules, then process as specified in +json-seq. For cases defined in +json-seq, where the fragment identifier does not resolve per the +json-seq rules, then process as specified in "xxx/yyy+json-seq". For cases not defined in +json-seq, then process as specified in "xxx/yyy+json-seq". See Applications and Real-Time Area Discussion (art@ietf.org), or any IESG-designated successor. The Applications and Real-Time Area Working Group. IESG has change control over this registration. SQLite3 database +sqlite3 binary Same as for "application/vnd.sqlite3". To allow identification of files when the media type name is not available, each individual "xxx/yyy+sqlite3" registration should specify an appliction ID value to be set with PRAGMA application_id (http://www.sqlite.org/pragma.html#pragma_application_id), and should specifiy it as a second magic number (file offset 68, see http://www.sqlite.org/fileformat2.html#application_id) in addition to the header string at offset 0. This value should also be added to the magic.txt file in the SQLite repository http://www.sqlite.org/src/artifact?ci=trunk&filename=magic.txt) by submitting a patch to <sqlite-users@mailinglists.sqlite.org>. The syntax and semantics of fragment identifiers specified for +sqlite3 should be as specified for "application/vnd.sqlite3". (At publication of this document, there is no fragment identification syntax defined for "application/vnd.sqlite3".) The syntax and semantics of fragment identifiers for a specific "xxx/yyy+sqlite3" should be processed as follows: For cases defined in +sqlite3, where the fragment identifier resolves per the +sqlite3 rules, then as specified in +sqlite3. For cases defined in +sqlite3, where the fragment identifier does not resolve per the +sqlite3 rules, then as specified in "xxx/yyy+sqlite3". For cases not defined in +sqlite3, then as specified in "xxx/yyy+sqlite3". All the security considerations for "application/vnd.sqlite3" apply to any type based on the sqlite3 format. Each individual media type registered with a +sqlite3 suffix can have additional security considerations. For example, if a specific registration requires that certain extension functions are available, or that blob fields contain data to be processed by other libraries or external tools, or if only a single implementation exists to handle a specific registered media type, then this increases the known attack surface available to an attacker. JSON Web Token (JWT) +jwt binary; JWT values are encoded as a series of base64url-encoded values (with trailing '=' characters removed), some of which may be the empty string, separated by period ('.') characters. N/A The syntax and semantics of fragment identifiers specified for +jwt SHOULD be as specified for "application/jwt". (At publication of , there is no fragment identification syntax defined for "application/jwt".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+jwt" SHOULD be processed as follows: For cases defined in +jwt where the fragment identifier resolves per the +jwt rules, process as specified in +jwt. For cases defined in +jwt where the fragment identifier does not resolve per the +jwt rules, process as specified in "xxx/yyy+jwt". For cases not defined in +jwt, process as specified in "xxx/ yyy+jwt". See . Security Events Working Group. The IESG has change control over this registration. gzip file storage and transfer format +gzip gzip is a binary encoding. n/a The syntax and semantics of fragment identifiers specified for +gzip SHOULD be as specified for "application/gzip". (At publication of , there is no fragment identification syntax defined for "application/gzip".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+gzip" SHOULD be processed as follows: For cases defined in +gzip, where the fragment identifier resolves per the +gzip rules, process as specified in +gzip. For cases defined in +gzip, where the fragment identifier does not resolve per the +gzip rules, process as specified in "xxx/yyy+gzip". For cases not defined in +gzip, process as specified in "xxx/yyy+gzip". gzip format doesn't provide confidentiality protection. Integrity protection is provided by an Adler-32 checksum, which is not cryptographically strong. See also the security considerations of . Each individual media type registered with a +gzip suffix can have additional security considerations. Additionally, gzip objects can contain multiple files and associated paths. File paths must be validated when the files are extracted; a malicious file path could otherwise cause the extractor to overwrite application or system files. art@ietf.org CBOR Sequence +cbor-seq binary n/a The syntax and semantics of fragment identifiers specified for +cbor-seq SHOULD be as specified for "application/cbor-seq". (At publication of , there is no fragment identification syntax defined for "application/cbor-seq".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+cbor-seq" SHOULD be processed as follows: For cases defined in +cbor-seq, where the fragment identifier resolves per the +cbor-seq rules, then process as specified in +cbor-seq. For cases defined in +cbor-seq, where the fragment identifier does not resolve per the +cbor-seq rules, then process as specified in "xxx/yyy+cbor-seq". For cases not defined in +cbor-seq, then process as specified in "xxx/yyy+cbor-seq". See Zstandard +zstd binary N/A The syntax and semantics of fragment identifiers specified for +zstd should be as specified for "application/zstd". See . Refer to the author for the 'application/zstd' media type. YAML Ain't Markup Language (YAML) +yaml YAML Same as application/yaml Same as application/yaml Unlike application/yaml, there is no fragment identification syntax defined for +yaml. A specific xxx/yyy+yaml media type needs to define the syntax and semantics for fragment identifiers because the ones defined for application/yaml do not apply unless explicitly expressed. Same as application/yaml httpapi@ietf.org or art@ietf.org CBOR Object Signing and Encryption (COSE) object +cose the "application/cose" media type binary (CBOR) The "application/cose" media type has an optional parameter "cose-type". Any new media type that uses the +cose suffix and allows use of this parameter MUST specify this explicitly, per . If the parameter "cose-type" is allowed, its usage MUST be identical to the usage defined for the "application/cose" media type in . A COSE processor handling a media type "foo+cose" and which does not know the specific type "foo" SHOULD use the cose-type tag, if present, or cose-type parameter, if present, to determine the specific COSE object type during processing. If the specific type cannot be determined, it MUST assume only the generic COSE object structure and it MUST NOT perform security-critical operations using the COSE object. N/A See IETF COSE Working Group or IETF (iesg@ietf.org) IETF ANIMA Working Group (iesg@ietf.org). The IETF has change control over this registration. CBOR Web Token (CWT) +cwt binary N/A The syntax and semantics of fragment identifiers specified for +cwt SHOULD be as specified for application/cwt. (At publication of this document, there is no fragment identification syntax defined for application/cwt.) See . RATS WG mailing list (rats@ietf.org), or IETF Security Area (saag@ietf.org) Remote ATtestation ProcedureS (RATS) Working Group. The IETF has change control over this registration. SD-JWT +sd-jwt binary; SD-JWT values are a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') or tilde ('~') characters. N/A N/A See the Security Considerations sections of , , and . Comma-Separated Values (CSV) +csv Same as "text/csv". Same as "text/csv". The syntax and semantics of fragment identifiers specified for +csv SHOULD be as specified for "text/csv". The syntax and semantics for fragment identifiers for a specific "xxx/yyy+csv" SHOULD be processed as follows: For cases defined in +csv, where the fragment identifier resolves per the +csv rules, then as specified for +csv. For cases defined in +csv, where the fragment identifier does not resolve per the +csv rules, then as specified for "xxx/yyy+csv". For cases not defined in +csv, then as specified for "xxx/yyy+csv". Same as "text/csv". ASN.1 Unaligned Packed Encoding Rules +uper ITU-T X.691 Unaligned Packed Encoding Rules The encoding considerations of ITU-T X.691 Unaligned Packed Encoding Rules apply. The interoperability considerations of ITU-T X.691 Unaligned Packed Encoding Rules apply. N/A The security considerations of ITU-T X.691 Unaligned Packed Encoding Rules apply. ASN.1 JSON Encoding Rules +jer ITU-T X.697 JSON Encoding Rules The encoding considerations of ITU-T X.697 JSON Encoding Rules apply. The interoperability considerations of ITU-T X.697 JSON Encoding Rules apply. N/A The security considerations of ITU-T X.697 JSON Encoding Rules apply. JSON Web Signature (JWS) +jws binary; values are represented as a JSON Object or as a series of base64url-encoded values each separated from the next by a single period ('.') character. N/A N/A See RATS WG mailing list (rats@ietf.org) or IETF Security Area (saag@ietf.org) Remote ATtestation ProcedureS (RATS) Working Group. The IETF has change control over this registration. SD-CWT +sd-cwt binary N/A N/A See Authors' Adresses section of IETF AS207960 Cyfyngedig mailto:hello&glauca.digital 2025-09-22 CBOR WG mailing list mailto:cbor&ietf.org 2019-10-10 Clemens Ladisch mailto:clemens&ladisch.de 2018-02-12 Daniel Fett mailto:mail&danielfett.de 2025-05-30 IETF mailto:iesg&ietf.org ITU-T https://www.itu.int John Mudge mailto:helpdesk&omaorg.org 2016-06-19 Michael B. Jones mailto:mbj&microsoft.com 2018-05-15 Open Mobile Naming Authority (OMNA) mailto:helpdesk&omaorg.org 2016-06-19 SQLite mailing list mailto:sqlite-users&mailinglists.sqlite.org 2018-02-12