Internet Assigned Numbers Authority Structured Syntax Suffixes Created 2012-07-20 Last Updated 2024-02-16 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 +xml [RFC7303] Same as [RFC7303], Same as [RFC7303], Section 9.1. See above, and also Section 3, instance of a specific See Section 10, See Authors' Addresses Web Consortium's XML Core 2012-11-15 2014-04-17 Language (XML) Section 9.1. for guidelines on the use of the 'charset' parameter. "xxx/yyy+xml" type, there are [RFC7303]. 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 JavaScript is binary data. specific "xxx/yyy+json" SHOULD be Object See [RFC8259] processed as follows: Apps Area Working Group The Apps Area Working Group. 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 suffix can have additional security At publication of [RFC6839], considerations. there is no fragment identification syntax defined for BER has a +ber. type-length-value structure, and it is easy The syntax and semantics for to construct malicious fragment identifiers for a content with invalid specific "xxx/yyy+ber" SHOULD be length fields that can processed as follows: cause buffer overrun Basic Encoding conditions. Rules (BER) BER is a binary For cases defined in +ber, where Apps Area Working Group The Apps Area Working Group. message +ber [ITU.X690.2008][RFC6839] encoding. n/a the fragment identifier resolves BER allows for arbitrary (apps-discuss@ietf.org) IESG has change control over 2012-11-27 transfer per the +ber rules, then as levels of nesting, which this registration. syntax specified in +ber. may make it possible to construct malicious For cases defined in +ber, where content that will cause a the fragment identifier does not stack overflow. resolve per the +ber rules, then as specified in "xxx/ yyy+ber". Interpreters of the BER structures should be For cases not defined in +ber, aware of these issues and then as specified in should take appropriate "xxx/yyy+ber". measures to guard against buffer 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 See Section 10 of (cbor@ietf.org) or IETF Representation +cbor [RFC8949] format. n/a * For cases defined in +cbor, [RFC8949] Applications and IETF (cbor@ietf.org) 2013-09-19 2020-10-16 (CBOR) where the fragment identifier Real-Time Area resolves per the +cbor rules, (art@ietf.org) 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 suffix can have additional security At publication of [RFC6839], considerations. there is no fragment identification syntax defined for DER has a +der. type-length-value structure, and it is easy The syntax and semantics for to construct malicious fragment identifiers for a content with invalid specific "xxx/yyy+der" SHOULD be length fields that can processed as follows: cause buffer overrun Distinguished conditions. Encoding Rules DER is a binary For cases defined in +der, where Apps Area Working Group The Apps Area Working Group. (DER) message +der [ITU.X690.2008][RFC6839] encoding. n/a the fragment identifier resolves DER allows for arbitrary (apps-discuss@ietf.org) IESG has change control over 2012-11-27 transfer per the +der rules, then as levels of nesting, which this registration. syntax specified in +der. may make it possible to construct malicious For cases defined in +der, where content that will cause a the fragment identifier does not stack overflow. resolve per the +der rules, then as specified in "xxx/ yyy+der". Interpreters of the DER structures should be For cases not defined in +der, aware of these issues and then as specified in should take appropriate "xxx/yyy+der". measures to guard against buffer 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 quoted-printable SHOULD be processed as follows: in Fast Infoset. Each Fast Infoset and base64 individual media type Apps Area Working Group The Apps Area Working Group. document +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 format transfer-encodings +fastinfoset, where the fragment +fastinfoset suffix can this registration. are suitable for identifier resolves per the have 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 WAP Binary XML be processed as follows: in WBXML. Each individual The Apps Area Working Group. (WBXML) +wbxml [Open Mobile Alliance, "Binary XML Content Format Specification", OMA Wireless Access WBXML is a binary n/a media type registered Apps Area Working Group IESG has change control over 2012-11-27 document Protocol WAP-192- WBXML-20010725-a, July 2001.][RFC6839] encoding. For cases defined in +wbxml, with a +wbxml suffix can (apps-discuss@ietf.org) this registration. format where the fragment identifier have 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 of encryption: The syntax and semantics for Strong Encryption and AES fragment identifiers for a 128-bit, 192-bit and ZIP file specific "xxx/yyy+zip" SHOULD be 256-bit encryption; see storage and [PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format Specification", PKWARE .ZIP File Format ZIP is a binary processed as follows: the specification for Apps Area Working Group The Apps Area Working Group. transfer +zip Specification - Version 6.3.2, September 2007.][RFC6839] encoding. n/a further details. Each (apps-discuss@ietf.org) IESG has change control over 2012-11-27 format For cases defined in +zip, where individual media type this registration. the fragment identifier resolves registered with a +zip per the +zip rules, then as 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 suffix can have The syntax and semantics of additional security fragment identifiers specified considerations. for +tlv should be as specified for As with any format with "application/vnd.oma.lwm2m+tlv". internal length fields, (At publication of this document, it is easy to construct there is no fragment malicious content with identification syntax defined for invalid length fields "application/vnd.oma.lwm2m+tlv".) that can cause buffer The syntax and semantics for overrun 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 (OMNA) defined in +tlv, where the may make it possible to fragment identifier resolves per construct malicious the +tlv rules, then process as content that will cause a specified in +tlv. For cases stack overflow. defined in +tlv, where the fragment identifier does not Interpreters of the TLV resolve per the +tlv rules, then structures should be process as specified in aware of these issues and "xxx/yyy+tlv". For cases not should take appropriate defined in +tlv, then process as measures to guard against specified in "xxx/yyy+tlv". buffer 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" Applications and SHOULD be processed as follows: Real-Time Area The Applications and Real-Time JSON Text +json-seq [RFC7464][RFC8091] See [RFC7464] n/a See [RFC7464] Section 3 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 registration. resolves per the +json-seq rules, successor. 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 All the security for +sqlite3 should be as considerations for specified for "application/vnd.sqlite3" "application/vnd.sqlite3". (At apply to any type based publication of this document, on the sqlite3 format. there is no fragment Same as for "application/vnd.sqlite3". identification syntax defined for Each individual media "application/vnd.sqlite3".) type registered with a To allow identification of files when the media type name is +sqlite3 suffix can have not available, each individual "xxx/yyy+sqlite3" registration The syntax and semantics of additional security should specify an appliction ID value to be set with PRAGMA fragment identifiers for a considerations. For application_id specific "xxx/yyy+sqlite3" should example, if a specific SQLite3 (http://www.sqlite.org/pragma.html#pragma_application_id), and be processed as follows: registration requires 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, that certain extension [SQLite_mailing_list] [Clemens_Ladisch] 2018-02-12 see http://www.sqlite.org/fileformat2.html#application_id) in For cases defined in +sqlite3, functions are available, addition to the header string at offset 0. This value should where the fragment identifier or that blob fields also be added to the magic.txt file in the SQLite repository resolves per the +sqlite3 rules, contain data to be http://www.sqlite.org/src/artifact?ci=trunk&filename=magic.txt) then as specified in +sqlite3. processed by other by submitting a patch to libraries or external . For cases defined in +sqlite3, tools, or if only a where the fragment identifier single implementation does not resolve per the +sqlite3 exists to handle a rules, then as specified in specific registered media "xxx/yyy+sqlite3". type, then this increases the known attack surface For cases not defined in available to an attacker. +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 Section 11 of [Michael_B._Jones] The IESG has change control 2018-05-15 (JWT) removed), some of For cases defined in +jwt where [RFC7519]. 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 gzip format doesn't fragment identifiers specified provide confidentiality for +gzip SHOULD be as specified protection. Integrity for "application/gzip". (At protection is provided by publication of [RFC8460], there an Adler-32 checksum, is no fragment identification which is not syntax defined for cryptographically strong. "application/gzip".) The syntax See also the security and semantics for fragment considerations of identifiers for a specific [RFC6713]. Each "xxx/yyy+gzip" SHOULD be individual media type gzip file processed as follows: registered with a +gzip storage and gzip is a binary suffix can have transfer +gzip [RFC1952][RFC6713] encoding. n/a For cases defined in +gzip, where additional security art@ietf.org [IETF] 2018-06-14 format the fragment identifier resolves considerations. per the +gzip rules, process as Additionally, gzip specified in +gzip. objects can contain multiple files and For cases defined in +gzip, where associated paths. File the fragment identifier does not paths must be validated resolve per the +gzip rules, when the files are process as specified in extracted; a malicious "xxx/yyy+gzip". file path could otherwise cause the extractor to For cases not defined in +gzip, overwrite application or process as specified in system files. "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 Zstandard +zstd [RFC8878] binary N/A fragment identifiers specified See Section 8 of the 'application/zstd' [IETF] 2020-05-19 for +zstd should be as specified [RFC8878]. media type. for "application/zstd". Unlike application/yaml, there is no fragment identification syntax defined for +yaml. YAML Ain't Markup Same as A specific xxx/yyy+yaml media httpapi@ietf.org or 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 Section 4.3 of [RFC6838]. 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 Section 2 of [RFC9052]. 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 (iesg@ietf.org). The IETF has 2024-02-12 Encryption A COSE processor handling a media type "foo+cose" and which or 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. Contact Information ID Name Contact URI Last Updated [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 [IETF] IETF mailto:iesg&ietf.org [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