Structured Syntax Suffixes
Multipurpose Internet Mail Extensions (MIME) and Media Types
2012-07-20
2024-02-16
Structured Syntax Suffixes
Expert Review
Alexey Melnikov, Darrel Miller
Extensible Markup Language (XML)
+xml
Same as , Section 9.1.
Same as , Section 9.1.
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 Section 10, .
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
section 8.1 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 Section 10 of
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 Section 2.2
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 Section 3
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
RFC7519, Section 3
RFC8417, Section 7.2
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 Section 11 of .
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 , Section 5
Zstandard
+zstd
binary
N/A
The syntax and semantics of
fragment identifiers specified for +zstd should be as specified
for "application/zstd".
See Section 8 of .
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 Section 4.3 of . If the parameter
"cose-type" is allowed, its usage MUST be identical to the
usage defined for the "application/cose" media type in
Section 2 of .
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 WG mailing list
mailto:cbor&ietf.org
2019-10-10
Clemens Ladisch
mailto:clemens&ladisch.de
2018-02-12
IETF
mailto:iesg&ietf.org
John Mudge
mailto:helpdesk&omaorg.org
2016-06-19
Michael B. Jones
mailto:mbjµsoft.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