draft-ietf-appsawg-media-type-suffix-regs-01.txt   draft-ietf-appsawg-media-type-suffix-regs-02.txt 
Network Working Group T. Hansen Network Working Group T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Updates: 3023 (if approved) May 23, 2012 Updates: 3023 (if approved) July 17, 2012
Intended status: Standards Track Intended status: Best Current Practice
Expires: November 22, 2012 Expires: January 16, 2013
Additional Media Type Structured Syntax Suffixes Additional Media Type Structured Syntax Suffixes
draft-ietf-appsawg-media-type-suffix-regs-01 draft-ietf-appsawg-media-type-suffix-regs-02
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 distinguish 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 updates the "+xml" Message Type Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax
Suffix registration. Suffix registration.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2012. This Internet-Draft will expire on January 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. When to Use these Structured Syntax Suffixes . . . . . . . . . 2 2. When to Use these Structured Syntax Suffixes . . . . . . . . . 2
3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 3 3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 3
3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 3 3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 3
3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 4 3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 4
3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 4 3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 5
3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 5 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 6
3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 6 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 7
3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 6 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
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. [I-D.ietf- parsed as their media type that is using the +xml suffix. [I-D.ietf-
appsawg-media-type-regs] defines the Message Type Structured Syntax appsawg-media-type-regs] defines the Message Type Structured Syntax
Suffixes registry to be used for such Structured Syntax Suffixes. Suffixes registry to be used for such Structured Syntax Suffixes.
skipping to change at page 3, line 35 skipping to change at page 3, line 40
+suffix: +json +suffix: +json
References: [RFC4627] References: [RFC4627]
Encoding considerations: Per [RFC4627], JSON is allowed to be Encoding considerations: Per [RFC4627], JSON is allowed to be
represented using UTF-8, UTF-16, or UTF-32. When represented using UTF-8, UTF-16, or UTF-32. When
JSON is written in UTF-8, JSON is 8bit compatible JSON is written in UTF-8, JSON is 8bit compatible
([RFC2045]). When JSON is written in UTF-16 or ([RFC2045]). When JSON is written in UTF-16 or
UTF-32, JSON is binary ([RFC2045]). UTF-32, JSON is binary ([RFC2045]).
Fragment identifier considerations: Media types using "+json" SHOULD Fragment identifier considerations:
process any fragment identifiers defined for
"application/json" in the same way as defined for The syntax and semantics of fragment
that media type. (At publication of this identifiers specified for +json SHOULD be as
document, there is no fragment identification specified for "application/json". (At
syntax defined for "application/json".) Specific publication of this document, there is no
media types using "+json" MAY identify additional fragment identification syntax defined for
fragment identifier considerations, MAY define "application/json".)
processing for fragment identifiers that are
classed as errors for "application/json" and MAY The syntax and semantics for fragment
designate fragment identifiers defined for identifiers for a specific "xxx/yyy+json"
"application/json" that SHOULD NOT be used. SHOULD be processed as follows:
For cases defined in +json, where the
fragment identifier resolves per the +json
rules, then as specified in +json.
For cases defined in +json, where the
fragment identifier does not resolve per
the +json rules, then as specified in "xxx/
yyy+json".
For cases not defined in +json, then as
specified in "xxx/yyy+json".
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: The Apps Area Working Group has change Author/Change controller: The Apps Area Working Group has change
control over this registration. control over this registration.
skipping to change at page 4, line 26 skipping to change at page 4, line 45
+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: n/a Fragment identifier considerations: n/a
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: There are no security considerations Security considerations: Each individual media type registered with a
inherent in BER. Each individual media type +ber suffix can have additional security
registered with a +ber suffix can have additional considerations.
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.
Some BER schema allow 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) Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller: The Apps Area Working Group has change Author/Change controller: The Apps Area Working Group has change
control over this registration. control over this registration.
3.3. The +der Structured Syntax Suffixes 3.3. The +der Structured Syntax Suffixes
The ITU defined the Distinguished Encoding Rules (DER) message The ITU defined the Distinguished Encoding Rules (DER) message
transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used
skipping to change at page 5, line 4 skipping to change at page 5, line 36
+suffix: +der +suffix: +der
References: [ITU.X690.2008] References: [ITU.X690.2008]
Encoding considerations: DER is a binary encoding. Encoding considerations: DER is a binary encoding.
Fragment identifier considerations: n/a Fragment identifier considerations: n/a
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: There are no security considerations
inherent in DER. Each individual media type Security considerations: Each individual media type registered with a
registered with a +der suffix can have additional +ber suffix can have additional security
security considerations. 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.
Some DER schema allow 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) Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller: The Apps Area Working Group has change Author/Change controller: The Apps Area Working Group has change
control over this registration. 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
skipping to change at page 5, line 35 skipping to change at page 6, line 35
+suffix: +fastinfoset +suffix: +fastinfoset
References: [ITU.X891.2005] References: [ITU.X891.2005]
Encoding considerations: Fast Infoset is a binary encoding. The Encoding considerations: Fast Infoset is a binary encoding. The
binary, quoted-printable and base64 content- binary, quoted-printable and base64 content-
transfer-encodings are suitable for use with Fast transfer-encodings are suitable for use with Fast
Infoset. Infoset.
Fragment identifier considerations: Media types using "+fastinfoset" Fragment identifier considerations:
SHOULD process any fragment identifiers defined
for "application/fastinfoset" in the same way as The syntax and semantics of fragment
defined for that media type. (At publication of identifiers specified for +fastinfoset SHOULD
this document, there is no fragment be as specified for "application/fastinfoset".
identification syntax defined for "application/ (At publication of this document, there is no
fastinfoset".) Specific media types using fragment identification syntax defined for
"+fastinfoset" MAY identify additional fragment "application/fastinfoset".)
identifier considerations, MAY define processing
for fragment identifiers that are classed as The syntax and semantics for fragment
errors for "application/fastinfoset" and MAY identifiers for a specific "xxx/
designate fragment identifiers defined for yyy+fastinfoset" SHOULD be processed as
"application/fastinfoset" that SHOULD NOT be follows:
used.
For cases defined in +fastinfoset, where
the fragment identifier resolves per the
+fastinfoset rules, then as specified in
+fastinfoset.
For cases defined in +fastinfoset, where
the fragment identifier does not resolve
per the +fastinfoset rules, then as
specified in "xxx/yyy+fastinfoset".
For cases not defined in +fastinfoset, then
as specified in "xxx/yyy+fastinfoset".
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: There are no security considerations Security considerations: There are no security considerations
inherent in Fast Infoset. Each individual media inherent in Fast Infoset. Each individual media
type registered with a +fastinfoset suffix can type registered with a +fastinfoset suffix can
have additional security considerations. have additional security considerations.
Contact: Apps Area Working Group (apps-discuss@ietf.org) Contact: Apps Area Working Group (apps-discuss@ietf.org)
skipping to change at page 6, line 30 skipping to change at page 7, line 39
Structured Syntax Suffix registration form follows: 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: Media types using "+wbxml" SHOULD Fragment identifier considerations:
process any fragment identifiers defined for
"application/vnd.wap.wbxml" in the same way as The syntax and semantics of fragment
defined for that media type. (At publication of identifiers specified for +wbxml SHOULD be as
this document, there is no fragment specified for "application/vnd.wap.wbxml".
identification syntax defined for "application/ (At publication of this document, there is no
vnd.wap.wbxml".) Specific media types using fragment identification syntax defined for
"+wbxml" MAY identify additional fragment "application/vnd.wap.wbxml".)
identifier considerations, MAY define processing
for fragment identifiers that are classed as The syntax and semantics for fragment
errors for "application/vnd.wap.wbxml" and MAY identifiers for a specific "xxx/yyy+wbxml"
designate fragment identifiers defined for SHOULD be processed as follows:
"application/vnd.wap.wbxml" that SHOULD NOT be
used. For cases defined in +wbxml, where the
fragment identifier resolves per the +wbxml
rules, then as specified in +wbxml.
For cases defined in +wbxml, where the
fragment identifier does not resolve per
the +wbxml rules, then as specified in "xxx
/yyy+wbxml".
For cases not defined in +wbxml, then as
specified in "xxx/yyy+wbxml".
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: There are no security considerations Security considerations: There are no security considerations
inherent in WBXML. Each individual media type inherent in WBXML. Each individual media type
registered with a +wbxml suffix can have registered with a +wbxml suffix can have
additional security considerations. additional security considerations.
Contact: Apps Area Working Group (apps-discuss@ietf.org) Contact: Apps Area Working Group (apps-discuss@ietf.org)
skipping to change at page 7, line 24 skipping to change at page 8, line 44
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: Media types using "+zip" SHOULD Fragment identifier considerations:
process any fragment identifiers defined for
"application/zip" in the same way as defined for The syntax and semantics of fragment
that media type. (At publication of this identifiers specified for +zip SHOULD be as
document, there is no fragment identification specified for "application/zip". (At
syntax defined for "application/zip".) Specific publication of this document, there is no
media types using "+zip" MAY identify additional fragment identification syntax defined for
fragment identifier considerations, MAY define "application/zip".)
processing for fragment identifiers that are
classed as errors for "application/zip" and MAY The syntax and semantics for fragment
designate fragment identifiers defined for identifiers for a specific "xxx/yyy+zip"
"application/zip" that SHOULD NOT be used. SHOULD be processed as follows:
For cases defined in +zip, where the
fragment identifier resolves per the +zip
rules, then as specified in +zip.
For cases defined in +zip, where the
fragment identifier does not resolve per
the +zip rules, then as specified in "xxx/
yyy+zip".
For cases not defined in +zip, then as
specified in "xxx/yyy+zip".
Interoperability considerations: n/a Interoperability considerations: n/a
Security considerations: ZIP files support two forms of encryption: Security considerations: ZIP files support two forms of encryption:
Strong Encryption and AES 128-bit, 192-bit and Strong Encryption and AES 128-bit, 192-bit and
256-bit encryption; see the specification for 256-bit encryption; see the specification for
further details. Each individual media type further details. Each individual media type
registered with a +zip suffix can have additional registered with a +zip suffix can have additional
security considerations. security considerations.
skipping to change at page 8, line 4 skipping to change at page 9, line 38
Author/Change controller: The Apps Area Working Group has change Author/Change controller: The Apps Area Working Group has change
control over this registration. control over this registration.
4. IANA Considerations 4. IANA Considerations
See the Message Type Structured Syntax Suffix registration forms in See the Message Type Structured Syntax Suffix registration forms in
Section 3.1 - Section 3.6. Section 3.1 - Section 3.6.
The existing Structured Syntax Suffix registration for "+xml" is The existing Structured Syntax Suffix registration for "+xml" is
modified to include the following modified to include the following
Fragment identifier considerations: Media types using "+xml" SHOULD
process any fragment identifiers defined for Fragment identifier considerations:
"application/xml" in the same way as defined for
that media type. (At publication of this The syntax and semantics of fragment
document, the fragment identification syntax identifiers specified for +xml SHOULD be as
considerations for "application/xml" are defined specified for "application/xml". (At
in [RFC3023], sections 5 and 7.) Specific media publication of this document, the fragment
types using "+xml" MAY identify additional identification syntax considerations for
fragment identifier considerations, MAY define "application/xml" are defined in [RFC3023],
processing for fragment identifiers that are sections 5 and 7.)
classed as errors for "application/xml" and MAY
designate fragment identifiers defined for The syntax and semantics for fragment
"application/xml" that SHOULD NOT be used. 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 as specified in +xml.
For cases defined in +xml, where the
fragment identifier does not resolve per
the +xml rules, then as specified in "xxx/
yyy+xml".
For cases not defined in +xml, then as
specified in "xxx/yyy+xml".
5. Security Considerations 5. Security Considerations
See the Security considerations sections found in the Message Type See the Security considerations sections found in the Message Type
Structured Syntax Suffix registration forms from Section 3.1 - Structured Syntax Suffix registration forms from Section 3.1 -
Section 3.5. Section 3.5.
6. References 6. References
6.1. Normative References 6.1. Normative References
skipping to change at page 9, line 16 skipping to change at page 11, line 8
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] [I-D.ietf-appsawg-media-type-regs]
Freed, N., Klensin, J. and T. Hansen, "Media Type Freed, N., Klensin, J. and T. Hansen, "Media Type
Specifications and Registration Procedures", Internet- Specifications and Registration Procedures", Internet-
Draft draft-ietf-appsawg-media-type-regs-09, May 2012. Draft draft-ietf-appsawg-media-type-regs-14, June 2012.
Appendix A. Change History Appendix A. Change History
This section is to be removed before publication. This section is to be removed before publication.
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 draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment
identifier consideration sections. identifier consideration sections.
Added a note about +xml fragment identifier Added a note about +xml
considerations. fragment identifier considerations.
draft-hansen-media-type-suffix-regs-02 Added +zip. draft-hansen-media-type-suffix-regs-02 Added +zip.
Fixed up the ISO document references. Fixed up the ISO document
Minor changes. references.
Minor changes.
draft-hansen-media-type-suffix-regs-01 Added +ber. draft-hansen-media-type-suffix-regs-01 Added +ber.
Minor changes. Minor changes.
Author's Address Author's Address
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
 End of changes. 19 change blocks. 
103 lines changed or deleted 209 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/