draft-ietf-appsawg-media-type-suffix-regs-08.txt   rfc6839.txt 
Network Working Group T. Hansen Internet Engineering Task Force (IETF) T. Hansen
Internet-Draft AT&T Laboratories Request for Comments: 6839 AT&T Laboratories
Updates: 3023 (if approved) A. Melnikov Updates: 3023 A. Melnikov
Intended status: Informational Isode Ltd Category: Informational Isode Ltd
Expires: May 9, 2013 November 5, 2012 ISSN: 2070-1721 January 2013
Additional Media Type Structured Syntax Suffixes Additional Media Type Structured Syntax Suffixes
draft-ietf-appsawg-media-type-suffix-regs-08
Abstract Abstract
A content media type name sometimes includes partitioned meta- A content media type name sometimes includes partitioned meta-
information distinguish by a Structured Syntax, to permit noting an information distinguished by a structured syntax to permit noting an
attribute of the media as a suffix to the name. This document attribute of the media as a suffix to the name. This document
defines several Structured Syntax Suffixes for use with media type defines several structured syntax suffixes for use with media type
registrations. In particular, it defines and registers the "+json", registrations. In particular, it defines and registers the "+json",
"+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax
Suffixes, and provides a Message Type Structured Syntax Suffix suffixes, and provides a media type structured syntax suffix
registration form for the "+xml" Structured Syntax Suffix. registration form for the "+xml" structured syntax suffix.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on May 9, 2013. 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 Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. When to Use these Structured Syntax Suffixes . . . . . . . . . 3 2. When to Use These Structured Syntax Suffixes . . . . . . . . . 3
3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 4 3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 4
3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 4 3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 4
3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 5 3.2. The +ber Structured Syntax Suffix . . . . . . . . . . . . 5
3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 6 3.3. The +der Structured Syntax Suffix . . . . . . . . . . . . 6
3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 8 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 7
3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 9 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 9
3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 10 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.1. The +xml Structured Syntax Suffix . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
[RFC3023] created the +xml suffix convention that can be used when [RFC3023] created the +xml suffix convention that can be used when
defining names for media types whose representation uses XML defining names for media types whose representation uses XML
underneath. That is, they could have been successfully parsed as if underneath. That is, they could have been successfully parsed as if
the media type had been application/xml in addition to their being the media type had been application/xml in addition to their being
parsed as their media type that is using the +xml suffix. parsed as their media type that is using the +xml suffix. [RFC6838]
[I-D.ietf-appsawg-media-type-regs] defines the Message Type defines the media type "Structured Syntax Suffix Registry" to be used
Structured Syntax Suffixes registry to be used for such Structured for such structured syntax suffixes.
Syntax Suffixes.
A variety of Structured Syntax Suffixes have already been used in A variety of structured syntax suffixes have already been used in
some media type registrations, in particular "+json", "+der", some media type registrations, in particular "+json", "+der",
"+fastinfoset" and "+wbxml". This document defines and registers "+fastinfoset", and "+wbxml". This document defines and registers
these Structured Syntax Suffixes in the Structured Syntax Suffix these structured syntax suffixes in the Structured Syntax Suffix
registry, along with "+ber" and "+zip". In addition, this document Registry, along with "+ber" and "+zip". In addition, this document
updates [RFC3023] to formally register the "+xml" Structured Syntax updates [RFC3023] to formally register the "+xml" structured syntax
Suffix according to procedure defined in suffix according to the procedure defined in [RFC6838].
[I-D.ietf-appsawg-media-type-regs].
Discussion of this document should occur in the Apps Area Working
Group (apps-discuss@ietf.org). [RFC Editor note: remove this
paragraph.]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. When to Use these Structured Syntax Suffixes 2. When to Use These Structured Syntax Suffixes
Each of the Structured Syntax Suffixes defined in this document is Each of the structured syntax suffixes defined in this document is
appropriate for use when the media type identifies the semantics of appropriate for use when the media type identifies the semantics of
the protocol payload. That is, knowing the semantics of the specific the protocol payload. That is, knowing the semantics of the specific
media type provides for more specific processing of the content than media type provides for more specific processing of the content than
that afforded by generic processing of the underlying representation. that afforded by generic processing of the underlying representation.
At the same time, using the suffix allows receivers of the media At the same time, using the suffix allows receivers of the media
types to do generic processing of the underlying representation in types to do generic processing of the underlying representation in
cases where cases where
they do not need to perform special handling of the particular they do not need to perform special handling of the particular
semantics of the exact media type, and, semantics of the exact media type, and
there is no special knowledge needed by such a generic processor there is no special knowledge needed by such a generic processor
in order to parse that underlying representation other than what in order to parse that underlying representation other than what
would be needed to parse any example of that underlying would be needed to parse any example of that underlying
representation. representation.
3. Initial Structured Syntax Suffix Definitions 3. Initial Structured Syntax Suffix Definitions
3.1. The +json Structured Syntax Suffix 3.1. The +json Structured Syntax Suffix
[RFC4627] defines the "application/json" media type. The suffix [RFC4627] defines the "application/json" media type. The suffix
"+json" MAY be used with any media type whose representation follows "+json" MAY be used with any media type whose representation follows
that established for "application/json". The Message Type Structured that established for "application/json". The media type structured
Syntax Suffix registration form follows. See syntax suffix registration form follows. See [RFC6838] for
[I-D.ietf-appsawg-media-type-regs] for definitions of each of the definitions of each of the registration form headings.
registration form headings.
Name: JavaScript Object Notation (JSON) Name: JavaScript Object Notation (JSON)
+suffix: +json +suffix: +json
References: [RFC4627] References: [RFC4627]
Encoding considerations: Per [RFC4627], JSON is allowed to be Encoding considerations:
represented using UTF-8, UTF-16, or UTF-32. When
JSON is written in UTF-8, JSON is 8bit compatible Per [RFC4627], JSON is allowed to be represented using UTF-8,
([RFC2045]). When JSON is written in UTF-16 or UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit
UTF-32, JSON is binary ([RFC2045]). compatible ([RFC2045]). When JSON is written in UTF-16 or UTF-32,
JSON is binary ([RFC2045]).
Fragment identifier considerations: Fragment identifier considerations:
The syntax and semantics of fragment The syntax and semantics of fragment identifiers specified for
identifiers specified for +json SHOULD be as +json SHOULD be as specified for "application/json". (At
specified for "application/json". (At publication of this document, there is no fragment identification
publication of this document, there is no syntax defined for "application/json".)
fragment identification syntax defined for
"application/json".)
The syntax and semantics for fragment The syntax and semantics for fragment identifiers for a specific
identifiers for a specific "xxx/yyy+json" "xxx/yyy+json" SHOULD be processed as follows:
SHOULD be processed as follows:
For cases defined in +json, where the For cases defined in +json, where the fragment identifier resolves
fragment identifier resolves per the +json per the +json rules, then process as specified in +json.
rules, then as specified in +json.
For cases defined in +json, where the For cases defined in +json, where the fragment identifier does
fragment identifier does not resolve per not resolve per the +json rules, then process as specified in
the +json rules, then as specified in "xxx/ "xxx/yyy+json".
yyy+json".
For cases not defined in +json, then as For cases not defined in +json, then process as specified in
specified in "xxx/yyy+json". "xxx/yyy+json".
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: See [RFC4627] Security considerations: See [RFC4627]
Contact: Apps Area Working Group (apps-discuss@ietf.org) Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller:
Author/Change controller: The Apps Area Working Group. IESG has The Apps Area Working Group. IESG has change control over this
change control over this registration. registration.
3.2. The +ber Structured Syntax Suffixes 3.2. The +ber Structured Syntax Suffix
The ITU defined the Basic Encoding Rules (BER) message transfer The ITU defined the Basic Encoding Rules (BER) transfer syntax in
syntax in [ITU.X690.2008]. The suffix "+ber" MAY be used with any [ITU.X690.2008]. The suffix "+ber" MAY be used with any media type
media type whose representation follows the BER message transfer whose representation follows the BER transfer syntax. (The Expert
syntax. (The expert reviewer for Message Type Structured Syntax Reviewer for media type structured syntax suffix registrations ought
Suffix registrations ought to be aware of the relationship between to be aware of the relationship between BER and DER to aid in
BER and DER to aid in selecting the proper suffix.) The Message Type selecting the proper suffix.) The media type structured syntax
Structured Syntax Suffix registration form for +ber follows: suffix registration form for +ber follows:
Name: Basic Encoding Rules (BER) message transfer Name: Basic Encoding Rules (BER) transfer syntax
syntax
+suffix: +ber +suffix: +ber
References: [ITU.X690.2008] References: [ITU.X690.2008]
Encoding considerations: BER is a binary encoding. Encoding considerations: BER is a binary encoding.
Fragment identifier considerations: Fragment identifier considerations:
At publication of this document, there is no At publication of this document, there is no fragment
fragment identification syntax defined for identification syntax defined for +ber.
+ber.
The syntax and semantics for fragment The syntax and semantics for fragment identifiers for a specific
identifiers for a specific "xxx/yyy+ber" "xxx/yyy+ber" SHOULD be processed as follows:
SHOULD be processed as follows:
For cases defined in +ber, where the For cases defined in +ber, where the fragment identifier
fragment identifier resolves per the +ber resolves per the +ber rules, then process as specified in +ber.
rules, then as specified in +ber.
For cases defined in +ber, where the For cases defined in +ber, where the fragment identifier does
fragment identifier does not resolve per not resolve per the +ber rules, then process as specified in
the +ber rules, then as specified in "xxx/ "xxx/yyy+ber".
yyy+ber".
For cases not defined in +ber, then as For cases not defined in +ber, then process as specified in
specified in "xxx/yyy+ber". "xxx/yyy+ber".
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: Each individual media type registered with Security considerations:
a +ber suffix can have additional security
considerations.
BER has a type-length-value structure, and it is Each individual media type registered with a +ber suffix can have
easy to construct malicious content with invalid additional security considerations.
length fields that can cause buffer overrun
conditions.
BER allows for arbitrary levels of nesting, which BER has a type-length-value structure, and it is easy to construct
may make it possible to construct malicious malicious content with invalid length fields that can cause buffer
content that will cause a stack overflow. overrun conditions.
Interpreters of the BER structures should be BER allows for arbitrary levels of nesting, which may make it
aware of these issues and should take appropriate possible to construct malicious content that will cause a stack
measures to guard against buffer overflows and overflow.
stack overruns in particular and malicious
content in general.
Contact: Apps Area Working Group (apps-discuss@ietf.org) 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.
Author/Change controller: The Apps Area Working Group. IESG has Contact: Apps Area Working Group (apps-discuss@ietf.org)
change control over this registration.
3.3. The +der Structured Syntax Suffixes Author/Change controller:
The ITU defined the Distinguished Encoding Rules (DER) message The Apps Area Working Group. IESG has change control over this
transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used registration.
with any media type whose representation follows the DER message
transfer syntax. (The expert reviewer for Message Type Structured
Syntax Suffix registrations ought to be aware of the relationship
between BER and DER to aid in selecting the proper suffix.) The
Message Type Structured Syntax Suffix registration form for +der
follows:
Name: Distinguished Encoding Rules (DER) message 3.3. The +der Structured Syntax Suffix
transfer syntax
+suffix: +der 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:
References: [ITU.X690.2008] Name: Distinguished Encoding Rules (DER) transfer syntax
+suffix: +der
References: [ITU.X690.2008]
Encoding considerations: DER is a binary encoding. Encoding considerations: DER is a binary encoding.
Fragment identifier considerations: Fragment identifier considerations:
At publication of this document, there is no At publication of this document, there is no fragment
fragment identification syntax defined for identification syntax defined for +der.
+der.
The syntax and semantics for fragment The syntax and semantics for fragment identifiers for a specific
identifiers for a specific "xxx/yyy+der" "xxx/yyy+der" SHOULD be processed as follows:
SHOULD be processed as follows:
For cases defined in +der, where the For cases defined in +der, where the fragment identifier
fragment identifier resolves per the +der resolves per the +der rules, then process as specified in +der.
rules, then as specified in +der.
For cases defined in +der, where the For cases defined in +der, where the fragment identifier does
fragment identifier does not resolve per not resolve per the +der rules, then process as specified in
the +der rules, then as specified in "xxx/ "xxx/yyy+der".
yyy+der".
For cases not defined in +der, then as For cases not defined in +der, then process as specified in
specified in "xxx/yyy+der". "xxx/yyy+der".
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: Each individual media type registered with Security considerations:
a +der suffix can have additional security
considerations.
DER has a type-length-value structure, and it is Each individual media type registered with a +der suffix can have
easy to construct malicious content with invalid additional security considerations.
length fields that can cause buffer overrun
conditions.
DER allows for arbitrary levels of nesting, which DER has a type-length-value structure, and it is easy to construct
may make it possible to construct malicious malicious content with invalid length fields that can cause buffer
content that will cause a stack overflow. overrun conditions.
Interpreters of the DER structures should be DER allows for arbitrary levels of nesting, which may make it
aware of these issues and should take appropriate possible to construct malicious content that will cause a stack
measures to guard against buffer overflows and overflow.
stack overruns in particular and malicious
content in general.
Contact: Apps Area Working Group (apps-discuss@ietf.org) 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.
Author/Change controller: The Apps Area Working Group. IESG has Contact: Apps Area Working Group (apps-discuss@ietf.org)
change control over this registration.
Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
3.4. The +fastinfoset Structured Syntax Suffix 3.4. The +fastinfoset Structured Syntax Suffix
The ITU defined the Fast Infoset document format as a binary The ITU defined the Fast Infoset document format as a binary
representation of the XML Information Set in [ITU.X891.2005]. These representation of the XML Information Set in [ITU.X891.2005]. These
documents further define the "application/fastinfoset" media type. documents further define the "application/fastinfoset" media type.
The suffix "+fastinfoset" MAY be used with any media type whose The suffix "+fastinfoset" MAY be used with any media type whose
representation follows that established for "application/ representation follows that established for "application/
fastinfoset". The Message Type Structured Syntax Suffix registration fastinfoset". The media type structured syntax suffix registration
form follows: form follows:
Name: Fast Infoset document format Name: Fast Infoset document format
+suffix: +fastinfoset +suffix: +fastinfoset
References: [ITU.X891.2005]
References: [ITU.X891.2005] Encoding considerations:
Encoding considerations: Fast Infoset is a binary encoding. The Fast Infoset is a binary encoding. The binary, quoted-printable,
binary, quoted-printable and base64 content- and base64 content-transfer-encodings are suitable for use with
transfer-encodings are suitable for use with Fast Fast Infoset.
Infoset.
Fragment identifier considerations: Fragment identifier considerations:
The syntax and semantics of fragment The syntax and semantics of fragment identifiers specified for
identifiers specified for +fastinfoset SHOULD +fastinfoset SHOULD be as specified for "application/fastinfoset".
be as specified for "application/fastinfoset". (At publication of this document, there is no fragment
(At publication of this document, there is no identification syntax defined for "application/fastinfoset".)
fragment identification syntax defined for
"application/fastinfoset".)
The syntax and semantics for fragment The syntax and semantics for fragment identifiers for a specific
identifiers for a specific "xxx/ "xxx/ yyy+fastinfoset" SHOULD be processed as follows:
yyy+fastinfoset" SHOULD be processed as
follows:
For cases defined in +fastinfoset, where For cases defined in +fastinfoset, where the fragment
the fragment identifier resolves per the identifier resolves per the +fastinfoset rules, then process as
+fastinfoset rules, then as specified in specified in +fastinfoset.
+fastinfoset.
For cases defined in +fastinfoset, where For cases defined in +fastinfoset, where the fragment
the fragment identifier does not resolve identifier does not resolve per the +fastinfoset rules, then
per the +fastinfoset rules, then as process as specified in "xxx/yyy+fastinfoset".
specified in "xxx/yyy+fastinfoset".
For cases not defined in +fastinfoset, then For cases not defined in +fastinfoset, then process as
as specified in "xxx/yyy+fastinfoset". specified in "xxx/ yyy+fastinfoset".
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: There are no security considerations 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) There are no security considerations inherent in Fast Infoset.
Each individual media type registered with a +fastinfoset suffix
can have additional security considerations.
Author/Change controller: The Apps Area Working Group. IESG has Contact: Apps Area Working Group (apps-discuss@ietf.org)
change control over this registration.
Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
3.5. The +wbxml Structured Syntax Suffix 3.5. The +wbxml Structured Syntax Suffix
The WAP Forum has defined the WAP Binary XML (WBXML) document format The Wireless Application Protocol (WAP) Forum has defined the WAP
as a binary representation of XML in [WBXML]. This document further Binary XML (WBXML) document format as a binary representation of XML
defines the "application/vnd.wap.wbxml" media type. The suffix in [WBXML]. This document further defines the "application/
"+wbxml" MAY be used with any media type whose representation follows vnd.wap.wbxml" media type. The suffix "+wbxml" MAY be used with any
that established for "application/vnd.wap.wbxml". The Message Type media type whose representation follows that established for
Structured Syntax Suffix registration form follows: "application/vnd.wap.wbxml". The media type structured syntax suffix
registration form follows:
Name: WAP Binary XML (WBXML) document format Name: WAP Binary XML (WBXML) document format
+suffix: +wbxml +suffix: +wbxml
References: [WBXML] References: [WBXML]
Encoding considerations: WBXML is a binary encoding. Encoding considerations: WBXML is a binary encoding.
Fragment identifier considerations: Fragment identifier considerations:
The syntax and semantics of fragment The syntax and semantics of fragment identifiers specified for
identifiers specified for +wbxml SHOULD be as +wbxml SHOULD be as specified for "application/vnd.wap.wbxml".
specified for "application/vnd.wap.wbxml". (At publication of this document, there is no fragment
(At publication of this document, there is no identification syntax defined for "application/vnd.wap.wbxml".)
fragment identification syntax defined for
"application/vnd.wap.wbxml".)
The syntax and semantics for fragment The syntax and semantics for fragment identifiers for a specific
identifiers for a specific "xxx/yyy+wbxml" "xxx/yyy+wbxml" SHOULD be processed as follows:
SHOULD be processed as follows:
For cases defined in +wbxml, where the For cases defined in +wbxml, where the fragment identifier
fragment identifier resolves per the +wbxml resolves per the +wbxml rules, then process as specified in
rules, then as specified in +wbxml. +wbxml.
For cases defined in +wbxml, where the For cases defined in +wbxml, where the fragment identifier does
fragment identifier does not resolve per not resolve per the +wbxml rules, then process as specified in
the +wbxml rules, then as specified in "xxx/yyy+wbxml".
"xxx/yyy+wbxml".
For cases not defined in +wbxml, then as For cases not defined in +wbxml, then process as specified in
specified in "xxx/yyy+wbxml". "xxx/yyy+wbxml".
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: There are no security considerations 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) There are no security considerations inherent in WBXML. Each
individual media type registered with a +wbxml suffix can have
additional security considerations.
Author/Change controller: The Apps Area Working Group. IESG has Contact: Apps Area Working Group (apps-discuss@ietf.org)
change control over this registration. Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
3.6. The +zip Structured Syntax Suffix 3.6. The +zip Structured Syntax Suffix
The ZIP format is a public domain, cross-platform, interoperable file The ZIP format is a public domain, cross-platform, interoperable file
storage and transfer format, originally defined by PKWARE, Inc.; it storage and transfer format, originally defined by PKWARE, Inc.; it
supports compression and encryption and is used as the underlying supports compression and encryption and is used as the underlying
representation by a variety of file formats. The media type representation by a variety of file formats. The media type
"application/zip" has been registered for such files. The suffix "application/zip" has been registered for such files. The suffix
"+zip" MAY be used with any media type whose representation follows "+zip" MAY be used with any media type whose representation follows
that established for "application/zip". The Message Type Structured that established for "application/zip". The media type structured
Syntax Suffix registration form follows: syntax suffix registration form follows:
Name: ZIP file storage and transfer format Name: ZIP file storage and transfer format
+suffix: +zip +suffix: +zip
References: [ZIP]
References: [ZIP]
Encoding considerations: ZIP is a binary encoding. Encoding considerations: ZIP is a binary encoding.
Fragment identifier considerations: Fragment identifier considerations:
The syntax and semantics of fragment The syntax and semantics of fragment identifiers specified for
identifiers specified for +zip SHOULD be as +zip SHOULD be as specified for "application/zip". (At
specified for "application/zip". (At publication of this document, there is no fragment identification
publication of this document, there is no syntax defined for "application/zip".)
fragment identification syntax defined for
"application/zip".)
The syntax and semantics for fragment The syntax and semantics for fragment identifiers for a specific
identifiers for a specific "xxx/yyy+zip" "xxx/yyy+zip" SHOULD be processed as follows:
SHOULD be processed as follows:
For cases defined in +zip, where the For cases defined in +zip, where the fragment identifier
fragment identifier resolves per the +zip resolves per the +zip rules, then process as specified in +zip.
rules, then as specified in +zip.
For cases defined in +zip, where the For cases defined in +zip, where the fragment identifier does
fragment identifier does not resolve per not resolve per the +zip rules, then process as specified in
the +zip rules, then as specified in "xxx/ "xxx/yyy+zip".
yyy+zip".
For cases not defined in +zip, then as For cases not defined in +zip, then process as specified in
specified in "xxx/yyy+zip". "xxx/yyy+zip".
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations:
Security considerations: ZIP files support two forms of encryption: IP files support two forms of encryption: Strong Encryption and
Strong Encryption and AES 128-bit, 192-bit and AES 128-bit, 192-bit, and 256-bit encryption; see the
256-bit encryption; see the specification for specification for further details. Each individual media type
further details. Each individual media type registered with a +zip suffix can have additional security
registered with a +zip suffix can have additional considerations.
security considerations.
Contact: Apps Area Working Group (apps-discuss@ietf.org) Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller: The Apps Area Working Group. IESG has Author/Change controller: The Apps Area Working Group. IESG has
change control over this registration. change control over this registration.
4. IANA Considerations 4. IANA Considerations
See the Message Type Structured Syntax Suffix registration forms in See the media type structured syntax suffix registration forms in
Section 3.1 - Section 3.6. Sections 3.1 - 3.6.
The following Structured Syntax Suffix registration for "+xml" shall 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 be used to reflect the information found in [RFC3023], with the
addition of fragment identifier considerations: addition of fragment identifier considerations. (Note that [RFC3023]
is in the process of being updated by [XML-MEDIATYPES].)
Name: Extensible Markup Language (XML) Name: Extensible Markup Language (XML)
+suffix: +xml +suffix: +xml
References: [RFC3023] References: [RFC3023]
Encoding considerations: Per [RFC3023], XML is allowed to be Encoding considerations:
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: 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]).
The syntax and semantics of fragment Fragment identifier considerations:
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 The syntax and semantics of fragment identifiers specified for
identifiers for a specific "xxx/yyy+xml" +xml SHOULD be as specified for "application/xml". (At
SHOULD be processed as follows: 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 For cases defined in +xml, where the fragment identifier
fragment identifier resolves per the +xml resolves per the +xml rules, then process as specified in +xml.
rules, then as specified in +xml.
For cases defined in +xml, where the For cases defined in +xml, where the fragment identifier does
fragment identifier does not resolve per not resolve per the +xml rules, then process as specified in
the +xml rules, then as specified in "xxx/ "xxx/yyy+xml".
yyy+xml".
For cases not defined in +xml, then as For cases not defined in +xml, then process as specified in
specified in "xxx/yyy+xml". "xxx/yyy+xml".
Interoperability considerations: See [RFC3023]. Interoperability considerations: See [RFC3023].
Security 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 Contact: Apps Area Working Group (apps-discuss@ietf.org)
change control over this registration.
Author/Change controller:
The Apps Area Working Group. IESG has change control over this
registration.
5. Security Considerations 5. Security Considerations
See the Security considerations sections found in the Message Type See the Security Considerations sections found in the media type
Structured Syntax Suffix registration forms from Section 3.1 - structured syntax suffix registration forms from Sections 3 and 4.
Section 3.5.
When updating a +<suffix> registration, care should be taken to When updating a +<suffix> registration, care should be taken to
review all previously-registered xxx/yyy+<suffix> media types as to review all previously-registered xxx/yyy+<suffix> media types as to
whether they might be affected by the updated +<suffix> registration. whether they might be affected by the updated +<suffix> registration.
Because the generic fragment identifier processing rules take Because the generic fragment identifier processing rules take
precedence over media-type-specific rules, introducing new or precedence over media-type-specific rules, introducing new or
changing existing definitions may break the existing registrations of changing existing definitions may break the existing registrations of
specific media types, as well as particular implementations of specific media types, as well as particular implementations of
applications that process affected media types. Such changes can applications that process affected media types. Such changes can
introduce interoperability and security issues. introduce interoperability and security issues.
skipping to change at page 14, line 32 skipping to change at page 13, line 49
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
6.2. Informative References 6.2. Informative References
[I-D.ietf-appsawg-media-type-regs] [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13,
Specifications and Registration Procedures", RFC 6838, January 2013.
draft-ietf-appsawg-media-type-regs-14 (work in progress),
June 2012.
[FRAGID-BP] [FRAGID-BP]
Tennison, J., "Best Practices for Fragment Identifiers and Tennison, J., "Best Practices for Fragment Identifiers and
Media Type Definitions", July 2012, Media Type Definitions", July 2012,
<http://www.w3.org/TR/fragid-best-practices/>. <http://www.w3.org/TR/fragid-best-practices/>.
Appendix A. Change History [XML-MEDIATYPES]
Lilley, C., Makoto, M., Melnikov, A., and H. Thompson,
This section is to be removed before publication. "XML Media Types", Work in Progress, November 2012.
draft-ietf-appsawg-media-type-suffix-regs-07 Added information based
on IANA and GEN-ART reviews.
draft-ietf-appsawg-media-type-suffix-regs-06 Clarified why this
document updates RFC 3023.
draft-ietf-appsawg-media-type-suffix-regs-05 Added an Informative
reference to
http://www.w3.org/TR/fragid-best-practices/.
Minor editorial changes.
draft-ietf-appsawg-media-type-suffix-regs-03 Added generic fragment
idenfier rules to +ber/+der to make them
consistant with other registrations.
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.
draft-ietf-appsawg-media-type-suffix-regs-02 Added BER/DER security
considerations.
Reworked fragment identifier wording some more.
draft-ietf-appsawg-media-type-suffix-regs-01 Reordered the sections.
Cleaned up some MUSTard.
Fixed some references.
Added encoding considerations.
Reworked fragment identifier wording.
draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment
identifier consideration sections.
Added a note about +xml fragment identifier
considerations.
draft-hansen-media-type-suffix-regs-02 Added +zip.
Fixed up the ISO document references.
Minor changes.
draft-hansen-media-type-suffix-regs-01 Added +ber.
Minor changes.
Authors' Addresses Authors' Addresses
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
200 Laurel Ave. South 200 Laurel Ave. South
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: tony+sss@maillennium.att.com EMail: tony+sss@maillennium.att.com
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: Alexey.Melnikov@isode.com EMail: Alexey.Melnikov@isode.com
 End of changes. 121 change blocks. 
363 lines changed or deleted 290 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/