draft-ietf-appsawg-xml-mediatypes-04.txt   draft-ietf-appsawg-xml-mediatypes-05.txt 
Network Working Group H. S. Thompson Network Working Group H. S. Thompson
Internet-Draft University of Edinburgh Internet-Draft University of Edinburgh
Obsoletes: 3023 (if approved) C. Lilley Obsoletes: 3023 (if approved) C. Lilley
Updates: 6839 (if approved) W3C Updates: 6839 (if approved) W3C
Intended status: Standards Track November 04, 2013 Intended status: Standards Track November 19, 2013
Expires: May 08, 2014 Expires: May 23, 2014
XML Media Types XML Media Types
draft-ietf-appsawg-xml-mediatypes-04 draft-ietf-appsawg-xml-mediatypes-05
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 the '+xml' suffix for types. This specification also standardizes the '+xml' suffix for
naming media types outside of these five types when those media types naming media types outside of these five types when those media types
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 May 08, 2014. This Internet-Draft will expire on May 23, 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 23 skipping to change at page 2, line 23
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . . 4 3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Application/xml Registration . . . . . . . . . . . . . . 5 3.1. Application/xml Registration . . . . . . . . . . . . . . 5
3.2. Text/xml Registration . . . . . . . . . . . . . . . . . . 7 3.2. Text/xml Registration . . . . . . . . . . . . . . . . . . 7
3.3. Application/xml-external-parsed-entity Registration . . . 7 3.3. Application/xml-external-parsed-entity Registration . . . 7
3.4. Text/xml-external-parsed-entity Registration . . . . . . 8 3.4. Text/xml-external-parsed-entity Registration . . . . . . 8
3.5. Application/xml-dtd Registration . . . . . . . . . . . . 8 3.5. Application/xml-dtd Registration . . . . . . . . . . . . 8
3.6. Charset considerations . . . . . . . . . . . . . . . . . 9 3.6. Charset considerations . . . . . . . . . . . . . . . . . 9
4. The Byte Order Mark (BOM) and Charset Conversions . . . . . . 11 4. The Byte Order Mark (BOM) and Charset Conversions . . . . . . 11
5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 12 5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 12
6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 12 6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 13
7. XML Versions . . . . . . . . . . . . . . . . . . . . . . . . 13 7. XML Versions . . . . . . . . . . . . . . . . . . . . . . . . 13
8. A Naming Convention for XML-Based Media Types . . . . . . . . 14 8. A Naming Convention for XML-Based Media Types . . . . . . . . 14
8.1. Referencing . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Referencing . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. +xml Structured Syntax Suffix Registration . . . . . . . 15 8.2. +xml Structured Syntax Suffix Registration . . . . . . . 16
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. UTF-8 Charset . . . . . . . . . . . . . . . . . . . . . . 17 9.1. UTF-8 Charset . . . . . . . . . . . . . . . . . . . . . . 17
9.2. UTF-16 Charset . . . . . . . . . . . . . . . . . . . . . 18 9.2. UTF-16 Charset . . . . . . . . . . . . . . . . . . . . . 18
9.3. Omitted Charset and 8-bit MIME entity . . . . . . . . . . 18 9.3. Omitted Charset and 8-bit MIME entity . . . . . . . . . . 18
9.4. Omitted Charset and 16-bit MIME entity . . . . . . . . . 18 9.4. Omitted Charset and 16-bit MIME entity . . . . . . . . . 18
9.5. Omitted Charset, no Internal Encoding Declaration and 9.5. Omitted Charset, no Internal Encoding Declaration and
UTF-8 Entity . . . . . . . . . . . . . . . . . . . . . . 19 UTF-8 Entity . . . . . . . . . . . . . . . . . . . . . . 19
9.6. UTF-16BE Charset . . . . . . . . . . . . . . . . . . . . 19 9.6. UTF-16BE Charset . . . . . . . . . . . . . . . . . . . . 19
9.7. Non-UTF Charset . . . . . . . . . . . . . . . . . . . . . 20 9.7. Non-UTF Charset . . . . . . . . . . . . . . . . . . . . . 20
9.8. Omitted Charset with Internal Encoding Declaration . . . 20 9.8. Omitted Charset with Internal Encoding Declaration . . . 20
9.9. INCONSISTENT EXAMPLE: Conflicting Charset and Internal 9.9. INCONSISTENT EXAMPLE: Conflicting Charset and Internal
Encoding Declaration . . . . . . . . . . . . . . . . . . 20 Encoding Declaration . . . . . . . . . . . . . . . . . . 20
9.10. INCONSISTENT EXAMPLE: Conflicting Charset and BOM . . . . 21 9.10. INCONSISTENT EXAMPLE: Conflicting Charset and BOM . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? 26 Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? 26
Appendix B. Changes from RFC 3023 . . . . . . . . . . . . . . . 26 Appendix B. Changes from RFC 3023 . . . . . . . . . . . . . . . 26
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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-
skipping to change at page 6, line 18 skipping to change at page 6, line 18
Optional parameters: charset Optional parameters: charset
See Section 3.6. See Section 3.6.
Encoding considerations: Depending on the charset encoding used, XML Encoding considerations: Depending on the charset encoding used, XML
MIME entities can consist of 7bit, 8bit or binary data [RFC6838]. MIME entities can consist of 7bit, 8bit or binary data [RFC6838].
For 7-bit transports, 7bit data, for example data with charset For 7-bit transports, 7bit data, for example data with charset
encoding US-ASCII, does not require content-transfer-encoding, but encoding US-ASCII, does not require content-transfer-encoding, but
8bit or binary data, for example data with charset encoding UTF-8 8bit or binary data, for example data with charset encoding UTF-8
or UTF-16, MUST be content-transfer-encoded in quoted-printable or or UTF-16, MUST be content-transfer-encoded in quoted-printable or
base64. For 8-bit clean transport (e.g. 8BITMIME [RFC6152], base64. For 8-bit clean transport (e.g. 8BITMIME ESMTP [RFC6152]
ESMTP or NNTP [RFC3977]), 7bit or 8bit data, for example data with or NNTP [RFC3977]), 7bit or 8bit data, for example data with
charset encoding UTF-8 or US-ASCII, does not require content- charset encoding UTF-8 or US-ASCII, does not require content-
transfer-encoding, but binary data, for example data with a transfer-encoding, but binary data, for example data with a
charset encoding from the UTF-16 family, MUST be content-transfer- charset encoding from the UTF-16 family, MUST be content-transfer-
encoded in base64. For binary clean transports (e.g. HTTP encoded in base64. For binary clean transports (e.g. BINARY
[RFC2616]), no content-transfer-encoding is necessary (or even ESMTP [RFC3030] or HTTP [HTTPbis]), no content-transfer-encoding
possible, in the case of HTTP) for 7bit, 8bit or binary data. is necessary (or even possible, in the case of HTTP) for 7bit,
8bit or binary data.
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 both generic and task-specific applications and for import across both generic and task-specific applications and for import
and export from multiple XML authoring and editing tools. and export from multiple XML authoring and editing tools.
Validating processors provide maximum interoperability. Although Validating processors provide maximum interoperability. Although
non-validating processors may be more efficient, they are not non-validating processors may be more efficient, they are not
required to handle all features of XML. For further information, required to handle all features of XML. For further information,
see sub-section 2.9 "Standalone Document Declaration" and section see sub-section 2.9 "Standalone Document Declaration" and section
skipping to change at page 7, line 24 skipping to change at page 7, line 27
Base URI: See Section 6 Base URI: See Section 6
Person and email address for further information: See Authors' Person and email address for further information: See Authors'
Addresses section Addresses section
Intended usage: COMMON Intended usage: COMMON
Author: See Authors' Addresses section Author: See Authors' Addresses section
Change controller: The XML specification is a work product of the Change controller: The XML specification is a work product of the
World Wide Web Consortium's XML Core Working Group World Wide Web Consortium's XML Core Working Group. The W3C has
change control over this specification.
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
Type name: application Type name: application
skipping to change at page 8, line 36 skipping to change at page 8, line 41
Base URI: See Section 6 Base URI: See Section 6
Person and email address for further information: See Authors' Person and email address for further information: See Authors'
Addresses section. Addresses section.
Intended usage: COMMON Intended usage: COMMON
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: The XML specification is a work product of the Change controller: The XML specification is a work product of the
World Wide Web Consortium's XML Core Working Group World Wide Web Consortium's XML Core Working Group. The W3C has
change control over this specification.
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
Type name: application Type name: application
Subtype name: xml-dtd Subtype name: xml-dtd
Required 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
interoperable by DTD authoring tools and XML validators, among interoperable by DTD authoring tools and XML validators, among
others. others.
skipping to change at page 9, line 39 skipping to change at page 9, line 45
Macintosh File Type Code(s): "TEXT" Macintosh File Type Code(s): "TEXT"
Person and email address for further information: See Authors' Person and email address for further information: See Authors'
Addresses section. Addresses section.
Intended usage: COMMON Intended usage: COMMON
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: The XML specification is a work product of the Change controller: The XML specification is a work product of the
World Wide Web Consortium's XML Working Core Group World Wide Web Consortium's XML Core Working Group. The W3C has
change control over this specification.
3.6. Charset considerations 3.6. Charset considerations
As many as three distinct sources of information about character As many as three distinct sources of information about character
encoding may be present for an XML MIME entity: a charset parameter, encoding may be present for an XML MIME entity: a charset parameter,
a Byte Order Mark (BOM -- see Section 4 below) and an XML encoding a Byte Order Mark (BOM -- see Section 4 below) and an XML encoding
declaration (see Section 4.3.3 of [XML]). Ensuring consistency among declaration (see Section 4.3.3 of [XML]). Ensuring consistency among
these sources requires coordination between entity authors and MIME these sources requires coordination between entity authors and MIME
agents (that is, processes which package, transfer, deliver and/or agents (that is, processes which package, transfer, deliver and/or
receive MIME entities). Some MIME agents will be what we will call receive MIME entities). Some MIME agents will be what we will call
skipping to change at page 10, line 42 skipping to change at page 10, line 49
declaration or both, or none, the normative component of the [XML] declaration or both, or none, the normative component of the [XML]
specification leaves the question open as to how to determine the specification leaves the question open as to how to determine the
encoding with which to attempt to process the entity. In particular, encoding with which to attempt to process the entity. In particular,
in the case where there is in-band information and it conflicts with in the case where there is in-band information and it conflicts with
the charset parameter, the [XML] specification does not specify which the charset parameter, the [XML] specification does not specify which
should be taken to be authoritative. In its (non-normative) should be taken to be authoritative. In its (non-normative)
Appendix F it defers to this specification: Appendix F it defers to this specification:
[T]he preferred method of handling conflict should be specified as [T]he preferred method of handling conflict should be specified as
part of the higher-level protocol used to deliver XML. In part of the higher-level protocol used to deliver XML. In
particular, please refer to [IETF RFC 3023] or its successor particular, please refer to [IETF RFC 3023] or its successor...
Accordingly, to conform with deployed processors and content and to Accordingly, to conform with deployed processors and content and to
avoid conflicting with this or other normative specifications, this avoid conflicting with this or other normative specifications, this
specification sets the priority as follows: specification sets the priority as follows:
All consumers SHOULD treat a BOM (Section 4) as authoritative if it All consumers SHOULD treat a BOM (Section 4) as authoritative if it
is present in an XML MIME entity. In the absence of a BOM is present in an XML MIME entity. In the absence of a BOM
(Section 4), all consumers SHOULD treat the charset parameter as (Section 4), all consumers SHOULD treat the charset parameter as
authoritative if it is present. For XML-aware consumers, note that authoritative if it is present. For XML-aware consumers, note that
Section 4.3.3 of the [XML] specification does _not_ make it an error Section 4.3.3 of the [XML] specification does _not_ make it an error
skipping to change at page 11, line 27 skipping to change at page 11, line 36
MIME Content-Type header. XML-aware processors MUST follow the MIME Content-Type header. XML-aware processors MUST follow the
requirements in section 4.3.3 of [XML] that directly address this requirements in section 4.3.3 of [XML] that directly address this
case. XML-unaware MIME processors SHOULD NOT assume a default case. XML-unaware MIME processors SHOULD NOT assume a default
charset in this case. charset in this case.
4. The Byte Order Mark (BOM) and Charset Conversions 4. The Byte Order Mark (BOM) and Charset Conversions
Section 4.3.3 of [XML] specifies that XML MIME entities in the Section 4.3.3 of [XML] specifies that XML MIME entities in the
charset "utf-16" MUST begin with a byte order mark (BOM), which is a charset "utf-16" MUST begin with a byte order mark (BOM), which is a
hexadecimal octet sequence 0xFE 0xFF (or 0xFF 0xFE, depending on hexadecimal octet sequence 0xFE 0xFF (or 0xFF 0xFE, depending on
endian). The XML Recommendation further states that the BOM is an endianness). The XML Recommendation further states that the BOM is
encoding signature, and is not part of either the markup or the an encoding signature, and is not part of either the markup or the
character data of the XML document. character data of the XML document.
Due to the presence of the BOM, applications that convert XML from Due to the presence of the BOM, applications that convert XML from
"utf-16" to an encoding other than "utf-8" MUST strip the BOM before "utf-16" to an encoding other than "utf-8" MUST strip the BOM before
conversion. Similarly, when converting from another encoding into conversion. Similarly, when converting from another encoding into
"utf-16", the BOM MUST be added after conversion is complete unless "utf-16", the BOM MUST be added after conversion is complete unless
the original encoding was "utf-8" and a BOM was already present, in the original encoding was "utf-8" and a BOM was already present, in
which case it will have been transcoded into a "utf-16" BOM already. which case it will have been transcoded into a "utf-16" BOM already.
Section 4.3.3 of [XML] also allows for XML MIME entities in the Section 4.3.3 of [XML] also allows for XML MIME entities in the
skipping to change at page 12, line 13 skipping to change at page 12, line 22
prohibited for these character sets. When an XML MIME entity is prohibited for these character sets. When an XML MIME entity is
encoded in "utf-16le" or "utf-16be", it MUST NOT begin with the BOM encoded in "utf-16le" or "utf-16be", it MUST NOT begin with the BOM
but SHOULD contain an in-band XML encoding declaration. Conversion but SHOULD contain an in-band XML encoding declaration. Conversion
from "utf-16"or "utf-8" to "utf-16be" or "utf-16le" and conversion in from "utf-16"or "utf-8" to "utf-16be" or "utf-16le" and conversion in
the other direction MUST strip or add the appropriate BOM, the other direction MUST strip or add the appropriate BOM,
respectively. respectively.
5. Fragment Identifiers 5. Fragment Identifiers
Uniform Resource Identifiers (URIs) can contain fragment identifiers Uniform Resource Identifiers (URIs) can contain fragment identifiers
(see Section 3.5 of [RFC3986]).Specifying the syntax and semantics of (see Section 3.5 of [RFC3986]). Specifying the syntax and semantics
fragment identifiers is devolved by [RFC3986] to the appropriate of fragment identifiers is devolved by [RFC3986] to the appropriate
media type registration. media type registration.
The syntax and semantics of fragment identifiers for the XML media The syntax and semantics of fragment identifiers for the XML media
types defined in this specification are based on the types defined in this specification are based on the
[XPointerFramework] W3C Recommendation. It allows simple names, and [XPointerFramework] W3C Recommendation. It allows simple names, and
more complex constructions based on named schemes. When the syntax more complex constructions based on named schemes. When the syntax
of a fragment identifier part of any URI or IRI with a retrieved of a fragment identifier part of any URI or IRI with a retrieved
media type governed by this specification conforms to the syntax media type governed by this specification conforms to the syntax
specified in [XPointerFramework], conforming applications MUST specified in [XPointerFramework], conforming applications MUST
interpret such fragment identifiers as designating whatever is interpret such fragment identifiers as designating whatever is
skipping to change at page 15, line 18 skipping to change at page 15, line 23
there is some particularly compelling reason not to. there is some particularly compelling reason not to.
The registration process for specific '+xml' media types is described The registration process for specific '+xml' media types is described
in [RFC6838]. The registrar for the IETF tree will encourage new in [RFC6838]. The registrar for the IETF tree will encourage new
XML-based media type registrations in the IETF tree to follow this XML-based media type registrations in the IETF tree to follow this
guideline. Registrars for other trees SHOULD follow this convention guideline. Registrars for other trees SHOULD follow this convention
in order to ensure maximum interoperability of their XML-based in order to ensure maximum interoperability of their XML-based
documents. Similarly, media subtypes that do not represent XML MIME documents. Similarly, media subtypes that do not represent XML MIME
entities MUST NOT be allowed to register with a '+xml' suffix. entities MUST NOT be allowed to register with a '+xml' suffix.
In addition to the changes described above, the change controller has
been changed to be the World Wide Web Consortium (W3C).
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."
Enabling the charset parameter is RECOMMENDED, since this information Enabling the charset parameter is RECOMMENDED, since this information
can be used by XML processors to determine authoritatively the can be used by XML processors to determine authoritatively the
skipping to change at page 16, line 36 skipping to change at page 16, line 43
per the rules specified there, then process as specified per the rules specified there, then process as specified
there; there;
For fragment identifiers matching the syntax defined in For fragment identifiers matching the syntax defined in
[XPointerFramework], where the fragment identifier does [XPointerFramework], where the fragment identifier does
_not_ resolve per the rules specified there, then process as _not_ resolve per the rules specified there, then process as
specified in "xxx/yyy+xml"; specified in "xxx/yyy+xml";
For fragment identifiers _not_ matching the syntax defined For fragment identifiers _not_ matching the syntax defined
in [XPointerFramework], then process as specified in "xxx/ in [XPointerFramework], then process as specified in "xxx/
yyy+xml".A fragment identifier of the form yyy+xml". A fragment identifier of the form
"xywh=160,120,320,240", as defined in [MediaFrags], which "xywh=160,120,320,240", as defined in [MediaFrags], which
might be used in a URI for an XML-encoded image, would fall might be used in a URI for an XML-encoded image, would fall
in this category. in this category.
Interoperability considerations: Same as Section 3.1. See above, Interoperability considerations: Same as Section 3.1. See above,
and also Section 3.6, for guidelines on the use of the 'charset' and also Section 3.6, for guidelines on the use of the 'charset'
parameter. parameter.
Security considerations: See Section 11. Security considerations: See Section 11.
Contact: See Authors' Addresses section. Contact: See Authors' Addresses section.
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: The XML specification is a work product of the Change controller: The XML specification is a work product of the
World Wide Web Consortium's XML WorkingCore Group. World Wide Web Consortium's XML Core Working Group. The W3C has
change control over this specification.
9. Examples 9. Examples
The examples below give the charset portion, if any, of the value of The examples below give the charset portion, if any, of the value of
the MIME Content-type header and the XML declaration or Text the MIME Content-type header and the XML declaration or Text
declaration (which includes the encoding declaration) inside the XML declaration (which includes the encoding declaration) inside the XML
MIME entity. For UTF-16 examples, the Byte Order Mark character MIME entity. For UTF-16 examples, the Byte Order Mark character
appropriately UTF-16-encoded is denoted as "{BOM}", and the XML or appropriately UTF-16-encoded is denoted as "{BOM}", and the XML or
Text declaration is assumed to come at the beginning of the XML MIME Text declaration is assumed to come at the beginning of the XML MIME
entity, immediately following the encoded BOM. Note that other MIME entity, immediately following the encoded BOM. Note that other MIME
skipping to change at page 17, line 47 skipping to change at page 18, line 7
<?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 and there is no BOM, both MIME and XML processors must treat provided and there is no BOM, both MIME and XML processors must treat
the enclosed entity as UTF-8 encoded. the enclosed entity 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. BINARY ESMTP or
transfer-encoding is necessary (or even possible, in the case of HTTP), no content-transfer-encoding is necessary (or even possible,
HTTP). in the case of HTTP).
9.2. UTF-16 Charset 9.2. UTF-16 Charset
Content-type charset: 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. For application/... cases, if sent using a 7-bit transport (e.g.
SMTP) or an 8-bit clean transport (e.g. 8BITMIME, ESMTP or NNTP), SMTP) or an 8-bit clean transport (e.g. 8BITMIME ESMTP or NNTP), the
the XML MIME entity must be encoded in quoted-printable or base64; XML MIME entity must be encoded in quoted-printable or base64; for a
for a binary clean transport (e.g. HTTP), no content-transfer- binary clean transport (e.g. BINARY ESMTP or HTTP), no content-
encoding is necessary (or even possible, in the case of HTTP). transfer-encoding is necessary (or even possible, in the case of
HTTP).
As described in [RFC2781], the UTF-16 family must not be used with 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 media types under the top-level type "text" except over HTTP or HTTPS
(see section 19.4.2 of [RFC2616] for details). Hence this example is (see section A.2 of HTTP [HTTPbis] for details). Hence this example
only possible in text/... cases when the XML MIME entity is is only possible in text/... cases when the XML MIME entity is
transmitted via HTTP or HTTPS, which use a MIME-like mechanism and transmitted via HTTP or HTTPS, which use a MIME-like mechanism and
are binary-clean protocols, hence do not perform CR and LF are binary-clean protocols, hence do not perform CR and LF
transformations and allow NUL octets. Since HTTP is binary clean, no transformations and allow NUL octets. Since HTTP is binary clean, no
content-transfer-encoding is necessary (or even possible). content-transfer-encoding is necessary (or even possible).
9.3. Omitted Charset and 8-bit MIME entity 9.3. Omitted Charset and 8-bit MIME entity
Content-type charset: [none] Content-type charset: [none]
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version="1.0" encoding="iso-8859-1"?>
skipping to change at page 23, line 32 skipping to change at page 23, line 32
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. For resources of computers, if they are performed many times. For
example, consider the case where XML-entity A consists of 100 copies example, consider the case where XML-entity A consists of 100 copies
of XML-entity B, which in turn consists of 100 copies of XML-entity of XML-entity B, which in turn consists of 100 copies of XML-entity
C, and so on. C, and so on.
12. References 12. References
12.1. Normative References 12.1. Normative References
[HTTPbis] Fielding, R., "Hypertext Transfer Protocol (HTTP/1.1)
[revised]", ietf-httpbis-p2-semantics (work in progress),
September 2013.
[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.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
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, February 2000. 10646", RFC 2781, February 2000.
[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
Identifiers (IRIs)", RFC 3987, July 2005.
[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
skipping to change at page 25, line 27 skipping to change at page 25, line 23
[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 [ASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[HTTPbis] Fielding, R., "Hypertext Transfer Protocol (HTTP/1.1)
[revised]", ietf-httpbis-p2-semantics (work in progress),
September 2013.
[ISO8859] ISO, "ISO-8859. International Standard -- Information
Processing -- 8-bit Single-Byte Coded Graphic Character
Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987",
1987.
[MediaFrags] [MediaFrags]
Troncy, R., Mannens, E., Pfeiffer, S., and D. Van Deursen, Troncy, R., Mannens, E., Pfeiffer, S., and D. Van Deursen,
"Media Fragments URI 1.0 (basic)", W3C Recommendation "Media Fragments URI 1.0 (basic)", W3C Recommendation
media-frags, September 2012, media-frags, September 2012,
<http://www.w3.org/TR/2012/REC-media-frags-20120925/>. <http://www.w3.org/TR/2012/REC-media-frags-20120925/>.
Latest version available at Latest version available at
[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,
H., Atkinson, R., Crispin, M., and P. Svanberg, "The
Report of the IAB Character Set Workshop held 29 February
- 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 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Framework", RFC 2703, September 1999. Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission
10646", RFC 3629, November 2003. of Large and Binary MIME Messages", RFC 3030, 2000.
[RFC3977] Feather, B., "Network News Transfer Protocol", RFC 3977, [RFC3977] Feather, B., "Network News Transfer Protocol", RFC 3977,
October 2006. October 2006.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
Service Extension for 8-bit MIME Transport", RFC 6152, Service Extension for 8-bit MIME Transport", RFC 6152,
March 2011. March 2011.
skipping to change at page 26, line 44 skipping to change at page 26, line 26
<http://www.w3.org/TR/2000/REC-xhtml1-20000126/>. <http://www.w3.org/TR/2000/REC-xhtml1-20000126/>.
Latest version available at Latest version available at
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.
The registration process for new '+xml' media types is described in
[RFC6838]
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
summarizes the major differences only. summarizes the major differences only.
First, XPointer ([XPointerFramework] and [XPointerElement]) has been First, XPointer ([XPointerFramework] and [XPointerElement]) has been
added as fragment identifier syntax for "application/xml", and the added as fragment identifier syntax for "application/xml", and the
XPointer Registry ([XPtrReg]) mentioned. Second, [XMLBase] has been XPointer Registry ([XPtrReg]) mentioned. Second, [XMLBase] has been
added as a mechanism for specifying base URIs. Third, the language added as a mechanism for specifying base URIs. Third, the language
regarding character sets was updated to correspond to the W3C TAG regarding character sets was updated to correspond to the W3C TAG
finding Internet Media Type registration, consistency of use finding Internet Media Type registration, consistency of use
[TAGMIME]. Fourth, many references are updated, and the existence of [TAGMIME]. Fourth, many references are updated, and the existence of
and relevance of the spec. to XML 1.1 acknowledged. Finally, a XML 1.1 and relevance of this specification to it acknowledged.
number of justifications and contextualizations which were Finally, a number of justifications and contextualizations which were
appropriate when XML was new have been removed, including the whole appropriate when XML was new have been removed, including the whole
of the original Appendix A. of the original Appendix A.
Appendix C. Acknowledgements Appendix C. Acknowledgements
MURATA Makoto (FAMILY Given) and Alexey Melnikov made early and MURATA Makoto (FAMILY Given) and Alexey Melnikov made early and
important contributions to the effort to revise [RFC3023]. important contributions to the effort to revise [RFC3023].
This specification reflects the input of numerous participants to the This specification reflects the input of numerous participants to the
ietf-xml-mime@imc.org, xml-mime@ietf.org and apps-discuss@ietf.org ietf-xml-mime@imc.org, xml-mime@ietf.org and apps-discuss@ietf.org
 End of changes. 31 change blocks. 
60 lines changed or deleted 56 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/