draft-ietf-appsawg-media-type-suffix-regs-00.txt   draft-ietf-appsawg-media-type-suffix-regs-01.txt 
Network Working Group T. Hansen Network Working Group T. Hansen
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Intended status: Standards Track April 26, 2012 Updates: 3023 (if approved) May 23, 2012
Expires: October 26, 2012 Intended status: Standards Track
Expires: November 22, 2012
Additional Media Type Structured Syntax Suffixes Additional Media Type Structured Syntax Suffixes
draft-ietf-appsawg-media-type-suffix-regs-00 draft-ietf-appsawg-media-type-suffix-regs-01
Abstract Abstract
This document defines several Structured Syntax Suffixes for use with A content media type name sometimes includes partitioned meta-
media type registrations. In particular, it defines and registers information distinguish by a Structured Syntax, to permit noting an
the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" attribute of the media as a suffix to the name. This document
Structured Syntax Suffixes, and updates the "+xml" Structured Syntax 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. 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 October 26, 2012. This Internet-Draft will expire on November 22, 2012.
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 (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 1, line 51 skipping to change at page 2, line 4
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 (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. 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. The +json Structured Syntax Suffix . . . . . . . . . . . . . . 2 3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 3
4. The +ber and +der Structured Syntax Suffixes . . . . . . . . . 3 3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 3
5. The +fastinfoset Structured Syntax Suffix . . . . . . . . . . 4 3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 4
6. The +wbxml Structured Syntax Suffix . . . . . . . . . . . . . 5 3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 4
7. The +zip Structured Syntax Suffix . . . . . . . . . . . . . . 6 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
[RFC3023] created the +xml suffix convention that may be used by [RFC3023] created the +xml suffix convention that can be used when
media types whose representation uses XML underneath, that is, they defining names for media types whose representation uses XML
could have been successfully parsed as if the media type had been underneath. That is, they could have been successfully parsed as if
application/xml in addition to their being parsed as their media type the media type had been application/xml in addition to their being
that is using the +xml suffix. [I-D.ietf-appsawg-media-type-regs] parsed as their media type that is using the +xml suffix. [I-D.ietf-
defines a registry to be used for future Structured Syntax Suffixes. appsawg-media-type-regs] defines the Message Type Structured Syntax
Suffixes registry to be used for such Structured 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 registration, 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 the "+xml" Structured Syntax Suffix registration. updates the "+xml" Structured Syntax Suffix registration.
Discussion of this document should occur in the Apps Area Working Discussion of this document should occur in the Apps Area Working
Group (apps-discuss@ietf.org). [RFC Editor note: remove this Group (apps-discuss@ietf.org). [RFC Editor note: remove this
paragraph.] 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 are 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 provides 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 1) they do not need to handle specially the particular cases where
semantics of the exact media type, and, 2) there is no special they do not need to perform special handling of the particular
knowledge needed by such a generic processor in order to parse that semantics of the exact media type, and,
underlying representation other than what would be needed to parse
any example of that underlying representation.
3. The +json Structured Syntax Suffix 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 [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 Message Type Structured
Syntax Suffix registration form follows: Syntax Suffix registration form follows. See [I-D.ietf-appsawg-
media-type-regs] for definitions of each of the 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 may be represented using Encoding considerations: Per [RFC4627], JSON is allowed to be
UTF-8, UTF-16, or UTF-32. When JSON is written represented using UTF-8, UTF-16, or UTF-32. When
in UTF-8, JSON is 8bit compatible. When JSON is JSON is written in UTF-8, JSON is 8bit compatible
written in UTF-16 or UTF-32, JSON is binary. ([RFC2045]). When JSON is written in UTF-16 or
UTF-32, JSON is binary ([RFC2045]).
Fragment identifier considerations Media types using "+json" SHOULD Fragment identifier considerations: Media types using "+json" SHOULD
process any fragment identifiers defined for process any fragment identifiers defined for
"application/json" in the same way as defined for "application/json" in the same way as defined for
that media type. (At publication of this that media type. (At publication of this
document, there is no fragment identification document, there is no fragment identification
syntax defined for "application/json".) Specific syntax defined for "application/json".) Specific
media types using "+json" MAY identify additional media types using "+json" MAY identify additional
fragment identifier considerations, MAY define fragment identifier considerations, MAY define
processing for fragment identifiers that are processing for fragment identifiers that are
classed as errors for "application/json" and MAY classed as errors for "application/json" and MAY
designate fragment identifiers defined for designate fragment identifiers defined for
"application/json" that SHOULD NOT be used. "application/json" that SHOULD NOT be used.
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.
4. The +ber and +der Structured Syntax Suffixes 3.2. The +ber Structured Syntax Suffixes
The ITU defined the Basic Encoding Rules (BER) and Distinguished The ITU defined the Basic Encoding Rules (BER) message transfer
Encoding Rules (DER) message transfer syntaxes in [ITU.X690.2008]. syntax in [ITU.X690.2008]. The suffix "+ber" MAY be used with any
The suffix "+ber" may be used with any media type whose media type whose representation follows the BER message transfer
representation follows the BER message transfer syntax. The suffix syntax. The Message Type Structured Syntax Suffix registration form
"+der" may be used with any media type whose representation follows for +ber follows:
the DER message transfer syntax. The Message Type Structured Syntax
Suffix registration forms follows:
Name Basic Encoding Rules (BER) message transfer Name: Basic Encoding Rules (BER) message transfer
syntax syntax
+suffix +ber +suffix: +ber
References [ITU.X690.2008]
Encoding considerations BER is a binary encoding. References: [ITU.X690.2008]
Fragment identifier considerations n/a Encoding considerations: BER is a binary encoding.
Interoperability considerations n/a Fragment identifier considerations: n/a
Security considerations There are no security considerations inherent Interoperability considerations: n/a
in BER. Each individual media type registered
with a +ber suffix may have additional security
considerations.
Contact Apps Area Working Group (apps-discuss@ietf.org) Security considerations: There are no security considerations
inherent in BER. Each individual media type
registered with a +ber suffix can have additional
security considerations.
Author/Change controller The Apps Area Working Group has change Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller: The Apps Area Working Group has change
control over this registration. control over this registration.
Name Distinguished Encoding Rules (DER) message 3.3. The +der Structured Syntax Suffixes
transfer syntax
+suffix +der The ITU defined the Distinguished Encoding Rules (DER) message
transfer syntax in [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:
References [ITU.X690.2008] Name: Distinguished Encoding Rules (DER) message
transfer syntax
Encoding considerations DER is a binary encoding. +suffix: +der
Fragment identifier considerations n/a References: [ITU.X690.2008]
Interoperability considerations n/a Encoding considerations: DER is a binary encoding.
Security considerations There are no security considerations inherent Fragment identifier considerations: n/a
in DER. Each individual media type registered
with a +der suffix may have additional security
considerations.
Contact Apps Area Working Group (apps-discuss@ietf.org) Interoperability considerations: n/a
Security considerations: There are no security considerations
inherent in DER. Each individual media type
registered with a +der suffix can have additional
security considerations.
Author/Change controller The Apps Area Working Group has change Contact: Apps Area Working Group (apps-discuss@ietf.org)
Author/Change controller: The Apps Area Working Group has change
control over this registration. control over this registration.
5. 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 Message 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 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: Media types using "+fastinfoset"
SHOULD process any fragment identifiers defined SHOULD process any fragment identifiers defined
for "application/fastinfoset" in the same way as for "application/fastinfoset" in the same way as
defined for that media type. (At publication of defined for that media type. (At publication of
this document, there is no fragment this document, there is no fragment
identification syntax defined for "application/ identification syntax defined for "application/
fastinfoset".) Specific media types using fastinfoset".) Specific media types using
"+fastinfoset" MAY identify additional fragment "+fastinfoset" MAY identify additional fragment
identifier considerations, MAY define processing identifier considerations, MAY define processing
for fragment identifiers that are classed as for fragment identifiers that are classed as
errors for "application/fastinfoset" and MAY errors for "application/fastinfoset" and MAY
designate fragment identifiers defined for designate fragment identifiers defined for
"application/fastinfoset" that SHOULD NOT be "application/fastinfoset" that SHOULD NOT be
used. used.
Interoperability considerations n/a Interoperability considerations: n/a
Security considerations There are no security considerations inherent Security considerations: There are no security considerations
in Fast Infoset. Each individual media type inherent in Fast Infoset. Each individual media
registered with a +fastinfoset suffix may have type registered with a +fastinfoset suffix can
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)
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.
6. 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 WAP Forum has defined the WAP Binary XML (WBXML) document format
as a binary representation of XML in [WBXML]. This document further as a binary representation of XML in [WBXML]. This document further
defines the "application/vnd.wap.wbxml" media type. The suffix defines the "application/vnd.wap.wbxml" media type. The suffix
"+wbxml" may be used with any media type whose representation follows "+wbxml" MAY be used with any media type whose representation follows
that established for "application/vnd.wap.wbxml". The Message Type that established for "application/vnd.wap.wbxml". The Message Type
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: Media types using "+wbxml" SHOULD
process any fragment identifiers defined for process any fragment identifiers defined for
"application/vnd.wap.wbxml" in the same way as "application/vnd.wap.wbxml" in the same way as
defined for that media type. (At publication of defined for that media type. (At publication of
this document, there is no fragment this document, there is no fragment
identification syntax defined for "application/ identification syntax defined for "application/
vnd.wap.wbxml".) Specific media types using vnd.wap.wbxml".) Specific media types using
"+wbxml" MAY identify additional fragment "+wbxml" MAY identify additional fragment
identifier considerations, MAY define processing identifier considerations, MAY define processing
for fragment identifiers that are classed as for fragment identifiers that are classed as
errors for "application/vnd.wap.wbxml" and MAY errors for "application/vnd.wap.wbxml" and MAY
designate fragment identifiers defined for designate fragment identifiers defined for
"application/vnd.wap.wbxml" that SHOULD NOT be "application/vnd.wap.wbxml" that SHOULD NOT be
used. used.
Interoperability considerations n/a Interoperability considerations: n/a
Security considerations There are no security considerations inherent Security considerations: There are no security considerations
in WBXML. Each individual media type registered inherent in WBXML. Each individual media type
with a +wbxml suffix may have additional security registered with a +wbxml suffix can have
considerations. additional 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 has change Author/Change controller: The Apps Area Working Group has change
control over this registration. control over this registration.
7. 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 Message 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.
Fragment identifier considerations Media types using "+zip" SHOULD Encoding considerations: ZIP is a binary encoding.
Fragment identifier considerations: Media types using "+zip" SHOULD
process any fragment identifiers defined for process any fragment identifiers defined for
"application/zip" in the same way as defined for "application/zip" in the same way as defined for
that media type. (At publication of this that media type. (At publication of this
document, there is no fragment identification document, there is no fragment identification
syntax defined for "application/zip".) Specific syntax defined for "application/zip".) Specific
media types using "+zip" MAY identify additional media types using "+zip" MAY identify additional
fragment identifier considerations, MAY define fragment identifier considerations, MAY define
processing for fragment identifiers that are processing for fragment identifiers that are
classed as errors for "application/zip" and MAY classed as errors for "application/zip" and MAY
designate fragment identifiers defined for designate fragment identifiers defined for
"application/zip" that SHOULD NOT be used. "application/zip" that SHOULD NOT be used.
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 may have additional registered with a +zip suffix can have additional
security 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 has change Author/Change controller: The Apps Area Working Group has change
control over this registration. control over this registration.
8. 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 - Section 7. Section 3.1 - Section 3.6.
The existing Structured Syntax Suffix registration for "+xml" should
be modified to include the following
Fragment identifier considerations Media types using "+xml" SHOULD The existing Structured Syntax Suffix registration for "+xml" is
modified to include the following
Fragment identifier considerations: Media types using "+xml" SHOULD
process any fragment identifiers defined for process any fragment identifiers defined for
"application/xml" in the same way as defined for "application/xml" in the same way as defined for
that media type. (At publication of this that media type. (At publication of this
document, the fragment identification syntax document, the fragment identification syntax
considerations for "application/xml" are defined considerations for "application/xml" are defined
in [RFC3023].) Specific media types using "+xml" in [RFC3023], sections 5 and 7.) Specific media
MAY identify additional fragment identifier types using "+xml" MAY identify additional
considerations, MAY define processing for fragment identifier considerations, MAY define
fragment identifiers that are classed as errors processing for fragment identifiers that are
for "application/xml" and MAY designate fragment classed as errors for "application/xml" and MAY
identifiers defined for "application/xml" that designate fragment identifiers defined for
SHOULD NOT be used. "application/xml" that SHOULD NOT be used.
5. Security Considerations
9. 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 - Section Structured Syntax Suffix registration forms from Section 3.1 -
6. Section 3.5.
10. References 6. References
10.1. Normative References 6.1. Normative References
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[ITU.X690.2008] [ITU.X690.2008]
International Telecommunications Union, "Recommendation International Telecommunications Union, "Recommendation
ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules: ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules:
Specification of basic encoding Rules (BER), Canonical Specification of basic encoding Rules (BER), Canonical
encoding rules (CER) and Distinguished encoding rules encoding rules (CER) and Distinguished encoding rules
(DER)", ITU-T Recommendation X.690, November 2008. (DER)", ITU-T Recommendation X.690, November 2008.
skipping to change at page 8, line 36 skipping to change at page 8, line 52
2005. 2005.
[WBXML] Open Mobile Alliance, "Binary XML Content Format [WBXML] Open Mobile Alliance, "Binary XML Content Format
Specification", OMA Wireless Access Protocol Specification", OMA Wireless Access Protocol
WAP-192-WBXML-20010725-a, July 2001. WAP-192-WBXML-20010725-a, July 2001.
[ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format [ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format
Specification", PKWARE .ZIP File Format Specification - Specification", PKWARE .ZIP File Format Specification -
Version 6.3.2, September 2007. Version 6.3.2, September 2007.
[RFC2045] Freed, N. and N.S. 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 [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.
10.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-05, April 2012. Draft draft-ietf-appsawg-media-type-regs-09, May 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-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 fragment identifier
considerations. considerations.
 End of changes. 86 change blocks. 
142 lines changed or deleted 167 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/