Internet Assigned Numbers Authority • Domains • Protocols • Numbers • About Structured Syntax Suffixes Created 2012-07-20 Last Updated 2026-01-15 Available Formats [IMG] XML [IMG] HTML [IMG] Plain text Registry Included Below • Structured Syntax Suffixes Structured Syntax Suffixes Registration Procedure(s) Expert Review Expert(s) Alexey Melnikov, Darrel Miller Reference [RFC6838] 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 [RFC7303], 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 [RFC7303] 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 [RFC7303] Same as [RFC7303, Same as [RFC7303, Section 9.1]. See above, and also Section 3, instance of a specific See [RFC7303, 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, [RFC7303]. Working Group. The W3C has three cases: change control over [RFC7303]. 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 [RFC6839], 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 [RFC8259, processed as follows: Apps Area Working Group The Apps Area Working Group. Object Notation +json [RFC8259][RFC6839] Section 8.1] for n/a See [RFC8259]. (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 [RFC6839], 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][RFC6839] 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 [RFC8949], 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 [RFC8949] format. n/a * For cases defined in +cbor, See [RFC8949, 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 [RFC6839], 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][RFC6839] 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 [RFC6839], 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][RFC6839] 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 [RFC6839], 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 be processed as follows: WBXML. Each individual media The Apps Area Working Group. (WBXML) +wbxml [Open Mobile Alliance, "Binary XML Content 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 2001.][RFC6839] encoding. For cases defined in +wbxml, +wbxml suffix can have (apps-discuss@ietf.org) this registration. 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 [RFC6839], 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, specific "xxx/yyy+zip" SHOULD be 192-bit and 256-bit ZIP file [PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format Specification", PKWARE .ZIP File Format ZIP is a binary processed as follows: encryption; see the Apps Area Working Group The Apps Area Working Group. storage and +zip Specification - Version 6.3.2, September 2007.][RFC6839] encoding. n/a specification for further (apps-discuss@ietf.org) IESG has change control over 2012-11-27 transfer format 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. fragment identifiers for a Type Length +tlv [“Lightweight Machine to Machine Technical Specification”, OMA-TS-LightweightM2M-V1_0, 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 especially section 6.3.3] format. processed as follows: For cases levels of nesting, which may (OMNA) 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 [RFC8091], 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 [RFC7464][RFC8091] See [RFC7464, n/a See [RFC7464, 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/pragma.html#pragma_application_id), and be processed as follows: example, if a specific database +sqlite3 [http://www.sqlite.org/fileformat2.html][http://www.sqlite.org/lang.html][Clemens_Ladisch] binary should specifiy it as a second magic number (file offset 68, registration requires that [SQLite_mailing_list] [Clemens_Ladisch] 2018-02-12 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 [RFC8417], 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 [RFC7519, Section 3][RFC8417, Section 7.2] characters N/A See [RFC7519, Section 11]. [Michael_B._Jones] The IESG has change control 2018-05-15 (JWT) 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 [RFC8460], 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 [RFC6713]. processed as follows: Each individual media type gzip file gzip is a binary registered with a +gzip storage and +gzip [RFC1952][RFC6713] 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 [RFC8742], 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 [RFC8742] binary n/a See [RFC8742, 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 [RFC8878] binary N/A fragment identifiers specified See [RFC8878, 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][RFC9512] 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 [RFC6838, Section 4.3]. If the parameter "cose-type" is allowed, its usage MUST be identical to the usage defined for CBOR Object the "application/cose" media type in [RFC9052, Section 2]. IETF ANIMA Working Group Signing and +cose [draft-ietf-anima-constrained-voucher-23][the "application/cose" media type][RFC9052] binary (CBOR) N/A See [RFC9052] IETF COSE Working Group or (iesg@ietf.org). The IETF has 2024-02-12 Encryption 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 [RFC8392] binary N/A for application/cwt. (At See [RFC8392, 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 [RFC9901] which may be the N/A N/A [RFC9901], [RFC7519], and [Daniel_Fett] [IETF] 2025-05-30 empty string) [RFC8725]. 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 [RFC4180][RFC7111] "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 Rules] 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 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 [RFC7515] base64url-encoded N/A N/A See [RFC7515, 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