Internet Assigned Numbers Authority • Domains • Protocols • Numbers • About Structured Syntax Suffixes Created 2012-07-20 Last Updated 2026-06-25 Available Formats [IMG] XML [IMG] HTML [IMG] TXT Registry Included Below • Structured Syntax Suffixes Structured Syntax Suffixes Registration Procedure(s) Expert Review Expert(s) Alexey Melnikov, Darrel Miller Reference [RFC 6838] Available Formats [IMG] CSV Name +suffix References Encoding Interoperability Considerations Fragment Identifier Security Considerations Contact Author/Change Controller Registration Modification Considerations Considerations Date Date(s) Registrations which use this '+xml' convention MUST also make reference to [RFC 7303], 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 [RFC 7303] does not define an interpretation. In practice these constraints imply that for a fragment The XML specification is a Extensible identifier addressed to an work product of the World Wide Markup Language +xml [RFC 7303] Same as [RFC 7303, Same as [RFC 7303, Section 9.1]. See above, and also Section 3, instance of a specific See [RFC 7303, Section 10]. See Authors' Addresses Web Consortium's XML Core 2012-11-15 2014-04-17 (XML) Section 9.1]. for guidelines on the use of the 'charset' parameter. "xxx/yyy+xml" type, there are section, [RFC 7303]. Working Group. The W3C has three cases: change control over [RFC 7303]. 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. The syntax and semantics of fragment identifiers specified for +json SHOULD be as specified for "application/json". (At publication of [RFC 6839], there is no fragment identification syntax defined for "application/json".) JSON is encoded The syntax and semantics for using UTF-8, and fragment identifiers for a is binary data. specific "xxx/yyy+json" SHOULD be JavaScript See [RFC 8259, processed as follows: Apps Area Working Group The Apps Area Working Group. Object Notation +json [RFC 8259]; [RFC 6839] Section 8.1] for n/a See [RFC 8259]. (apps-discuss@ietf.org) IESG has change control over 2012-11-27 (JSON) additional For cases defined in +json, where this registration. encoding the fragment identifier resolves considerations. 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". Each individual media type registered with a +ber At publication of [RFC 6839], suffix can have additional there is no fragment security considerations. identification syntax defined for +ber. BER has a type-length-value structure, and it is easy to The syntax and semantics for construct malicious content fragment identifiers for a with invalid length fields specific "xxx/yyy+ber" SHOULD be that can cause buffer processed as follows: overrun conditions. Basic Encoding Rules (BER) BER is a binary For cases defined in +ber, where BER allows for arbitrary Apps Area Working Group The Apps Area Working Group. message +ber [ITU.X690.2008]; [RFC 6839] encoding. n/a the fragment identifier resolves levels of nesting, which may (apps-discuss@ietf.org) IESG has change control over 2012-11-27 transfer syntax per the +ber rules, then as make it possible to this registration. specified in +ber. construct malicious content that will cause a stack For cases defined in +ber, where overflow. the fragment identifier does not resolve per the +ber rules, then Interpreters of the BER as specified in "xxx/ yyy+ber". structures should be aware of these issues and should For cases not defined in +ber, take appropriate measures to then as specified in guard against buffer "xxx/yyy+ber". overflows and stack overruns in particular and malicious content in general. The syntax and semantics of fragment identifiers specified for +cbor SHOULD be as specified for "application/cbor". (At publication of [RFC 8949], 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 Concise Binary processed as follows: IETF CBOR Working Group Object CBOR is a binary (cbor@ietf.org) or IETF Representation +cbor [RFC 8949] format. n/a * For cases defined in +cbor, See [RFC 8949, Section 10] Applications and Real-Time IETF (cbor@ietf.org) 2013-09-19 2020-10-16 (CBOR) where the fragment identifier Area (art@ietf.org) 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". Each individual media type registered with a +der At publication of [RFC 6839], suffix can have additional there is no fragment security considerations. identification syntax defined for +der. DER has a type-length-value structure, and it is easy to The syntax and semantics for construct malicious content fragment identifiers for a with invalid length fields specific "xxx/yyy+der" SHOULD be that can cause buffer processed as follows: overrun conditions. Distinguished Encoding Rules DER is a binary For cases defined in +der, where DER allows for arbitrary Apps Area Working Group The Apps Area Working Group. (DER) message +der [ITU.X690.2008]; [RFC 6839] encoding. n/a the fragment identifier resolves levels of nesting, which may (apps-discuss@ietf.org) IESG has change control over 2012-11-27 transfer syntax per the +der rules, then as make it possible to this registration. specified in +der. construct malicious content that will cause a stack For cases defined in +der, where overflow. the fragment identifier does not resolve per the +der rules, then Interpreters of the DER as specified in "xxx/ yyy+der". structures should be aware of these issues and should For cases not defined in +der, take appropriate measures to then as specified in guard against buffer "xxx/yyy+der". overflows and stack overruns in particular and malicious content in general. The syntax and semantics of fragment identifiers specified for +fastinfoset SHOULD be as specified for "application/fastinfoset". (At publication of [RFC 6839], there is no fragment identification syntax defined for "application/fastinfoset".) Fast Infoset is a The syntax and semantics for binary encoding. fragment identifiers for a There are no security The binary, specific "xxx/ yyy+fastinfoset" considerations inherent in quoted-printable SHOULD be processed as follows: Fast Infoset. Each Fast Infoset and base64 individual media type Apps Area Working Group The Apps Area Working Group. document format +fastinfoset [ITU.X891.2005]; [RFC 6839] content- n/a For cases defined in registered with a (apps-discuss@ietf.org) IESG has change control over 2012-11-27 transfer-encodings +fastinfoset, where the fragment +fastinfoset suffix can have this registration. are suitable for identifier resolves per the additional security use with Fast +fastinfoset rules, then as considerations. Infoset. 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". The syntax and semantics of fragment identifiers specified for +wbxml SHOULD be as specified for "application/vnd.wap.wbxml". (At publication of [RFC 6839], there is no fragment identification syntax defined for "application/vnd.wap.wbxml".) The syntax and semantics for fragment identifiers for a There are no security specific "xxx/yyy+wbxml" SHOULD considerations inherent in WAP Binary XML [Open Mobile Alliance, "Binary XML Content be processed as follows: WBXML. Each individual media The Apps Area Working Group. (WBXML) +wbxml Format Specification", OMA Wireless Access WBXML is a binary n/a type registered with a Apps Area Working Group IESG has change control over 2012-11-27 document format Protocol WAP-192- WBXML-20010725-a, July encoding. For cases defined in +wbxml, +wbxml suffix can have (apps-discuss@ietf.org) this registration. 2001.]; [RFC 6839] where the fragment identifier additional security resolves per the +wbxml rules, considerations. 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". The syntax and semantics of fragment identifiers specified for +zip SHOULD be as specified for "application/zip". (At publication of [RFC 6839], there is no fragment identification syntax defined for "application/zip".) ZIP files support two forms The syntax and semantics for of encryption: Strong fragment identifiers for a Encryption and AES 128-bit, [PKWARE, Inc., "APPNOTE.TXT - .ZIP File specific "xxx/yyy+zip" SHOULD be 192-bit and 256-bit ZIP file Format Specification", PKWARE .ZIP File ZIP is a binary processed as follows: encryption; see the Apps Area Working Group The Apps Area Working Group. storage and +zip Format Specification - Version 6.3.2, encoding. n/a specification for further (apps-discuss@ietf.org) IESG has change control over 2012-11-27 transfer format September 2007.]; [RFC 6839] For cases defined in +zip, where details. Each individual this registration. the fragment identifier resolves media type registered with a per the +zip rules, then as +zip suffix can have specified in +zip. additional security considerations. 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". Each individual media type registered with a +tlv The syntax and semantics of suffix can have additional fragment identifiers specified security considerations. for +tlv should be as specified for As with any format with "application/vnd.oma.lwm2m+tlv". internal length fields, it (At publication of this document, is easy to construct there is no fragment malicious content with identification syntax defined for invalid length fields that "application/vnd.oma.lwm2m+tlv".) can cause buffer overrun The syntax and semantics for conditions. [“Lightweight Machine to Machine Technical fragment identifiers for a Type Length +tlv Specification”, TLV is a binary n/a specific "xxx/yyy+tlv" should be TLV allows for arbitrary [John_Mudge] [Open_Mobile_Naming_Authority] 2016-06-19 Value OMA-TS-LightweightM2M-V1_0, especially format. processed as follows: For cases levels of nesting, which may (OMNA) section 6.3.3] defined in +tlv, where the make it possible to fragment identifier resolves per construct malicious content the +tlv rules, then process as that will cause a stack specified in +tlv. For cases overflow. defined in +tlv, where the fragment identifier does not Interpreters of the TLV resolve per the +tlv rules, then structures should be aware process as specified in of these issues and should "xxx/yyy+tlv". For cases not take appropriate measures to defined in +tlv, then process as guard against buffer specified in "xxx/yyy+tlv". overflows and stack overruns in particular and malicious content in general. The syntax and semantics of fragment identifiers specified for +json-seq SHOULD be as specified for "application/json-seq". (At publication of [RFC 8091], 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: Applications and Real-Time The Applications and Real-Time JSON Text +json-seq [RFC 7464]; [RFC 8091] See [RFC 7464, n/a See [RFC 7464, Section 3] Area Discussion Area Working Group. IESG has 2017-01-05 Sequence Section 2.2] For cases defined in +json-seq, (art@ietf.org), or any change control over this where the fragment identifier IESG-designated successor. registration. 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". The syntax and semantics of fragment identifiers specified for +sqlite3 should be as specified for All the security "application/vnd.sqlite3". (At considerations for publication of this document, "application/vnd.sqlite3" there is no fragment apply to any type based on Same as for "application/vnd.sqlite3". identification syntax defined for the sqlite3 format. "application/vnd.sqlite3".) To allow identification of files when the media type name is Each individual media type not available, each individual "xxx/yyy+sqlite3" registration The syntax and semantics of registered with a +sqlite3 should specify an appliction ID value to be set with PRAGMA fragment identifiers for a suffix can have additional application_id specific "xxx/yyy+sqlite3" should security considerations. For SQLite3 [http://www.sqlite.org/fileformat2.html]; (http://www.sqlite.org/pragma.html#pragma_application_id), and be processed as follows: example, if a specific database +sqlite3 [http://www.sqlite.org/lang.html]; binary should specifiy it as a second magic number (file offset 68, registration requires that [SQLite_mailing_list] [Clemens_Ladisch] 2018-02-12 [Clemens_Ladisch] see http://www.sqlite.org/fileformat2.html#application_id) in For cases defined in +sqlite3, certain extension functions addition to the header string at offset 0. This value should where the fragment identifier are available, or that blob also be added to the magic.txt file in the SQLite repository resolves per the +sqlite3 rules, fields contain data to be http://www.sqlite.org/src/artifact?ci=trunk&filename=magic.txt) then as specified in +sqlite3. processed by other libraries by submitting a patch to or external tools, or if . For cases defined in +sqlite3, only a single implementation where the fragment identifier exists to handle a specific does not resolve per the +sqlite3 registered media type, then rules, then as specified in this increases the known "xxx/yyy+sqlite3". attack surface available to an attacker. For cases not defined in +sqlite3, then as specified in "xxx/yyy+sqlite3". The syntax and semantics of fragment identifiers specified for +jwt SHOULD be as specified for "application/jwt". (At publication of [RFC 8417], there is no fragment identification syntax defined for binary; JWT values "application/jwt".) are encoded as a series of The syntax and semantics for base64url-encoded fragment identifiers for a values (with specific "xxx/yyy+jwt" SHOULD be trailing '=' processed as follows: Security Events Working Group. JSON Web Token +jwt [RFC 7519, Section 3]; [RFC 8417, Section characters N/A See [RFC 7519, Section 11]. [Michael_B._Jones] The IESG has change control 2018-05-15 (JWT) 7.2] removed), some of For cases defined in +jwt where over this registration. which may be the the fragment identifier resolves empty string, per the +jwt rules, process as separated by specified in +jwt. period ('.') characters. 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". The syntax and semantics of fragment identifiers specified for +gzip SHOULD be as specified for "application/gzip". (At gzip format doesn't provide publication of [RFC 8460], there confidentiality protection. is no fragment identification Integrity protection is syntax defined for provided by an Adler-32 "application/gzip".) The syntax checksum, which is not and semantics for fragment cryptographically strong. identifiers for a specific See also the security "xxx/yyy+gzip" SHOULD be considerations of [RFC processed as follows: 6713]. Each individual media gzip file gzip is a binary type registered with a +gzip storage and +gzip [RFC 1952]; [RFC 6713] encoding. n/a For cases defined in +gzip, where suffix can have additional art@ietf.org [IETF] 2018-06-14 transfer format the fragment identifier resolves security considerations. per the +gzip rules, process as Additionally, gzip objects specified in +gzip. can contain multiple files and associated paths. File For cases defined in +gzip, where paths must be validated when the fragment identifier does not the files are extracted; a resolve per the +gzip rules, malicious file path could process as specified in otherwise cause the "xxx/yyy+gzip". extractor to overwrite application or system files. For cases not defined in +gzip, process as specified in "xxx/yyy+gzip". The syntax and semantics of fragment identifiers specified for +cbor-seq SHOULD be as specified for "application/cbor-seq". (At publication of [RFC 8742], 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: CBOR Sequence +cbor-seq [RFC 8742] binary n/a See [RFC 8742, Section 5] [CBOR_WG_mailing_list] [IETF] 2019-10-10 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". The syntax and semantics of Refer to the author for the Zstandard +zstd [RFC 8878] binary N/A fragment identifiers specified See [RFC 8878, Section 8]. 'application/zstd' media [IETF] 2020-05-19 for +zstd should be as specified type. for "application/zstd". Unlike application/yaml, there is no fragment identification syntax defined for +yaml. YAML Ain't Same as A specific xxx/yyy+yaml media httpapi@ietf.org or Markup Language +yaml [YAML]; [RFC 9512] application/yaml Same as application/yaml type needs to define the syntax Same as application/yaml art@ietf.org [IETF] 2023-06-02 (YAML) and semantics for fragment identifiers because the ones defined for application/yaml do not apply unless explicitly expressed. 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 [RFC 6838, Section 4.3]. If the parameter "cose-type" is allowed, its usage MUST be identical to the usage defined for CBOR Object [draft-ietf-anima-constrained-voucher-23]; the "application/cose" media type in [RFC 9052, Section 2]. IETF ANIMA Working Group Signing and +cose [the "application/cose" media type]; [RFC binary (CBOR) N/A See [RFC 9052] IETF COSE Working Group or (iesg@ietf.org). The IETF has 2024-02-12 Encryption 9052] A COSE processor handling a media type "foo+cose" and which IETF (iesg@ietf.org) change control over this (COSE) object does not know the specific type "foo" SHOULD use the cose-type registration. 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. The syntax and semantics of fragment identifiers specified for +cwt SHOULD be as specified RATS WG mailing list Remote ATtestation ProcedureS CBOR Web Token +cwt [RFC 8392] binary N/A for application/cwt. (At See [RFC 8392, Section 8]. (rats@ietf.org), or IETF (RATS) Working Group. The IETF 2024-11-26 (CWT) publication of this document, Security Area has change control over this there is no fragment (saag@ietf.org) registration. identification syntax defined for application/cwt.) binary; SD-JWT values are a series of base64url-encoded See the Security values (some of Considerations sections of SD-JWT +sd-jwt [RFC 9901] which may be the N/A N/A [RFC 9901], [RFC 7519], and [Daniel_Fett] [IETF] 2025-05-30 empty string) [RFC 8725]. separated by period ('.') or tilde ('~') characters. 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: Comma-Separated Same as For cases defined in +csv, where Values (CSV) +csv [RFC 4180]; [RFC 7111] "text/csv". Same as "text/csv". the fragment identifier resolves Same as "text/csv". [IETF] [IETF] 2025-07-24 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". The encoding ASN.1 Unaligned considerations of The security considerations Packed Encoding +uper [ITU-T X.691 Unaligned Packed Encoding ITU-T X.691 The interoperability considerations of ITU-T X.691 Unaligned N/A of ITU-T X.691 Unaligned [AS207960_Cyfyngedig] [ITU-T] 2025-09-22 Rules Rules] Unaligned Packed Packed Encoding Rules apply. Packed Encoding Rules apply. Encoding Rules apply. The encoding ASN.1 JSON considerations of The interoperability considerations of ITU-T X.697 JSON The security considerations Encoding Rules +jer [ITU-T X.697 JSON Encoding Rules] ITU-T X.697 JSON Encoding Rules apply. N/A of ITU-T X.697 JSON Encoding [AS207960_Cyfyngedig] [ITU-T] 2025-09-22 Encoding Rules Rules apply. apply. binary. Values are represented as a JSON Object or as a series of RATS WG mailing list Remote ATtestation ProcedureS JSON Web +jws [RFC 7515] base64url-encoded N/A N/A See [RFC 7515, Section 10] (rats@ietf.org) or IETF (RATS) Working Group. The IETF 2025-12-09 Signature (JWS) values, each Security Area has change control over this separated from the (saag@ietf.org) registration. next by a single period ('.') character. [draft-ietf-spice-sd-cwt-06, See Authors' Adresses SD-CWT +sd-cwt [draft-ietf-spice-sd-cwt-06, Section 5] binary N/A N/A Section 16] section of IETF 2025-12-17 [draft-ietf-spice-sd-cwt-06] Contact Information ID Name Contact URI Last Updated [AS207960_Cyfyngedig] AS207960 Cyfyngedig mailto:hello&glauca.digital 2025-09-22 [CBOR_WG_mailing_list] CBOR WG mailing list mailto:cbor&ietf.org 2019-10-10 [Clemens_Ladisch] Clemens Ladisch mailto:clemens&ladisch.de 2018-02-12 [Daniel_Fett] Daniel Fett mailto:mail&danielfett.de 2025-05-30 [IETF] IETF mailto:iesg&ietf.org [ITU-T] ITU-T https://www.itu.int [John_Mudge] John Mudge mailto:helpdesk&omaorg.org 2016-06-19 [Michael_B._Jones] Michael B. Jones mailto:mbjµsoft.com 2018-05-15 [Open_Mobile_Naming_Authority] Open Mobile Naming Authority (OMNA) mailto:helpdesk&omaorg.org 2016-06-19 [SQLite_mailing_list] SQLite mailing list mailto:sqlite-users&mailinglists.sqlite.org 2018-02-12 Licensing Terms