draft-ietf-appsawg-xml-mediatypes-01.txt   draft-ietf-appsawg-xml-mediatypes-02.txt 
Network Working Group C. Lilley Network Working Group C. Lilley
Internet-Draft W3C Internet-Draft W3C
Obsoletes: 3023 (if approved) M. Murata Obsoletes: 3023 (if approved) M. Murata
Updates: 4288, 4289, 6839 (if approved)International University of Japan Updates: 4289, 6839 (if approved) International University of Japan
Intended status: Standards Track A. Melnikov Intended status: Standards Track A. Melnikov
Expires: November 29, 2013 Isode Ltd. Expires: January 09, 2014 Isode Ltd.
H. S. Thompson H. S. Thompson
University of Edinburgh University of Edinburgh
May 28, 2013 July 08, 2013
XML Media Types XML Media Types
draft-ietf-appsawg-xml-mediatypes-01 draft-ietf-appsawg-xml-mediatypes-02
Abstract Abstract
This specification standardizes three media types -- application/xml, This specification standardizes three media types -- application/xml,
application/xml-external-parsed-entity, and application/xml-dtd -- application/xml-external-parsed-entity, and application/xml-dtd --
for use in exchanging network entities that are related to the for use in exchanging network entities that are related to the
Extensible Markup Language (XML) while defining text/xml and text/ Extensible Markup Language (XML) while defining text/xml and text/
xml-external-parsed-entity as aliases for the respective application/ xml-external-parsed-entity as aliases for the respective application/
types. This specification also standardizes a convention (using the types. This specification also standardizes a convention (using the
suffix '+xml') for naming media types outside of these five types suffix '+xml') for naming media types outside of these five types
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 29, 2013. This Internet-Draft will expire on January 09, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . . 4 3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Application/xml Registration . . . . . . . . . . . . . . 7 3.1. Application/xml Registration . . . . . . . . . . . . . . 6
3.2. Text/xml Registration . . . . . . . . . . . . . . . . . . 9 3.2. Text/xml Registration . . . . . . . . . . . . . . . . . . 8
3.3. Application/xml-external-parsed-entity Registration . . . 9 3.3. Application/xml-external-parsed-entity Registration . . . 8
3.4. Text/xml-external-parsed-entity Registration . . . . . . 10 3.4. Text/xml-external-parsed-entity Registration . . . . . . 9
3.5. Application/xml-dtd Registration . . . . . . . . . . . . 10 3.5. Application/xml-dtd Registration . . . . . . . . . . . . 9
3.6. Charset considerations . . . . . . . . . . . . . . . . . 11 3.6. Charset considerations . . . . . . . . . . . . . . . . . 10
3.6.1. Background . . . . . . . . . . . . . . . . . . . . . 12 3.6.1. Background . . . . . . . . . . . . . . . . . . . . . 11
4. The Byte Order Mark (BOM) and Conversions to/from the UTF-16 4. The Byte Order Mark (BOM) and Conversions to/from the UTF-16
Charset . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Charset . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 12 5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 12
6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 13 6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 13
7. XML Versions . . . . . . . . . . . . . . . . . . . . . . . . 14 7. XML Versions . . . . . . . . . . . . . . . . . . . . . . . . 13
8. A Naming Convention for XML-Based Media Types . . . . . . . . 14 8. A Naming Convention for XML-Based Media Types . . . . . . . . 13
8.1. Referencing . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Referencing . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. +xml Structured Syntax Suffix Registration . . . . . . . 15
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. application/xml or text/xml with Omitted Charset and 9.1. UTF-8 Charset . . . . . . . . . . . . . . . . . . . . . . 17
8-bit MIME entity . . . . . . . . . . . . . . . . . . . . 17 9.2. UTF-16 Charset . . . . . . . . . . . . . . . . . . . . . 17
9.2. application/xml or text/xml with Omitted Charset and 9.3. Omitted Charset and 8-bit MIME entity . . . . . . . . . . 18
16-bit MIME entity . . . . . . . . . . . . . . . . . . . 17 9.4. Omitted Charset and 16-bit MIME entity . . . . . . . . . 18
9.3. application/xml or text/xml with UTF-8 Charset . . . . . 17 9.5. Omitted Charset, no Internal Encoding Declaration and
9.4. application/xml with UTF-16 Charset . . . . . . . . . . . 18 UTF-8 Entity . . . . . . . . . . . . . . . . . . . . . . 19
9.5. text/xml with UTF-16 Charset . . . . . . . . . . . . . . 18 9.6. UTF-16BE Charset . . . . . . . . . . . . . . . . . . . . 19
9.6. application/xml with UTF-16BE Charset . . . . . . . . . . 18 9.7. Non-UTF Charset . . . . . . . . . . . . . . . . . . . . . 19
9.7. text/xml with UTF-16BE Charset . . . . . . . . . . . . . 19 9.8. Omitted Charset with Internal Encoding Declaration . . . 20
9.8. application/xml or text/xml with ISO-2022-KR Charset . . 19 9.9. INCONSISTENT EXAMPLE: Conflicting Charset and Internal
9.9. application/xml or text/xml with Omitted Charset, no Encoding Declaration . . . . . . . . . . . . . . . . . . 20
Internal Encoding Declaration and UTF-8 Entity . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.10. application/xml or text/xml with Omitted Charset and 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Internal Encoding Declaration . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.11. application/xml-external-parsed-entity or text/xml- 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
external-parsed-entity with UTF-8 Charset . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 24
9.12. application/xml-external-parsed-entity with UTF-16 Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? 25
Charset . . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Changes from RFC 3023 . . . . . . . . . . . . . . . 25
9.13. application/xml-external-parsed-entity with UTF-16BE Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Charset . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
9.14. application/xml-dtd . . . . . . . . . . . . . . . . . . . 21
9.15. application/mathml+xml . . . . . . . . . . . . . . . . . 21
9.16. application/xslt+xml . . . . . . . . . . . . . . . . . . 21
9.17. application/rdf+xml . . . . . . . . . . . . . . . . . . . 22
9.18. image/svg+xml . . . . . . . . . . . . . . . . . . . . . . 22
9.19. model/x3d+xml . . . . . . . . . . . . . . . . . . . . . . 22
9.20. INCONSISTENT EXAMPLE: text/xml with UTF-8 Charset . . . . 22
9.21. application/soap+xml . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? 28
Appendix B. Changes from RFC 3023 . . . . . . . . . . . . . . . 28
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The World Wide Web Consortium has issued the Extensible Markup The World Wide Web Consortium has issued the Extensible Markup
Language (XML) 1.0 [XML] and Extensible Markup Language (XML) 1.1 Language (XML) 1.0 [XML] and Extensible Markup Language (XML) 1.1
[XML1.1] specifications. To enable the exchange of XML network [XML1.1] specifications. To enable the exchange of XML network
entities, this specification standardizes three media types -- entities, this specification standardizes three media types --
application/xml, application/xml-external-parsed-entity, and application/xml, application/xml-external-parsed-entity, and
application/xml-dtd and two aliases -- text/xml and text/xml- application/xml-dtd and two aliases -- text/xml and text/xml-
external-parsed-entity, as well as a naming convention for external-parsed-entity, as well as a naming convention for
identifying XML-based MIME media types (using +xml). identifying XML-based MIME media types (using '+xml').
XML has been used as a foundation for other media types, including XML has been used as a foundation for other media types, including
types in every branch of the IETF media types tree. To facilitate types in every branch of the IETF media types tree. To facilitate
the processing of such types, and in line with the recognition in the processing of such types, and in line with the recognition in
[RFC6838] of structured syntax name suffixes, a suffix of '+xml' is [RFC6838] of structured syntax name suffixes, a suffix of '+xml' is
described in Section 8. This will allow generic XML-based tools -- described in Section 8. This will allow generic XML-based tools --
browsers, editors, search engines, and other processors -- to work browsers, editors, search engines, and other processors -- to work
with all XML-based media types. with all XML-based media types.
2. Notational Conventions 2. Notational Conventions
skipping to change at page 7, line 14 skipping to change at page 6, line 40
information. Furthermore, such media types may allow UTF-8 or UTF-16 information. Furthermore, such media types may allow UTF-8 or UTF-16
only and prohibit other charsets. This specification does not only and prohibit other charsets. This specification does not
prohibit such media types and in fact expects them to proliferate. prohibit such media types and in fact expects them to proliferate.
However, developers of such media types are STRONGLY RECOMMENDED to However, developers of such media types are STRONGLY RECOMMENDED to
use this specification as a basis for their registration. In use this specification as a basis for their registration. In
particular, the charset parameter, if used, MUST agree with the in- particular, the charset parameter, if used, MUST agree with the in-
band XML encoding of the XML entity, as described in Section 3.6, in band XML encoding of the XML entity, as described in Section 3.6, in
order to enhance interoperability. order to enhance interoperability.
An XML document labeled as application/xml or text/xml, or with a An XML document labeled as application/xml or text/xml, or with a
+xml media type, might contain namespace declarations, stylesheet- '+xml' media type, might contain namespace declarations, stylesheet-
linking processing instructions (PIs), schema information, or other linking processing instructions (PIs), schema information, or other
declarations that might be used to suggest how the document is to be declarations that might be used to suggest how the document is to be
processed. For example, a document might have the XHTML namespace processed. For example, a document might have the XHTML namespace
and a reference to a CSS stylesheet. Such a document might be and a reference to a CSS stylesheet. Such a document might be
handled by applications that would use this information to dispatch handled by applications that would use this information to dispatch
the document for appropriate processing. the document for appropriate processing.
3.1. Application/xml Registration 3.1. Application/xml Registration
MIME media type name: application Type name: application
Subtype name: xml
MIME subtype name: xml
Mandatory parameters: none Required parameters: none
Optional parameters: charset Optional parameters: charset
See Section 3.6. See Section 3.6.
Encoding considerations: This media type MAY be encoded as Encoding considerations: This media type MAY be encoded as
appropriate for the charset and the capabilities of the underlying appropriate for the charset and the capabilities of the underlying
MIME transport. For 7-bit transports, data in either UTF-8 or MIME transport. For 7-bit transports, data in either UTF-8 or
UTF-16 MUST be encoded in quoted-printable or base64. For 8-bit UTF-16 MUST be encoded in quoted-printable or base64. For 8-bit
clean transport (e.g., 8BITMIME [RFC6152] ESMTP or NNTP clean transport (e.g., 8BITMIME [RFC6152] ESMTP or NNTP
[RFC3977]), UTF-8 is not encoded, but the UTF-16 family MUST be [RFC3977]), UTF-8 is not encoded, but the UTF-16 family MUST be
encoded in base64. For binary clean transports (e.g., HTTP encoded in base64. For binary clean transports (e.g., HTTP
[RFC2616]), no content-transfer-encoding is necessary. [RFC2616]), no content-transfer-encoding is necessary.
Security considerations: See Section 11. Security considerations: See Section 11.
Interoperability considerations: XML has proven to be interoperable Interoperability considerations: XML has proven to be interoperable
across WebDAV clients and servers, and for import and export from across both generic and task-specific applications and for import
multiple XML authoring tools. For maximum interoperability, and export from multiple XML authoring and editting tools. For
validating processors are recommended. Although non-validating maximum interoperability, validating processors are recommended.
processors may be more efficient, they are not required to handle Although non-validating processors may be more efficient, they are
all features of XML. For further information, see sub-section 2.9 not required to handle all features of XML. For further
"Standalone Document Declaration" and section 5 "Conformance" of information, see sub-section 2.9 "Standalone Document Declaration"
[XML] . and section 5 "Conformance" of [XML] .
Published specification: Extensible Markup Language (XML) 1.0 (Fifth Published specification: Extensible Markup Language (XML) 1.0 (Fifth
Edition) [XML]. Edition) [XML], Extensible Markup Language (XML) 1.1 (Second
Edition) [XML1.1].
Applications which use this media type: XML is device-, platform-, Applications that use this media type: XML is device-, platform-,
and vendor-neutral and is supported by a wide range of Web user and vendor-neutral and is supported by a wide range of generic XML
agents, WebDAV [RFC4918] clients and servers, as well as XML tools (editors, parsers, Web agents, ...) and task-specific
authoring tools. applications.
Additional information: Additional information:
Magic number(s): None. Magic number(s): None.
Although no byte sequences can be counted on to always be Although no byte sequences can be counted on to always be
present, XML MIME entities in ASCII-compatible charsets present, XML MIME entities in ASCII-compatible charsets
(including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C
("<?xml"), and those in UTF-16 often begin with hexadecimal FE ("<?xml"), and those in UTF-16 often begin with hexadecimal FE
FF 00 3C 00 3F 00 78 00 6D 00 6C or FF FE 3C 00 3F 00 78 00 6D FF 00 3C 00 3F 00 78 00 6D 00 6C or FF FE 3C 00 3F 00 78 00 6D
00 6C 00 (the Byte Order Mark (BOM) followed by "<?xml"). For 00 6C 00 (the Byte Order Mark (BOM) followed by "<?xml"). For
more information, see Appendix F of [XML]. more information, see Appendix F of [XML].
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): "TEXT" Macintosh File Type Code(s): "TEXT"
Person and email address for further information: Person and email address for further information: See Authors'
Addresses section
MURATA Makoto (FAMILY Given) <eb2m-mrt@asahi-net.or.jp>
Alexey Melnikov <alexey.melnikov@isode.com>
Chris Lilley <chris@w3.org>
Henry S. Thompson <ht@inf.ed.ac.uk>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The XML specification is a work product of Author: See Authors' Addresses section
the World Wide Web Consortium's XML Working Group, and was edited
by:
Tim Bray <tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
Eve Maler <eve.maler@east.sun.com>
Francois Yergeau <mailto:francois@yergeau.com> Change controller: The XML specification is a work product of the
World Wide Web Consortium's XML Working Group
3.2. Text/xml Registration 3.2. Text/xml Registration
text/xml is an alias for application/xml, as defined in Section 3.1 text/xml is an alias for application/xml, as defined in Section 3.1
above. above.
3.3. Application/xml-external-parsed-entity Registration 3.3. Application/xml-external-parsed-entity Registration
MIME media type name: application Type name: application
MIME subtype name: xml-external-parsed-entity Subtype name: xml-external-parsed-entity
Mandatory parameters: none Required parameters: none
Optional parameters: charset Optional parameters: charset
See Section 3.6. See Section 3.6.
Encoding considerations: Same as application/xml as described in Encoding considerations: Same as application/xml as described in
Section 3.1. Section 3.1.
Security considerations: See Section 11. Security considerations: See Section 11.
skipping to change at page 10, line 14 skipping to change at page 9, line 20
Additional information: Additional information:
Magic number(s): Same as application/xml as described in Magic number(s): Same as application/xml as described in
Section 3.1. Section 3.1.
File extension(s): .xml or .ent File extension(s): .xml or .ent
Macintosh File Type Code(s): "TEXT" Macintosh File Type Code(s): "TEXT"
Person and email address for further information: Same as Person and email address for further information: See Authors'
application/xml as described in Section 3.1. Addresses section.
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Same as application/xml as described in Author: See Authors' Addresses section.
Section 3.1.
Change controller: The XML specification is a work product of the
World Wide Web Consortium's XML Working Group
3.4. Text/xml-external-parsed-entity Registration 3.4. Text/xml-external-parsed-entity Registration
text/xml-external-parsed-entity is an alias for application/xml- text/xml-external-parsed-entity is an alias for application/xml-
external-parsed-entity, as defined in Section 3.3 above. external-parsed-entity, as defined in Section 3.3 above.
3.5. Application/xml-dtd Registration 3.5. Application/xml-dtd Registration
MIME media type name: application Type name: application
MIME subtype name: xml-dtd Subtype name: xml-dtd
Mandatory parameters: none Required parameters: none
Optional parameters: charset Optional parameters: charset
See Section 3.6. See Section 3.6.
Encoding considerations: Same as Section 3.1. Encoding considerations: Same as Section 3.1.
Security considerations: See Section 11. Security considerations: See Section 11.
Interoperability considerations: XML DTDs have proven to be Interoperability considerations: XML DTDs have proven to be
skipping to change at page 11, line 19 skipping to change at page 10, line 26
Additional information: Additional information:
Magic number(s): Same as application/xml as described in Magic number(s): Same as application/xml as described in
Section 3.1. Section 3.1.
File extension(s): .dtd or .mod File extension(s): .dtd or .mod
Macintosh File Type Code(s): "TEXT" Macintosh File Type Code(s): "TEXT"
Person and email address for further information: Same as Person and email address for further information: See Authors'
application/xml as described in Section 3.1. Addresses section.
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Same as application/xml as described in Author: See Authors' Addresses section.
Section 3.1.
3.6. Charset considerations Change controller: The XML specification is a work product of the
World Wide Web Consortium's XML Working Group
[HST: new section pulled from section 3.2] 3.6. Charset considerations
The charset parameter MUST only be used, when the charset is reliably The charset parameter MUST only be used, when the charset is reliably
known and agrees with the in-band XML encoding declaration. This known and agrees with the in-band XML encoding declaration. This
information can be used by non-XML processors to determine information can be used by non-XML processors to determine
authoritatively the charset of the XML MIME entity. The charset authoritatively the charset of the XML MIME entity. The charset
parameter can also be used to provide protocol-specific operations, parameter can also be used to provide protocol-specific operations,
such as charset-based content negotiation in HTTP. such as charset-based content negotiation in HTTP.
"utf-8" [RFC3629] and "utf-16" [RFC2781] are the recommended values, "utf-8" [RFC3629] and "utf-16" [RFC2781] are the recommended values,
representing the UTF-8 and UTF-16 charsets, respectively. These representing the UTF-8 and UTF-16 charsets, respectively. These
skipping to change at page 14, line 39 skipping to change at page 13, line 49
Specifications and recommendations based on or referring to this RFC Specifications and recommendations based on or referring to this RFC
SHOULD indicate any limitations on the particular versions of XML to SHOULD indicate any limitations on the particular versions of XML to
be used. For example, a particular specification might indicate: be used. For example, a particular specification might indicate:
"content MUST be represented using media-type application/xml, and "content MUST be represented using media-type application/xml, and
the document must either (a) carry an xml declaration specifying the document must either (a) carry an xml declaration specifying
version="1.0" or (b) omit the XML declaration, in which case per the version="1.0" or (b) omit the XML declaration, in which case per the
XML recommendation the version defaults to 1.0" XML recommendation the version defaults to 1.0"
8. A Naming Convention for XML-Based Media Types 8. A Naming Convention for XML-Based Media Types
This section supersedes the earlier registration of the '+xml' suffix
[RFC6839].
This specification recommends the use of a naming convention (a This specification recommends the use of a naming convention (a
suffix of '+xml') for identifying XML-based MIME media types, suffix of '+xml') for identifying XML-based MIME media types,
whatever their particular content may represent, in line with the whatever their particular content may represent, in line with the
recognition in [RFC6838] of structured syntax name suffixes. This recognition in [RFC6838] of structured syntax name suffixes. This
allows the use of generic XML processors and technologies on a wide allows the use of generic XML processors and technologies on a wide
variety of different XML document types at a minimum cost, using variety of different XML document types at a minimum cost, using
existing frameworks for media type registration. existing frameworks for media type registration.
When a new media type is introduced for an XML-based format, the name When a new media type is introduced for an XML-based format, the name
of the media type SHOULD end with '+xml'. This convention will allow of the media type SHOULD end with '+xml'. This convention will allow
skipping to change at page 15, line 39 skipping to change at page 15, line 5
XML generic processing is not always appropriate for XML-based media XML generic processing is not always appropriate for XML-based media
types. For example, authors of some such media types may wish that types. For example, authors of some such media types may wish that
the types remain entirely opaque except to applications that are the types remain entirely opaque except to applications that are
specifically designed to deal with that media type. By NOT following specifically designed to deal with that media type. By NOT following
the naming convention '+xml', such media types can avoid XML-generic the naming convention '+xml', such media types can avoid XML-generic
processing. Since generic processing will be useful in many cases, processing. Since generic processing will be useful in many cases,
however -- including in some situations that are difficult to predict however -- including in some situations that are difficult to predict
ahead of time -- those registering media types SHOULD use the '+xml' ahead of time -- those registering media types SHOULD use the '+xml'
convention unless they have a particularly compelling reason not to. convention unless they have a particularly compelling reason not to.
The registration process for these media types is described in The registration process for specific '+xml' media types is described
[RFC6838] and [RFC6839]. The registrar for the IETF tree will in [RFC6838] and [RFC6839]. The registrar for the IETF tree will
encourage new XML-based media type registrations in the IETF tree to encourage new XML-based media type registrations in the IETF tree to
follow this guideline. Registrars for other trees SHOULD follow this follow this guideline. Registrars for other trees SHOULD follow this
convention in order to ensure maximum interoperability of their XML- convention in order to ensure maximum interoperability of their XML-
based documents. Similarly, media subtypes that do not represent XML based documents. Similarly, media subtypes that do not represent XML
MIME entities MUST NOT be allowed to register with a '+xml' suffix. MIME entities MUST NOT be allowed to register with a '+xml' suffix.
*HST: What do we do about the registration of +xml in RFC6839? I
think we need to reproduce it with appropriate changes, as it
currently references 3023, and can be simplified/clarified by
including it here. . .*
8.1. Referencing 8.1. Referencing
Registrations for new XML-based media types under top-level types Registrations for new XML-based media types under top-level types
SHOULD, in specifying the charset parameter and encoding SHOULD, in specifying the charset parameter and encoding
considerations, define them as: "Same as [charset parameter / considerations, define them as: "Same as [charset parameter /
encoding considerations] of application/xml as specified in RFC encoding considerations] of application/xml as specified in RFC
XXXX." XXXX."
The use of the charset parameter is STRONGLY RECOMMENDED, since this The use of the charset parameter is STRONGLY RECOMMENDED, since this
information can be used by XML processors to determine information can be used by XML processors to determine
skipping to change at page 16, line 28 skipping to change at page 15, line 36
"UTF-8 only" or "UTF-8 or UTF-16 only". "UTF-8 only" or "UTF-8 or UTF-16 only".
These registrations SHOULD specify that the XML-based media type These registrations SHOULD specify that the XML-based media type
being registered has all of the security considerations described in being registered has all of the security considerations described in
RFC XXXX plus any additional considerations specific to that media RFC XXXX plus any additional considerations specific to that media
type. type.
These registrations SHOULD also make reference to RFC XXXX in These registrations SHOULD also make reference to RFC XXXX in
specifying magic numbers, base URIs, and use of the BOM. specifying magic numbers, base URIs, and use of the BOM.
When these registrations use the '+xml' convention, they MUST also
make reference to RFC XXXX in specifying fragment identifier syntax
and semantics, and they MAY restrict the syntax to a specified subset
of schemes, except that they MUST NOT disallow barenames or 'element'
scheme pointers. They MAY further require support for other
registered schemes. They also MAY add additional syntax (which MUST
NOT overlap with [XPointerFramework] syntax) together with associated
semantics, and MAY add additional semantics for barename XPointers
which, as provided for in Section 5, will only apply when this
specification does not define an interpretation.
These registrations MAY reference the application/xml registration in These registrations MAY reference the application/xml registration in
RFC XXXX in specifying interoperability considerations, if these RFC XXXX in specifying interoperability considerations, if these
considerations are not overridden by issues specific to that media considerations are not overridden by issues specific to that media
type. type.
9. Examples 8.2. +xml Structured Syntax Suffix Registration
The examples below give the value of the MIME Content-type header and Name: Extensible Markup Language (XML)
the XML declaration (which includes the encoding declaration) inside
the XML MIME entity. For UTF-16 examples, the Byte Order Mark
character is denoted as "{BOM}", and the XML declaration is assumed
to come at the beginning of the XML MIME entity, immediately
following the BOM. Note that other MIME headers may be present, and
the XML MIME entity may contain other data in addition to the XML
declaration; the examples focus on the Content-type header and the
encoding declaration for clarity.
This section is non-normative. In particular, note that all "MUST" +suffix: +xml
language herein reproduces or summarizes the consequences of
normative statement already made above, and have no independent
normative force.
9.1. application/xml or text/xml with Omitted Charset and 8-bit MIME Reference: This specification
entity
Content-type: application/xml or text/xml Encoding considerations: Same as Section 3.1.
<?xml version="1.0" encoding="iso-8859-1"?> Fragment identifier considerations: Registrations which use this
'+xml' convention MUST also make reference to RFC XXXX,
specifically Section 5, in specifying fragment identifier syntax
and semantics, and they MAY restrict the syntax to a specified
subset of schemes, except that they MUST NOT disallow barenames or
'element' scheme pointers. They MAY further require support for
other registered schemes. They also MAY add additional syntax
(which MUST NOT overlap with [XPointerFramework] syntax) together
with associated semantics, and MAY add additional semantics for
barename XPointers which, as provided for in Section 5, will only
apply when this specification does not define an interpretation.
Since the charset parameter is not provided in the Content-Type In practice these constraints imply that for a fragment
header, XML processors MUST treat the "iso-8859-1" encoding as identifier addressed to an instance of a specific "xxx/yyy+xml"
authoritative. XML-unaware MIME processors SHOULD make no type, there are three cases:
assumptions about the charset of the XML MIME entity.
9.2. application/xml or text/xml with Omitted Charset and 16-bit MIME For fragment identifiers matching the syntax defined in
entity Section 5, where the fragment identifier resolves per the
rules specified there, then process as specified there;
Content-type: application/xml or text/xml For fragment identifiers matching the syntax defined in
Section 5, where the fragment identifier does _not_ resolve
per the rules specified there, then process as specified in
"xxx/yyy+xml";
{BOM}<?xml version="1.0" encoding="utf-16"?> For fragment identifiers _not_ matching the syntax defined
in Section 5, then process as specified in "xxx/yyy+xml".
or Interoperability considerations: Same as Section 3.1. See above,
and also Section 3.6, for guidelines on the use of the 'charset'
parameter.
{BOM}<?xml version="1.0"?> Security considerations: See Section 11.
This example shows a 16-bit MIME entity with no charset parameter. Contact: See Authors' Addresses section.
Since the charset parameter is not provided in the Content-Type
header, in this case XML processors MUST treat the "utf-16" encoding
and/or the BOM as authoritative. XML-unaware MIME processors SHOULD
make no assumptions about the charset of the XML MIME entity.
Omitting the charset parameter is NOT RECOMMENDED for application/xml Author: See Authors' Addresses section.
when used with transports other than HTTP or HTTPS---text/xml SHOULD
NOT be used for 16-bit MIME with transports other than HTTP or HTTPS
(see. Section 9.5).
9.3. application/xml or text/xml with UTF-8 Charset Change controller: The XML specification is a work product of the
World Wide Web Consortium's XML Working Group.
Content-type: application/xml or text/xml; charset="utf-8" 9. Examples
The examples below give the charset portion, if any, of the value of
the MIME Content-type header and the XML declaration or Text
declaration (which includes the encoding declaration) inside the XML
MIME entity. For UTF-16 examples, the Byte Order Mark character is
denoted as "{BOM}", and the XML or Text declaration is assumed to
come at the beginning of the XML MIME entity, immediately following
the BOM. Note that other MIME headers may be present, and the XML
MIME entity may contain other data in addition to the XML
declaration; the examples focus on the Content-type header and the
encoding declaration for clarity.
All the examples below apply to all five media types declared above
in Section 3, as well as to any media types declared using the '+xml'
convention. See the XML MIME entities table (Section 3, Paragraph 2)
for discussion of which types are appropriate for which varieties of
XML MIME entities.
This section is non-normative. In particular, note that all "MUST"
language herein reproduces or summarizes the consequences of
normative statement already made above, and have no independent
normative force.
9.1. UTF-8 Charset
Content-type charset: charset="utf-8"
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
This is the recommended encoding for use with all the media types This is the recommended encoding for use with all the media types
defined in this specification. Since the charset parameter is defined in this specification. Since the charset parameter is
provided, both MIME and XML processors MUST treat the enclosed entity provided, both MIME and XML processors MUST treat the enclosed entity
as UTF-8 encoded. as UTF-8 encoded.
If sent using a 7-bit transport (e.g. SMTP [RFC5321]), the XML MIME If sent using a 7-bit transport (e.g. SMTP [RFC5321]), the XML MIME
entity MUST use a content-transfer-encoding of either quoted- entity MUST use a content-transfer-encoding of either quoted-
printable or base64. For an 8-bit clean transport (e.g., 8BITMIME printable or base64. For an 8-bit clean transport (e.g., 8BITMIME
ESMTP or NNTP), or a binary clean transport (e.g., HTTP), no content- ESMTP or NNTP), or a binary clean transport (e.g., HTTP), no content-
transfer-encoding is necessary. transfer-encoding is necessary.
skipping to change at page 18, line 15 skipping to change at page 17, line 38
defined in this specification. Since the charset parameter is defined in this specification. Since the charset parameter is
provided, both MIME and XML processors MUST treat the enclosed entity provided, both MIME and XML processors MUST treat the enclosed entity
as UTF-8 encoded. as UTF-8 encoded.
If sent using a 7-bit transport (e.g. SMTP [RFC5321]), the XML MIME If sent using a 7-bit transport (e.g. SMTP [RFC5321]), the XML MIME
entity MUST use a content-transfer-encoding of either quoted- entity MUST use a content-transfer-encoding of either quoted-
printable or base64. For an 8-bit clean transport (e.g., 8BITMIME printable or base64. For an 8-bit clean transport (e.g., 8BITMIME
ESMTP or NNTP), or a binary clean transport (e.g., HTTP), no content- ESMTP or NNTP), or a binary clean transport (e.g., HTTP), no content-
transfer-encoding is necessary. transfer-encoding is necessary.
9.4. application/xml with UTF-16 Charset 9.2. UTF-16 Charset
Content-type: application/xml; charset="utf-16" Content-type charset: charset="utf-16"
{BOM}<?xml version="1.0" encoding="utf-16"?> {BOM}<?xml version="1.0" encoding="utf-16"?>
or or
{BOM}<?xml version="1.0"?> {BOM}<?xml version="1.0"?>
For application... cases, if sent using a 7-bit transport (e.g.,
If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean SMTP) or an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP), the
transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be XML MIME entity MUST be encoded in quoted-printable or base64; for a
encoded in quoted-printable or base64. For a binary clean transport binary clean transport (e.g., HTTP), no content-transfer-encoding is
(e.g., HTTP), no content-transfer-encoding is necessary.
9.5. text/xml with UTF-16 Charset
Content-type: text/xml; charset="utf-16"
{BOM}<?xml version='1.0' encoding='utf-16'?>
or
{BOM}<?xml version='1.0'?>
This is possible only when the XML MIME entity is transmitted via
HTTP or HTTPS, which use a MIME-like mechanism and are binary-clean
protocols, hence do not perform CR and LF transformations and allow
NUL octets. As described in [RFC2781], the UTF-16 family MUST NOT be
used with media types under the top-level type "text" except over
HTTP or HTTPS (see section 19.4.1 of [RFC2616] for details).
Since HTTP is binary clean, no content-transfer-encoding is
necessary. necessary.
9.6. application/xml with UTF-16BE Charset As described in [RFC2781], the UTF-16 family MUST NOT be used with
Content-type: application/xml; charset="utf-16be" media types under the top-level type "text" except over HTTP or HTTPS
(see section 19.4.1 of [RFC2616] for details). Hence this example is
only possible in text/... cases when the XML MIME entity is
transmitted via HTTP or HTTPS, which use a MIME-like mechanism and
are binary-clean protocols, hence do not perform CR and LF
transformations and allow NUL octets. Since HTTP is binary clean, no
content-transfer-encoding is necessary.
<?xml version='1.0' encoding='utf-16be'?> 9.3. Omitted Charset and 8-bit MIME entity
Observe that the BOM does not exist. Since the charset parameter is Content-type charset: [none]
provided, MIME and XML processors MUST treat the enclosed entity as
UTF-16BE encoded.
9.7. text/xml with UTF-16BE Charset <?xml version="1.0" encoding="iso-8859-1"?>
Content-type: text/xml; charset="utf-16be" Since the charset parameter is not provided in the Content-Type
header, XML processors MUST treat the "iso-8859-1" encoding as
authoritative. XML-unaware MIME processors SHOULD make no
assumptions about the charset of the XML MIME entity.
<?xml version='1.0' encoding='utf-16be'?> 9.4. Omitted Charset and 16-bit MIME entity
Observe that the BOM does not exist. As for UTF-16, this is possible Content-type charset: [none]
only when the XML MIME entity is transmitted via HTTP.
9.8. application/xml or text/xml with ISO-2022-KR Charset {BOM}<?xml version="1.0" encoding="utf-16"?>
Content-type: application/xml; charset="iso-2022-kr" or
<?xml version="1.0" encoding="iso-2022-kr"?> {BOM}<?xml version="1.0"?>
This example shows the use of a Korean charset (e.g., Hangul) encoded This example shows a 16-bit MIME entity with no charset parameter.
following the specification in [RFC1557]. Since the charset Since the charset parameter is not provided in the Content-Type
parameter is provided, MIME processors MUST treat the enclosed entity header, in this case XML processors MUST treat the "utf-16" encoding
as encoded per RFC 1557. Since the XML MIME entity has an internal and/or the BOM as authoritative. XML-unaware MIME processors SHOULD
encoding declaration (this example does show such a declaration, make no assumptions about the charset of the XML MIME entity.
which agrees with the charset parameter) XML processors MUST also
treat the enclosed entity as encoded per RFC 1557. Thus,
interoperability is assured.
Since ISO-2022-KR has been defined to use only 7 bits of data, no Omitting the charset parameter is NOT RECOMMENDED for application/...
content-transfer-encoding is necessary with any transport. when used with transports other than HTTP or HTTPS---text/... SHOULD
NOT be used for 16-bit MIME with transports other than HTTP or HTTPS
(see discussion above (Section 9.2, Paragraph 6)).
9.9. application/xml or text/xml with Omitted Charset, no Internal 9.5. Omitted Charset, no Internal Encoding Declaration and UTF-8 Entity
Encoding Declaration and UTF-8 Entity
Content-type: application/xml or text/xml Content-type charset: [none]
<?xml version='1.0'?> <?xml version='1.0'?>
In this example, the charset parameter has been omitted, the is no In this example, the charset parameter has been omitted, the is no
internal encoding declaration, and there is no BOM. Since there is internal encoding declaration, and there is no BOM. Since there is
no BOM, the XML processor follows the requirements in section 4.3.3, no BOM, the XML processor follows the requirements in section 4.3.3,
and optionally applies the mechanism described in Appendix F (which and optionally applies the mechanism described in Appendix F (which
is non-normative) of [XML] to determine the charset encoding of is non-normative) of [XML] to determine the charset encoding of
UTF-8. Although the XML MIME entity does not contain an encoding UTF-8. Although the XML MIME entity does not contain an encoding
declaration, the encoding actually _is_ UTF-8, so this is still a declaration, the encoding actually _is_ UTF-8, so this is still a
conforming XML MIME entity. conforming XML MIME entity.
An XML-unaware MIME processor SHOULD make no assumptions about the An XML-unaware MIME processor SHOULD make no assumptions about the
charset of the XML MIME entity. charset of the XML MIME entity.
9.10. application/xml or text/xml with Omitted Charset and Internal See Section 9.1 for transport-related issues for UTF-8 XML MIME
Encoding Declaration entities.
Content-type: application/xml or text/xml
<?xml version='1.0' encoding="iso-10646-ucs-4"?>
In this example, the charset parameter has been omitted, and there is
no BOM. However, the XML MIME entity does have an encoding
declaration inside the XML MIME entity that specifies the entity's
charset. Following the requirements in section 4.3.3, and optionally
applying the mechanism described in Appendix F (non-normative) of
[XML], the XML processor determines the charset encoding of the XML
MIME entity (in this example, UCS-4).
An XML-unaware MIME processor SHOULD make no assumptions about the
charset of the XML MIME entity.
9.11. application/xml-external-parsed-entity or text/xml-external-
parsed-entity with UTF-8 Charset
Content-type: text/xml-external-parsed-entity or application/xml-
external-parsed-entity; charset="utf-8"
<?xml encoding="utf-8"?>
Since the charset parameter is provided, MIME and XML processors MUST
treat the enclosed entity as UTF-8 encoded.
If sent using a 7-bit transport (e.g. SMTP), the XML MIME entity
MUST use a content-transfer-encoding of either quoted-printable or
base64. For an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP),
or a binary clean transport (e.g., HTTP) no content-transfer-encoding
is necessary.
9.12. application/xml-external-parsed-entity with UTF-16 Charset
Content-type: application/xml-external-parsed-entity;
charset="utf-16"
{BOM}<?xml encoding="utf-16"?>
or
{BOM}<?xml?>
Since the charset parameter is provided, MIME and XML processors MUST
treat the enclosed entity as UTF-16 encoded.
If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean
transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be
encoded in quoted-printable or base64. For a binary clean transport
(e.g., HTTP), no content-transfer-encoding is necessary.
9.13. application/xml-external-parsed-entity with UTF-16BE Charset
Content-type: application/xml-external-parsed-entity; charset="utf-
16be"
<?xml encoding="utf-16be"?>
Since the charset parameter is provided, MIME and XML processors MUST
treat the enclosed entity as UTF-16BE encoded.
9.14. application/xml-dtd
Content-type: application/xml-dtd; charset="utf-8"
<?xml encoding="utf-8"?>
Charset "utf-8" is a recommended charset value for use with
application/xml-dtd. Since the charset parameter is provided, MIME
and XML processors MUST treat the enclosed entity as UTF-8 encoded.
9.15. application/mathml+xml
Content-type: application/mathml+xml
<?xml version="1.0" ?> 9.6. UTF-16BE Charset
MathML documents are XML documents whose content describes Content-type charset: charset="utf-16be"
mathematical information, as defined by [MathML]. As a format based
on XML, MathML documents SHOULD follow the '+xml' suffix convention
and use 'mathml+xml' in their MIME content-type identifier.This media
type has been registered at IANA and is fully defined in [MathML].
9.16. application/xslt+xml <?xml version='1.0' encoding='utf-16be'?>
Content-type: application/xslt+xml Observe that the BOM does not exist. Since the charset parameter is
<?xml version="1.0" ?> provided, MIME and XML processors MUST treat the enclosed entity as
UTF-16BE encoded.
Extensible Stylesheet Language (XSLT) documents are XML documents See also the additional considerations in the UTF-16 example
whose content describes stylesheets for other XML documents, as (Section 9.2) above.
defined by [XSLT]. As a format based on XML, XSLT documents SHOULD
follow the '+xml' suffix convention and use 'xslt+xml' in their MIME
content-type identifier.This media type has been registered at IANA
and is fully defined in [XSLT].
9.17. application/rdf+xml 9.7. Non-UTF Charset
Content-type: application/rdf+xml Content-type charset: charset="iso-2022-kr"
<?xml version="1.0" ?> <?xml version="1.0" encoding="iso-2022-kr"?>
Resources identified using the application/rdf+xml media type are XML This example shows the use of a non-UTF charset (in this case Hangul,
documents whose content describe RDF metadata. This media type has but this example is intended to cover all non-UTF-family charsets).
been registered at IANA and is fully defined in [RFC3870]. Since the charset parameter is provided, MIME processors MUST treat
the enclosed entity as encoded per RFC 1557. Since the XML MIME
entity has an internal encoding declaration (this example does show
such a declaration, which agrees with the charset parameter) XML
processors MUST also treat the enclosed entity as encoded per RFC
1557. Thus, interoperability is assured.
9.18. image/svg+xml Since ISO-2022-KR [RFC1557] has been defined to use only 7 bits of
data, no content-transfer-encoding is necessary with any transport:
for charsets needing 8 or more bits, considerations such as those
discussed above (Section 9.1, Section 9.2) would apply.
Content-type: image/svg+xml 9.8. Omitted Charset with Internal Encoding Declaration
<?xml version="1.0" ?> Content-type charset: [none]
Scalable Vector Graphics (SVG) documents are XML documents whose <?xml version='1.0' encoding="iso-10646-ucs-4"?>
content describes graphical information, as defined by [SVG]. As a
format based on XML, SVG documents SHOULD follow the '+xml' suffix
convention and use 'svg+xml' in their MIME content-type
identifier.The image/svg+xml media type has been registered at IANA
and is fully defined in [SVG]. .
9.19. model/x3d+xml In this example, the charset parameter has been omitted, and there is
no BOM. However, the XML MIME entity does have an encoding
declaration inside the XML MIME entity that specifies the entity's
charset. Following the requirements in section 4.3.3, and optionally
applying the mechanism described in Appendix F (non-normative) of
[XML], the XML processor determines the charset encoding of the XML
MIME entity (in this example, UCS-4).
Content-type: model/x3d+xml An XML-unaware MIME processor SHOULD make no assumptions about the
charset of the XML MIME entity.
<?xml version="1.0" ?> For charsets needing 8 or more bits, considerations such as those
discussed above (Section 9.1, Section 9.2) would apply
X3D is derived from VRML and is used for 3D models. Besides the XML 9.9. INCONSISTENT EXAMPLE: Conflicting Charset and Internal Encoding
representation, it may also be serialised in classic VRML syntax and Declaration
using a fast infoset. Separate, but clearly related media types are
used for these serialisations (model/x3d+vrml and model/
x3d+fastinfoset respectively).
9.20. INCONSISTENT EXAMPLE: text/xml with UTF-8 Charset Content-type charset: charset="utf-8"
Content-type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version="1.0" encoding="iso-8859-1"?>
Since the charset parameter is provided in the Content-Type header Since the charset parameter is provided in the Content-Type header
and differs from the XML encoding declaration , MIME and XML and differs from the XML encoding declaration, MIME and XML
processors will not interoperate. MIME processors will treat the processors will not interoperate. MIME processors will treat the
enclosed entity as UTF-8 encoded. That is, the "iso-8859-1" encoding enclosed entity as UTF-8 encoded. That is, the "iso-8859-1" encoding
will be be ignored. XML processors on the other hand will ignore the will be ignored. XML processors on the other hand will ignore the
charset parameter and treat the XML entity as encoded in iso-8859-1. charset parameter and treat the XML entity as encoded in iso-8859-1.
Processors generating XML MIME entities MUST NOT label conflicting Processors generating XML MIME entities MUST NOT label conflicting
charset information between the MIME Content-Type and the XML charset information between the MIME Content-Type and the XML
declaration. In particular, the addition of an explicit, site-wide declaration. In particular, the addition of an explicit, site-wide
charset without inspecting the XML MIME entity has frequently lead to charset without inspecting the XML MIME entity has frequently lead to
interoperability problems. interoperability problems.
9.21. application/soap+xml
Content-type: application/soap+xml
<?xml version="1.0" ?>
Resources identified using the application/soap+xml media type are
SOAP 1.2 message envelopes that have been serialized with XML 1.0.
This media type has been registered at IANA and is fully defined in
[RFC3902].
10. IANA Considerations 10. IANA Considerations
As described in Section 8, this specification updates the [RFC6838] As described in Section 8, this specification updates the [RFC6838]
and [RFC6839] registration process for XML-based MIME types. and [RFC6839] registration process for XML-based MIME types.
11. Security Considerations 11. Security Considerations
XML MIME entities contain information which may be parsed and further XML MIME entities contain information which may be parsed and further
processed by the recipient's XML system. These entities may contain processed by the recipient's XML system. These entities may contain
and such systems may permit explicit system level commands to be and such systems may permit explicit system level commands to be
executed while processing the data. To the extent that an XML system executed while processing the data. To the extent that an XML system
will execute arbitrary command strings, recipients of XML MIME will execute arbitrary command strings, recipients of XML MIME
skipping to change at page 25, line 26 skipping to change at page 23, line 4
Note that it is also possible to construct XML documents that make Note that it is also possible to construct XML documents that make
use of what XML terms "[XML-]entity references" to construct repeated use of what XML terms "[XML-]entity references" to construct repeated
expansions of text. Recursive expansions are prohibited by [XML] and expansions of text. Recursive expansions are prohibited by [XML] and
XML processors are required to detect them. However, even non- XML processors are required to detect them. However, even non-
recursive expansions may cause problems with the finite computing recursive expansions may cause problems with the finite computing
resources of computers, if they are performed many times. (XML- resources of computers, if they are performed many times. (XML-
entity A consists of 100 copies of XML-entity B, which in turn entity A consists of 100 copies of XML-entity B, which in turn
consists of 100 copies of XML-entity C, and so on) consists of 100 copies of XML-entity C, and so on)
12. References 12. References
12.1. Normative References 12.1. Normative References
[ASCII] , "US-ASCII. Coded Character Set -- 7-Bit American
Standard Code for Information Interchange", ANSI
X3.4-1986, 1986.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. 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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, Februrary 2000. 10646", RFC 2781, February 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003.
[RFC3977] Feather, B., "Network News Transfer Protocol", RFC 3977,
October 2006.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax.", RFC 3986, Resource Identifiers (URI): Generic Syntax.", RFC 3986,
January 2005. January 2005.
[RFC3987] DUeerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Dueerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, July 2005. Identifiers (IRIs)", RFC 3987, July 2005.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
Service Extension for 8-bit MIME Transport", RFC 6152,
March 2011.
[RFC6657] Melnikov, A. and J. Reschke, "Update to MIME regarding [RFC6657] Melnikov, A. and J. Reschke, "Update to MIME regarding
"charset" Parameter Handling in Textual Media Types", RFC "charset" Parameter Handling in Textual Media Types", RFC
6657, July 2012, 6657, July 2012,
<http://www.rfc-editor.org/rfc/rfc6657.txt>. <http://www.rfc-editor.org/rfc/rfc6657.txt>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013. 6838, January 2013.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839, January 2013. Structured Syntax Suffixes", RFC 6839, January 2013.
[XBase] Marsh, J. and R. Tobin, "XML Base", World Wide Web [XBase] Marsh, J. and R. Tobin, "XML Base", World Wide Web
Consortium Recommendation xmlbase, January 2009, Consortium Recommendation xmlbase, January 2009,
<http://www.w3.org/TR/xmlbase>. <http://www.w3.org/TR/xmlbase>.
[XML1.1] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E., [XML1.1] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,
Yergeau, F., and J. Cowan, "Extensible Markup Language Yergeau, F., and J. Cowan, "Extensible Markup Language
(XML) 1.1", World Wide Web Consortium Recommendation REC- (XML) 1.1 (Second Edition)", World Wide Web Consortium
xml, September 2006, <http://www.w3.org/TR/xml11>. Recommendation REC-xml, September 2006,
<http://www.w3.org/TR/xml11>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E., [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0 and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Fifth Edition)", World Wide Web Consortium Recommendation (Fifth Edition)", World Wide Web Consortium Recommendation
REC-xml, November 2008, <http://www.w3.org/TR/REC-xml>. REC-xml, November 2008, <http://www.w3.org/TR/REC-xml>.
[XPointerElement] [XPointerElement]
Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer
element() Scheme", World Wide Web Consortium element() Scheme", World Wide Web Consortium
Recommendation REC-XPointer-Element, March 2003, Recommendation REC-XPointer-Element, March 2003,
skipping to change at page 27, line 16 skipping to change at page 24, line 27
Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer
Framework", World Wide Web Consortium Recommendation REC- Framework", World Wide Web Consortium Recommendation REC-
XPointer-Framework, March 2003, XPointer-Framework, March 2003,
<http://www.w3.org/TR/xptr-framework/>. <http://www.w3.org/TR/xptr-framework/>.
[XPtrReg] Hazael-Massieux, D., "XPointer Registry", 2005, [XPtrReg] Hazael-Massieux, D., "XPointer Registry", 2005,
<http://www.w3.org/2005/04/xpointer-schemes/>. <http://www.w3.org/2005/04/xpointer-schemes/>.
12.2. Informative References 12.2. Informative References
[ASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[CSS] Bos, B., Lie, H.W., Lilley, C., and I. Jacobs, "Cascading [CSS] Bos, B., Lie, H.W., Lilley, C., and I. Jacobs, "Cascading
Style Sheets, level 2 (CSS2) Specification", World Wide Style Sheets, level 2 (CSS2) Specification", World Wide
Web Consortium Recommendation REC-CSS2, May 1998, Web Consortium Recommendation REC-CSS2, May 1998,
<http://www.w3.org/TR/REC-CSS2/>. <http://www.w3.org/TR/REC-CSS2/>.
[HTTPbis] Fielding, R., "Hypertext Transfer Protocol -- HTTP/1.2?", [HTTPbis] Fielding, R., "Hypertext Transfer Protocol (HTTP/1.1)
RFC ???, January 2013. [revised]", ietf-httpbis-p1-messaging (work in progress),
February 2013.
[ISO8859] , "ISO-8859. International Standard -- Information [ISO8859] ISO, "ISO-8859. International Standard -- Information
Processing -- 8-bit Single-Byte Coded Graphic Character Processing -- 8-bit Single-Byte Coded Graphic Character
Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987", Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987",
1987. 1987.
[MathML] Carlisle, D., Ion, P., and R. Miner, "Mathematical Markup
Language (MathML) Version 3.0", World Wide Web Consortium
Recommendation MathML, October 2010,
<http://www.w3.org/TR/MathML/>.
[RFC1557] Choi, U., Chon, K., and H. Park, "Korean Character [RFC1557] Choi, U., Chon, K., and H. Park, "Korean Character
Encoding for Internet Messages", RFC 1557, December 1993. Encoding for Internet Messages", RFC 1557, December 1993.
[RFC2130] Weider, C., Cecilia Preston, C., Simonsen, K., Alvestrand, [RFC2130] Weider, C., Cecilia Preston, C., Simonsen, K., Alvestrand,
H., Atkinson, R., Crispin, M., and P. Svanberg, "The H., Atkinson, R., Crispin, M., and P. Svanberg, "The
Report of the IAB Character Set Workshop held 29 February Report of the IAB Character Set Workshop held 29 February
- 1 March, 1996", RFC 2130, April 1997. - 1 March, 1996", RFC 2130, April 1997.
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, [RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
July 1998. July 1998.
[RFC2703] Klyne, G., "Protocol-independent Content Negotiation [RFC2703] Klyne, G., "Protocol-independent Content Negotiation
Framework", RFC 2703, September 1999. Framework", RFC 2703, September 1999.
[RFC3023] Murata, M., St.Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St.Laurent, S., and D. Kohn, "XML Media
Types", January 2001. Types", January 2001.
[RFC3870] 3870, A., "application/rdf+xml Media Type Registration", [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
RFC 3870, September 2004. 10646", RFC 3629, November 2003.
[RFC3902] Baker, M. and M. Nottingham, "The "application/soap+xml"
media type", RFC 3902, September 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC3977] Feather, B., "Network News Transfer Protocol", RFC 3977,
Registration Procedures", RFC 4288, December 2005. October 2006.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", RFC Extensions (MIME) Part Four: Registration Procedures", RFC
4289, December 2005. 4289, December 2005.
[RFC4918] Dusseault, L., "HTTP Extensions for Distributed Authoring [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
-- WEBDAV", RFC 4918, June 2007. October 2008.
[SVG] Dahlstroem, E. and others. , "Scalable Vector Graphics [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
(SVG) 1.1 Specification (Second edition)", World Wide Web Service Extension for 8-bit MIME Transport", RFC 6152,
Consortium Recommendation SVG, August 2011, March 2011.
<http://www.w3.org/TR/SVG/>.
[TAGMIME] Bray, T., Ed., "Internet Media Type registration, [TAGMIME] Bray, T., Ed., "Internet Media Type registration,
consistency of use", April 2004, consistency of use", April 2004,
<http://www.w3.org/2001/tag/2004/0430-mime>. <http://www.w3.org/2001/tag/2004/0430-mime>.
[XHTML] Pemberton, S. and et al, "XHTML 1.0: The Extensible [XHTML] Pemberton, S. and et al, "XHTML 1.0: The Extensible
HyperText Markup Language", World Wide Web Consortium HyperText Markup Language", World Wide Web Consortium
Recommendation xhtml1, December 1999, Recommendation xhtml1, December 1999,
<http://www.w3.org/TR/xhtml1>. <http://www.w3.org/TR/xhtml1>.
[XSLT] Kay, M., "XSL Transformations (XSLT) Version 2.0", World
Wide Web Consortium Recommendation xslt20, January 2007,
<http://www.w3.org/TR/xslt20/>.
Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types?
[RFC3023] contains a detailed discussion of the (at the time) novel [RFC3023] contains a detailed discussion of the (at the time) novel
use of a suffix, a practice which has since become widespread. use of a suffix, a practice which has since become widespread.
Interested parties are referred to [RFC3023], Appendix A. Interested parties are referred to [RFC3023], Appendix A.
Appendix B. Changes from RFC 3023 Appendix B. Changes from RFC 3023
There are numerous and significant differences between this There are numerous and significant differences between this
specification and [RFC3023], which it obsoletes. This appendix specification and [RFC3023], which it obsoletes. This appendix
 End of changes. 108 change blocks. 
395 lines changed or deleted 250 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/