One document matched: draft-ietf-appsawg-media-type-suffix-regs-04.xml
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='no'?>
<?rfc linkmailto='no'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<?rfc comments='yes'?>
<?rfc inline='yes'?>
<?rfc-ext parse-xml-in-artwork='yes' ?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc ipr='trust200902' docName='draft-ietf-appsawg-media-type-suffix-regs-04'
category='bcp' updates='3023'>
<front>
<title abbrev='Additional Media Type Suffixes'>Additional Media Type Structured Syntax Suffixes</title>
<author initials='T.' surname='Hansen' fullname='Tony Hansen'>
<organization>AT&T Laboratories</organization>
<address>
<postal>
<street>200 Laurel Ave. South</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<email>tony+sss@maillennium.att.com</email>
</address>
</author>
<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
<organization>Isode Ltd</organization>
<address>
<postal>
<street>5 Castle Business Village</street>
<street>36 Station Road</street>
<city>Hampton</city>
<region>Middlesex</region>
<code>TW12 2BX</code>
<country>UK</country>
</postal>
<email>Alexey.Melnikov@isode.com</email>
</address>
</author>
<date />
<area>Applications</area>
<abstract>
<t>
A content media type name sometimes includes partitioned
meta-information distinguish 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 updates the "+xml" Message Type Structured Syntax Suffix registration.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
<xref target='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.
<xref target='I-D.ietf-appsawg-media-type-regs'/> defines the Message Type Structured Syntax
Suffixes registry to be used for such Structured Syntax Suffixes.
</t>
<t>
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 the "+xml" Structured Syntax Suffix registration.
<!--
<a>dssc+der</a>
<a href="/assignments/media-types/application/soap+fastinfoset">soap+fastinfoset</a>
<a href="/assignments/media-types/application/vnd.collection+json">vnd.collection+json</a>
<a href="/assignments/media-types/application/vnd.hal+json">vnd.hal+json</a>
<a href="/assignments/media-types/application/vnd.oftn.l10n+json">vnd.oftn.l10n+json</a>
<a href="/assignments/media-types/application/vnd.nokia.conml+wbxml">vnd.nokia.conml+wbxml</a>
<a href="/assignments/media-types/application/vnd.nokia.landmark+wbxml">vnd.nokia.landmark+wbxml</a>
<a href="/assignments/media-types/application/vnd.nokia.pcd+wbxml">vnd.nokia.pcd+wbxml</a>
<a href="/assignments/media-types/application/vnd.syncml.dm+wbxml">vnd.syncml.dm+wbxml</a>
<a href="/assignments/media-types/application/vnd.wv.csp+wbxml">vnd.wv.csp+wbxml</a>
-->
</t>
<t>
Discussion of this document should occur in the Apps Area Working Group (apps-discuss@ietf.org).
[RFC Editor note: remove this paragraph.]
</t>
<t>
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 <xref target='RFC2119'/>.
</t>
</section>
<section title='When to Use these Structured Syntax Suffixes'>
<t>
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.
</t>
<t>
At the same time, using the suffix allows receivers of the media types to do generic
processing of the underlying representation in cases where
<list hangIndent='0'>
<t>they do not need to perform special handling of the particular semantics of the
exact media type, and,
</t>
<t>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.
</t>
</list>
</t>
</section>
<section title='Initial Structured Syntax Suffix Definitions'>
<section title='The +json Structured Syntax Suffix' anchor='json'>
<t>
<xref target='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 Message Type Structured Syntax Suffix registration form follows.
See <xref target='I-D.ietf-appsawg-media-type-regs'/> for definitions of each of the registration
form headings.
<list style='hanging' hangIndent='20'>
<t hangText='Name:'>
JavaScript Object Notation (JSON)
</t>
<t hangText='+suffix:'>
+json
</t>
<t hangText='References:'>
<xref target='RFC4627'/>
</t>
<t hangText='Encoding considerations:'>
Per <xref target='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 (<xref target='RFC2045'/>).
When JSON is written in UTF-16 or UTF-32, JSON is binary (<xref target='RFC2045'/>).
</t>
<t hangText='Fragment identifier considerations:'>
<list hangIndent='0'>
<t>
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".)
</t>
<t>
The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+json" SHOULD be processed as follows:
<list>
<t>For cases defined in +json, where the fragment identifier resolves per
the +json rules, then as specified in +json.
</t>
<t>
For cases defined in +json, where the fragment identifier does not resolve per
the +json rules, then as specified in "xxx/yyy+json".
</t>
<t>
For cases not defined in +json, then as specified in "xxx/yyy+json".
</t>
</list>
</t>
</list>
</t>
<t hangText='Interoperability considerations:'>
n/a
</t>
<t hangText='Security considerations:'>
See <xref target='RFC4627'/>
</t>
<t hangText='Contact:'>
Apps Area Working Group (apps-discuss@ietf.org)
</t>
<t hangText='Author/Change controller:'>
The Apps Area Working Group has change control over this registration.
</t>
</list>
</t>
</section>
<section title='The +ber Structured Syntax Suffixes' anchor='ber'>
<t>
The ITU defined the Basic Encoding Rules (BER)
message transfer syntax in <xref target='ITU.X690.2008'/>.
The suffix "+ber" MAY be used with any media type
whose representation follows the BER message transfer syntax.
The Message Type Structured Syntax Suffix registration form for +ber follows:
<list style='hanging' hangIndent='20'>
<t hangText='Name:'>
Basic Encoding Rules (BER) message transfer syntax
</t>
<t hangText='+suffix:'>
+ber
</t>
<t hangText='References:'>
<xref target='ITU.X690.2008'/>
</t>
<t hangText='Encoding considerations:'>
BER is a binary encoding.
</t>
<t hangText='Fragment identifier considerations:'>
<list hangIndent='0'>
<t>
At publication of this document, there is no fragment identification syntax
defined for +ber.
</t>
<t>
The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+ber" SHOULD be processed as follows:
<list>
<t>
For cases defined in +ber, where the fragment identifier resolves per
the +ber rules, then as specified in +ber.
</t>
<t>
For cases defined in +ber, where the fragment identifier does not resolve per
the +ber rules, then as specified in "xxx/yyy+ber".
</t>
<t>
For cases not defined in +ber, then as specified in "xxx/yyy+ber".
</t>
</list>
</t>
</list>
</t>
<t hangText='Interoperability considerations:'>
n/a
</t>
<t hangText='Security considerations:'>
Each individual media type registered with a +ber suffix can
have additional security considerations.
</t>
<t>
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.
</t>
<t>
Some BER schema allow for arbitrary levels of nesting, which may
make it possible to construct malicious content that will cause a stack
overflow.
</t>
<t>
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.
</t>
<t hangText='Contact:'>
Apps Area Working Group (apps-discuss@ietf.org)
</t>
<t hangText='Author/Change controller:'>
The Apps Area Working Group has change control over this registration.
</t>
</list>
</t>
</section>
<section title='The +der Structured Syntax Suffixes' anchor='der'>
<t>
The ITU defined the Distinguished Encoding Rules (DER)
message transfer syntax in <xref target='ITU.X690.2008'/>.
The suffix "+der" MAY be used with any media type
whose representation follows the DER message transfer syntax.
The Message Type Structured Syntax Suffix registration form for +der follows:
<list style='hanging' hangIndent='20'>
<t hangText='Name:'>
Distinguished Encoding Rules (DER) message transfer syntax
</t>
<t hangText='+suffix:'>
+der
</t>
<t hangText='References:'>
<xref target='ITU.X690.2008'/>
</t>
<t hangText='Encoding considerations:'>
DER is a binary encoding.
</t>
<t hangText='Fragment identifier considerations:'>
<list hangIndent='0'>
<t>
At publication of this document, there is no fragment identification syntax
defined for +der.
</t>
<t>
The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+der" SHOULD be processed as follows:
<list>
<t>
For cases defined in +der, where the fragment identifier resolves per
the +der rules, then as specified in +der.
</t>
<t>
For cases defined in +der, where the fragment identifier does not resolve per
the +der rules, then as specified in "xxx/yyy+der".
</t>
<t>
For cases not defined in +der, then as specified in "xxx/yyy+der".
</t>
</list>
</t>
</list>
</t>
<t hangText='Interoperability considerations:'>
n/a
</t>
<t hangText='Security considerations:'>
Each individual media type registered with a +der suffix can
have additional security considerations.
</t>
<t>
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.
</t>
<t>
Some DER schema allow for arbitrary levels of nesting, which may
make it possible to construct malicious content that will cause a stack
overflow.
</t>
<t>
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.
</t>
<t hangText='Contact:'>
Apps Area Working Group (apps-discuss@ietf.org)
</t>
<t hangText='Author/Change controller:'>
The Apps Area Working Group has change control over this registration.
</t>
</list>
</t>
</section>
<section title='The +fastinfoset Structured Syntax Suffix' anchor='fastinfoset'>
<t>
The ITU defined the Fast Infoset document format as a binary representation of the XML Information Set in
<xref target='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 Message Type Structured Syntax Suffix registration form follows:
<list style='hanging' hangIndent='20'>
<t hangText='Name:'>
Fast Infoset document format
</t>
<t hangText='+suffix:'>
+fastinfoset
</t>
<t hangText='References:'>
<xref target='ITU.X891.2005'/>
</t>
<t hangText='Encoding considerations:'>
Fast Infoset is a binary encoding. The binary, quoted-printable and base64 content-transfer-encodings
are suitable for use with Fast Infoset.
</t>
<t hangText='Fragment identifier considerations:'>
<list hangIndent='0'>
<t>
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".)
</t>
<t>
The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+fastinfoset" SHOULD be processed as follows:
<list>
<t>For cases defined in +fastinfoset, where the fragment identifier resolves per
the +fastinfoset rules, then as specified in +fastinfoset.
</t>
<t>
For cases defined in +fastinfoset, where the fragment identifier does not resolve per
the +fastinfoset rules, then as specified in "xxx/yyy+fastinfoset".
</t>
<t>
For cases not defined in +fastinfoset, then as specified in "xxx/yyy+fastinfoset".
</t>
</list>
</t>
</list>
</t>
<t hangText='Interoperability considerations:'>
n/a
</t>
<t hangText='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.
</t>
<t hangText='Contact:'>
Apps Area Working Group (apps-discuss@ietf.org)
</t>
<t hangText='Author/Change controller:'>
The Apps Area Working Group has change control over this registration.
</t>
</list>
</t>
</section>
<section title='The +wbxml Structured Syntax Suffix' anchor='wbxml'>
<t>
The WAP Forum has defined the WAP Binary XML (WBXML) document format
as a binary representation of XML in <xref target='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 Message Type Structured Syntax Suffix registration form follows:
<list style='hanging' hangIndent='20'>
<t hangText='Name:'>
WAP Binary XML (WBXML) document format
</t>
<t hangText='+suffix:'>
+wbxml
</t>
<t hangText='References:'>
<xref target='WBXML'/>
</t>
<t hangText='Encoding considerations:'>
WBXML is a binary encoding.
</t>
<t hangText='Fragment identifier considerations:'>
<list hangIndent='0'>
<t>
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".)
</t>
<t>
The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+wbxml" SHOULD be processed as follows:
<list>
<t>For cases defined in +wbxml, where the fragment identifier resolves per
the +wbxml rules, then as specified in +wbxml.
</t>
<t>
For cases defined in +wbxml, where the fragment identifier does not resolve per
the +wbxml rules, then as specified in "xxx/yyy+wbxml".
</t>
<t>
For cases not defined in +wbxml, then as specified in "xxx/yyy+wbxml".
</t>
</list>
</t>
</list>
</t>
<t hangText='Interoperability considerations:'>
n/a
</t>
<t hangText='Security considerations:'>
There are no security considerations inherent in WBXML.
Each individual media type registered with a +wbxml suffix can have additional security considerations.
</t>
<t hangText='Contact:'>
Apps Area Working Group (apps-discuss@ietf.org)
</t>
<t hangText='Author/Change controller:'>
The Apps Area Working Group has change control over this registration.
</t>
</list>
</t>
</section>
<section title='The +zip Structured Syntax Suffix' anchor='zip'>
<t>
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 Message Type Structured Syntax Suffix registration form follows:
<list style='hanging' hangIndent='20'>
<t hangText='Name:'>
ZIP file storage and transfer format
</t>
<t hangText='+suffix:'>
+zip
</t>
<t hangText='References:'>
<xref target='ZIP'/>
</t>
<t hangText='Encoding considerations:'>
ZIP is a binary encoding.
</t>
<t hangText='Fragment identifier considerations:'>
<list hangIndent='0'>
<t>
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".)
</t>
<t>
The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+zip" SHOULD be processed as follows:
<list>
<t>For cases defined in +zip, where the fragment identifier resolves per
the +zip rules, then as specified in +zip.
</t>
<t>
For cases defined in +zip, where the fragment identifier does not resolve per
the +zip rules, then as specified in "xxx/yyy+zip".
</t>
<t>
For cases not defined in +zip, then as specified in "xxx/yyy+zip".
</t>
</list>
</t>
</list>
</t>
<t hangText='Interoperability considerations:'>
n/a
</t>
<t hangText='Security considerations:'>
ZIP 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.
</t>
<t hangText='Contact:'>
Apps Area Working Group (apps-discuss@ietf.org)
</t>
<t hangText='Author/Change controller:'>
The Apps Area Working Group has change control over this registration.
</t>
</list>
</t>
</section>
</section>
<section title='IANA Considerations'>
<t>
See the Message Type Structured Syntax Suffix registration forms in <xref target='json'/> - <xref target='zip'/>.
</t>
<t>
The existing Structured Syntax Suffix registration for "+xml" is modified to include the following
<list style='hanging' hangIndent='20'>
<t hangText='Fragment identifier considerations:'>
<list hangIndent='0'>
<t>
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 <xref target='RFC3023'/>, sections 5 and 7.)
</t>
<t>
The syntax and semantics for fragment identifiers for a specific
"xxx/yyy+xml" SHOULD be processed as follows:
<list>
<t>For cases defined in +xml, where the fragment identifier resolves per
the +xml rules, then as specified in +xml.
</t>
<t>
For cases defined in +xml, where the fragment identifier does not resolve per
the +xml rules, then as specified in "xxx/yyy+xml".
</t>
<t>
For cases not defined in +xml, then as specified in "xxx/yyy+xml".
</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
<section title='Security Considerations'>
<t>
See the Security considerations sections found in the Message Type Structured Syntax
Suffix registration forms from <xref target='json'/> - <xref target='wbxml'/>.
</t>
<t>
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.
</t>
<t>
When updating the fragment identifier processing rules for a specific 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.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.4627' ?>
<reference anchor="ITU.X690.2008">
<front>
<title>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)</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="November" year="2008" />
</front>
<seriesInfo name="ITU-T" value="Recommendation X.690" />
<!-- http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf -->
</reference>
<reference anchor="ITU.X891.2005">
<front>
<title>Recommendation ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications of ASN.1: Fast infoset</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="May" year="2005" />
</front>
<seriesInfo name="ITU-T" value="Recommendation X.891" />
<!-- http://www.itu.int/rec/T-REC-X.891-200505-I/en -->
</reference>
<reference anchor="WBXML">
<front>
<title>Binary XML Content Format Specification</title>
<author>
<organization>Open Mobile Alliance</organization>
</author>
<date month='July' year='2001'/>
</front>
<seriesInfo name='OMA' value='Wireless Access Protocol WAP-192-WBXML-20010725-a'/>
</reference>
<reference anchor="ZIP">
<front>
<title>APPNOTE.TXT - .ZIP File Format Specification</title>
<author>
<organization>PKWARE, Inc.</organization>
<address>
<uri>http://www.pkware.com/documents/casestudies/APPNOTE.TXT</uri>
<!-- http://www.iana.org/assignments/media-types/application/zip -->
</address>
</author>
<date month='September' year='2007'/>
</front>
<seriesInfo name='PKWARE' value='.ZIP File Format Specification - Version 6.3.2'/>
</reference>
<?rfc include='reference.RFC.2045' ?>
<?rfc include='reference.RFC.2119' ?>
<?rfc include='reference.RFC.3023' ?>
</references>
<references title='Informative References'>
<?rfc include='reference.I-D.ietf-appsawg-media-type-regs' ?>
</references>
<section title="Change History">
<t>This section is to be removed before publication.
<list style='hanging' hangIndent='20'>
<t hangText='draft-ietf-appsawg-media-type-suffix-regs-03'>
Added generic fragment idenfier rules to +ber/+der to make them consistant with other registrations.
<vspace/>
Added some warning about how adding/changing fragment identifier rules for a +suffix
can affect fragment identifier processing rules for previously registered xxx/yyy+suffix media types.
<vspace/>
</t>
<t hangText='draft-ietf-appsawg-media-type-suffix-regs-02'>
Added BER/DER security considerations.
<vspace/>
Reworked fragment identifier wording some more.
<vspace/>
</t>
<t hangText='draft-ietf-appsawg-media-type-suffix-regs-01'>
Reordered the sections.
<vspace/>
Cleaned up some MUSTard.
<vspace/>
Fixed some references.
<vspace/>
Added encoding considerations.
<vspace/>
Reworked fragment identifier wording.
</t>
<t hangText='draft-ietf-appsawg-media-type-suffix-regs-00'>
Added the fragment identifier consideration sections.
<vspace/>
Added a note about +xml fragment identifier considerations.
</t>
<t hangText='draft-hansen-media-type-suffix-regs-02'>
Added +zip.
<vspace/>
Fixed up the ISO document references.
<vspace/>
Minor changes.
</t>
<t hangText='draft-hansen-media-type-suffix-regs-01'>
Added +ber.
<vspace/>
Minor changes.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:25:00 |