Structured Syntax Suffixes

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 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.
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".)
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".
At publication of RFC 6839, 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.
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 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".
At publication of RFC 6839, 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.
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".)
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".
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".)