RFC 6839 INFORMATIONAL MEDIA TYPES · IANA · FORMATS
Media Type Suffixes: Additional Media Type Structured Syntax Suffixes
Registers six more name suffixes, such as +json and +zip, that tell software what format a media type is built on.
RFC EDITOR
Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, <https://www.rfc-editor.org/info/rfc6839>.
BIBTEX
@misc{rfc6839,
series = {Request for Comments},
number = 6839,
howpublished = {RFC 6839},
publisher = {RFC Editor},
doi = {10.17487/RFC6839},
url = {https://www.rfc-editor.org/info/rfc6839},
author = {T. Hansen and A. Melnikov},
title = {{Additional Media Type Structured Syntax Suffixes}},
pagetotal = 14,
year = 2013,
month = jan,
} LINEAGE · FROM THE RFC INDEXOpen full graph →
RFC text
Contents
Internet Engineering Task Force (IETF) T. Hansen
Request for Comments: 6839 AT&T Laboratories
Updates: 3023 A. Melnikov
Category: Informational Isode Ltd
ISSN: 2070-1721 January 2013
Additional Media Type Structured Syntax Suffixes
Abstract
A content media type name sometimes includes partitioned meta-
information distinguished by a structured syntax to permit noting an
attribute of the media as a suffix to the name. This document
defines several structured syntax suffixes for use with media type
registrations. In particular, it defines and registers the "+json",
"+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax
suffixes, and provides a media type structured syntax suffix
registration form for the "+xml" structured syntax suffix.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6839.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. When to Use These Structured Syntax Suffixes . . . . . . . . . 3
3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 4
3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 4
3.2. The +ber Structured Syntax Suffix . . . . . . . . . . . . 5
3.3. The +der Structured Syntax Suffix . . . . . . . . . . . . 6
3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 7
3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 9
3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
4.1. The +xml Structured Syntax Suffix . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. Introduction
[RFC3023] created the +xml suffix convention that can be used when
defining names for media types whose representation uses XML
underneath. That is, they could have been successfully parsed as if
the media type had been application/xml in addition to their being
parsed as their media type that is using the +xml suffix. [RFC6838]
defines the media type "Structured Syntax Suffix Registry" to be used
for such structured syntax suffixes.
A variety of structured syntax suffixes have already been used in
some media type registrations, in particular "+json", "+der",
"+fastinfoset", and "+wbxml". This document defines and registers
these structured syntax suffixes in the Structured Syntax Suffix
Registry, along with "+ber" and "+zip". In addition, this document
updates [RFC3023] to formally register the "+xml" structured syntax
suffix according to the procedure defined in [RFC6838].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. When to Use These Structured Syntax Suffixes
Each of the structured syntax suffixes defined in this document is
appropriate for use when the media type identifies the semantics of
the protocol payload. That is, knowing the semantics of the specific
media type provides for more specific processing of the content than
that afforded by generic processing of the underlying representation.
At the same time, using the suffix allows receivers of the media
types to do generic processing of the underlying representation in
cases where
they do not need to perform special handling of the particular
semantics of the exact media type, and
there is no special knowledge needed by such a generic processor
in order to parse that underlying representation other than what
would be needed to parse any example of that underlying
representation.
3. Initial Structured Syntax Suffix Definitions
3.1. The +json Structured Syntax Suffix
[RFC4627] defines the "application/json" media type. The suffix
"+json" MAY be used with any media type whose representation follows
that established for "application/json". The media type structured
syntax suffix registration form follows. See [RFC6838] for
definitions of each of the registration form headings.
Name: JavaScript Object Notation (JSON)
+suffix: +json
References: [RFC4627]
Encoding considerations:
Per [RFC4627], JSON is allowed to be represented using UTF-8,
UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit
compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32,
JSON is binary ([RFC2045]).
Fragment identifier considerations:
The syntax and semantics of fragment identifiers specified for
+json SHOULD be as specified for "application/json". (At
publication of this document, 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 process as specified in +json.
For cases defined in +json, where the fragment identifier does
not resolve per the +json rules, then process as specified in
"xxx/yyy+json".
For cases not defined in +json, then process as specified in
"xxx/yyy+json".
Interoperability considerations: n/a
Security considerations: See [RFC4627]
Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
3.2. The +ber Structured Syntax Suffix
The ITU defined the Basic Encoding Rules (BER) transfer syntax in
[ITU.X690.2008]. The suffix "+ber" MAY be used with any media type
whose representation follows the BER transfer syntax. (The Expert
Reviewer for media type structured syntax suffix registrations ought
to be aware of the relationship between BER and DER to aid in
selecting the proper suffix.) The media type structured syntax
suffix registration form for +ber follows:
Name: Basic Encoding Rules (BER) transfer syntax
+suffix: +ber
References: [ITU.X690.2008]
Encoding considerations: BER is a binary encoding.
Fragment identifier considerations:
At publication of this document, 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 process as specified in +ber.
For cases defined in +ber, where the fragment identifier does
not resolve per the +ber rules, then process as specified in
"xxx/yyy+ber".
For cases not defined in +ber, then process as specified in
"xxx/yyy+ber".
Interoperability considerations: n/a
Security considerations:
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.
Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
3.3. The +der Structured Syntax Suffix
The ITU defined the Distinguished Encoding Rules (DER) transfer
syntax in [ITU.X690.2008]. The suffix "+der" MAY be used with any
media type whose representation follows the DER transfer syntax.
(The Expert Reviewer for media type structured syntax suffix
registrations ought to be aware of the relationship between BER and
DER to aid in selecting the proper suffix.) The media type
structured syntax suffix registration form for +der follows:
Name: Distinguished Encoding Rules (DER) transfer syntax
+suffix: +der
References: [ITU.X690.2008]
Encoding considerations: DER is a binary encoding.
Fragment identifier considerations:
At publication of this document, 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 process as specified in +der.
For cases defined in +der, where the fragment identifier does
not resolve per the +der rules, then process as specified in
"xxx/yyy+der".
For cases not defined in +der, then process as specified in
"xxx/yyy+der".
Interoperability considerations: n/a
Security considerations:
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.
Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
3.4. The +fastinfoset Structured Syntax Suffix
The ITU defined the Fast Infoset document format as a binary
representation of the XML Information Set in [ITU.X891.2005]. These
documents further define the "application/fastinfoset" media type.
The suffix "+fastinfoset" MAY be used with any media type whose
representation follows that established for "application/
fastinfoset". The media type structured syntax suffix registration
form follows:
Name: Fast Infoset document format
+suffix: +fastinfoset
References: [ITU.X891.2005]
Encoding considerations:
Fast Infoset is a binary encoding. The binary, quoted-printable,
and base64 content-transfer-encodings are suitable for use with
Fast Infoset.
Fragment identifier considerations:
The syntax and semantics of fragment identifiers specified for
+fastinfoset SHOULD be as specified for "application/fastinfoset".
(At publication of this document, 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 process as
specified in +fastinfoset.
For cases defined in +fastinfoset, where the fragment
identifier does not resolve per the +fastinfoset rules, then
process as specified in "xxx/yyy+fastinfoset".
For cases not defined in +fastinfoset, then process as
specified in "xxx/ yyy+fastinfoset".
Interoperability considerations: n/a
Security considerations:
There are no security considerations inherent in Fast Infoset.
Each individual media type registered with a +fastinfoset suffix
can have additional security considerations.
Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
3.5. The +wbxml Structured Syntax Suffix
The Wireless Application Protocol (WAP) Forum has defined the WAP
Binary XML (WBXML) document format as a binary representation of XML
in [WBXML]. This document further defines the "application/
vnd.wap.wbxml" media type. The suffix "+wbxml" MAY be used with any
media type whose representation follows that established for
"application/vnd.wap.wbxml". The media type structured syntax suffix
registration form follows:
Name: WAP Binary XML (WBXML) document format
+suffix: +wbxml
References: [WBXML]
Encoding considerations: WBXML is a binary encoding.
Fragment identifier considerations:
The syntax and semantics of fragment identifiers specified for
+wbxml SHOULD be as specified for "application/vnd.wap.wbxml".
(At publication of this document, 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 process as specified in
+wbxml.
For cases defined in +wbxml, where the fragment identifier does
not resolve per the +wbxml rules, then process as specified in
"xxx/yyy+wbxml".
For cases not defined in +wbxml, then process as specified in
"xxx/yyy+wbxml".
Interoperability considerations: n/a
Security considerations:
There are no security considerations inherent in WBXML. Each
individual media type registered with a +wbxml suffix can have
additional security considerations.
Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
3.6. The +zip Structured Syntax Suffix
The ZIP format is a public domain, cross-platform, interoperable file
storage and transfer format, originally defined by PKWARE, Inc.; it
supports compression and encryption and is used as the underlying
representation by a variety of file formats. The media type
"application/zip" has been registered for such files. The suffix
"+zip" MAY be used with any media type whose representation follows
that established for "application/zip". The media type structured
syntax suffix registration form follows:
Name: ZIP file storage and transfer format
+suffix: +zip
References: [ZIP]
Encoding considerations: ZIP is a binary encoding.
Fragment identifier considerations:
The syntax and semantics of fragment identifiers specified for
+zip SHOULD be as specified for "application/zip". (At
publication of this document, 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 process as specified in +zip.
For cases defined in +zip, where the fragment identifier does
not resolve per the +zip rules, then process as specified in
"xxx/yyy+zip".
For cases not defined in +zip, then process as specified in
"xxx/yyy+zip".
Interoperability considerations: n/a
Security considerations:
IP 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.
Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller: The Apps Area Working Group. IESG has
change control over this registration.
4. IANA Considerations
See the media type structured syntax suffix registration forms in
Sections 3.1 - 3.6.
4.1. The +xml Structured Syntax Suffix
The following structured syntax suffix registration for "+xml" shall
be used to reflect the information found in [RFC3023], with the
addition of fragment identifier considerations. (Note that [RFC3023]
is in the process of being updated by [XML-MEDIATYPES].)
Name: Extensible Markup Language (XML)
+suffix: +xml
References: [RFC3023]
Encoding considerations:
Per [RFC3023], XML is allowed to be represented using both 7-bit
and 8-bit encodings. When XML is written in UTF-8, XML is 8bit
compatible ([RFC2045]). When XML is written in UTF-16 or UTF-32,
XML is binary ([RFC2045]).
Fragment identifier considerations:
The syntax and semantics of fragment identifiers specified for
+xml SHOULD be as specified for "application/xml". (At
publication of this document, the fragment identification syntax
considerations for "application/xml" are defined in [RFC3023],
Sections 5 and 7.)
The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+xml" SHOULD be processed as follows:
For cases defined in +xml, where the fragment identifier
resolves per the +xml rules, then process as specified in +xml.
For cases defined in +xml, where the fragment identifier does
not resolve per the +xml rules, then process as specified in
"xxx/yyy+xml".
For cases not defined in +xml, then process as specified in
"xxx/yyy+xml".
Interoperability considerations: See [RFC3023].
Security considerations: See [RFC3023]
Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
5. Security Considerations
See the Security Considerations sections found in the media type
structured syntax suffix registration forms from Sections 3 and 4.
When updating a +<suffix> registration, care should be taken to
review all previously-registered xxx/yyy+<suffix> media types as to
whether they might be affected by the updated +<suffix> registration.
Because the generic fragment identifier processing rules take
precedence over media-type-specific rules, introducing new or
changing existing definitions may break the existing registrations of
specific media types, as well as particular implementations of
applications that process affected media types. Such changes can
introduce interoperability and security issues.
When updating the fragment identifier processing rules for a specific
xxx/yyy+<suffix> media type, care should be taken to review the
generic fragment identifier processing rules for the +<suffix>
registration and not introduce any conflicts. Because the generic
fragment identifier processing rules take precedence over media-type-
specific rules, such conflicting processing requirements should be
ignored by an implementation, but such conflicts can introduce
interoperability and security issues.
Note that [FRAGID-BP] provides additional advice to designers of
fragment identifier rules for media type suffixes and specific media
types.
6. References
6.1. Normative References
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[ITU.X690.2008]
International Telecommunications Union, "Recommendation
ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules:
Specification of basic encoding Rules (BER), Canonical
encoding rules (CER) and Distinguished encoding rules
(DER)", ITU-T Recommendation X.690, November 2008.
[ITU.X891.2005]
International Telecommunications Union, "Recommendation
ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications
of ASN.1: Fast infoset", ITU-T Recommendation X.891,
May 2005.
[WBXML] Open Mobile Alliance, "Binary XML Content Format
Specification", OMA Wireless Access Protocol WAP-192-
WBXML-20010725-a, July 2001.
[ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format
Specification", PKWARE .ZIP File Format Specification -
Version 6.3.2, September 2007.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
6.2. Informative References
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013.
[FRAGID-BP]
Tennison, J., "Best Practices for Fragment Identifiers and
Media Type Definitions", July 2012,
<http://www.w3.org/TR/fragid-best-practices/>.
[XML-MEDIATYPES]
Lilley, C., Makoto, M., Melnikov, A., and H. Thompson,
"XML Media Types", Work in Progress, November 2012.
Authors' Addresses
Tony Hansen
AT&T Laboratories
200 Laurel Ave. South
Middletown, NJ 07748
USA
EMail: tony+sss@maillennium.att.com
Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
AI ELI5
On this page
PROBLEMA specialized media type name does not say what underlying format its content uses, so generic software cannot tell it could parse the data as, say, plain JSON.
MECHANISMThe RFC defines and registers the +json, +ber, +der, +fastinfoset, +wbxml and +zip structured syntax suffixes, and gives the registration form for +xml, each with rules for encoding, fragment identifiers and security.
WHY IT MATTERSA media type ending in a registered suffix can be handled generically by receivers that do not need its special semantics. The RFC updates RFC 3023 and was itself updated by RFC 7303.
§1Why Suffixes Exist
A media type name can carry partitioned meta-information as a suffix. RFC 3023 created the +xml suffix for media types whose content is XML underneath, meaning it could be parsed as application/xml as well as under its own type. RFC 6838 defines a Structured Syntax Suffix Registry for such suffixes.
Several suffixes were already in use in registrations: +json, +der, +fastinfoset and +wbxml. This document defines and registers those, adds +ber and +zip, and updates RFC 3023 so that +xml is formally registered under the RFC 6838 procedure.
Many file types are really a special kind of a simpler type. A suffix is a tag at the end of the name that says which simple type it is built from.
§2When to Use These Suffixes
Each suffix fits when the media type identifies the semantics of the payload, so that knowing the specific type allows more specific processing than generic handling of the underlying representation.
At the same time, the suffix lets a receiver do generic processing of the underlying format when two conditions hold: the receiver does not need to handle the particular semantics of the exact media type, and no special knowledge is needed to parse the underlying representation beyond what would be needed for any example of it.
If a tool only needs to open the box and does not care what the toy inside is, the suffix tells it what kind of box to open.
§3The Six New Suffix Definitions
Each suffix has a registration form. +json may be used with any type whose representation follows application/json (RFC 4627); JSON may be UTF-8, UTF-16 or UTF-32. +ber and +der cover the ITU Basic Encoding Rules and Distinguished Encoding Rules, both binary, and the text notes that the Expert Reviewer should understand the relationship between the two when choosing the proper suffix.
+fastinfoset covers the Fast Infoset binary representation of the XML Information Set, following application/fastinfoset. +wbxml covers WAP Binary XML, following application/vnd.wap.wbxml. +zip covers the ZIP file storage and transfer format, following application/zip, which is used as the underlying representation by a variety of file formats.
For all of them, the interoperability considerations are listed as not applicable, the contact is the Apps Area Working Group, and the IESG has change control.
Six new endings were added to the list: one for JSON text, one each for two kinds of ASN.1 binary, one for compact binary XML, one for wireless-style binary XML, and one for zip files.
- +jsonJSON — Follows application/json (RFC 4627).
- +berBasic Encoding Rules — ITU X.690 transfer syntax; binary.
- +derDistinguished Encoding Rules — ITU X.690 transfer syntax; binary.
- +fastinfosetFast Infoset — Binary form of the XML Information Set; follows application/fastinfoset.
- +wbxmlWAP Binary XML — Follows application/vnd.wap.wbxml; binary.
- +zipZIP — Follows application/zip; binary.
§3.1Fragment Identifier Rules
Every registration gives the same layered rule for fragment identifiers on a specific type xxx/yyy+suffix. If the fragment is defined by the suffix and resolves under the suffix rules, process it as the suffix specifies. If it is defined by the suffix but does not resolve under those rules, process it as specified for xxx/yyy+suffix. If the suffix does not define it, process it as specified for xxx/yyy+suffix.
The suffix's own rules should follow those of the base type. At the time of publication no fragment syntax was defined for application/json, +ber, +der, application/fastinfoset, application/vnd.wap.wbxml or application/zip.
When a link points to a spot inside a file, the suffix's rules are tried first, and if they do not cover that spot, the specific type's own rules decide.
§4IANA Registrations and +xml
The IANA section points to the registration forms in Sections 3.1 to 3.6. It also supplies the registration for +xml, to reflect what RFC 3023 says, with the addition of fragment identifier considerations. XML is allowed in both 7-bit and 8-bit encodings; in UTF-8 it is 8bit compatible and in UTF-16 or UTF-32 it is binary.
The fragment rules for +xml follow application/xml, which at publication were defined in RFC 3023, Sections 5 and 7. The text notes that RFC 3023 was in the process of being updated by a separate XML media types document.
The registry office gets a form for each new ending, and the old +xml ending gets its official form too.
§5Security Considerations
Each registration has its own security section, and each media type under a suffix can add more. For +ber and +der, the type-length-value structure makes it easy to build malicious content with invalid length fields that can cause buffer overruns, and arbitrary nesting may allow content that causes a stack overflow. Interpreters should guard against both. The text says there are no security considerations inherent in Fast Infoset or WBXML. For ZIP it notes the two forms of encryption it supports, Strong Encryption and AES at 128-bit, 192-bit and 256-bit.
The general warning is about changes. Because the generic fragment identifier rules take precedence over media-type-specific rules, updating a suffix registration or adding conflicting rules can break existing registrations and implementations, and can introduce interoperability and security issues. Care should be taken to review all previously registered types before updating a suffix.
Some file kinds can be tricked with lying size numbers or boxes inside boxes, so programs reading them must be careful. Changing the rules later could also break files that already follow the old rules.
§7References
[RFC3023]RFC 3023Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.January 2001[RFC4627]RFC 4627Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.July 2006[RFC6838]RFC 6838Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.January 2013
[ITU.X690.2008]International Telecommunications Union, "Recommendation ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules", ITU-T Recommendation X.690, November 2008.
[ZIP]PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format Specification", Version 6.3.2, September 2007.