--- 1/draft-ietf-appsawg-xml-mediatypes-08.txt 2014-03-03 02:14:46.145282211 -0800 +++ 2/draft-ietf-appsawg-xml-mediatypes-09.txt 2014-03-03 02:14:46.213283873 -0800 @@ -1,20 +1,20 @@ Network Working Group H. Thompson Internet-Draft University of Edinburgh Obsoletes: 3023 (if approved) C. Lilley Updates: 6839 (if approved) W3C -Intended status: Standards Track February 23, 2014 -Expires: August 27, 2014 +Intended status: Standards Track March 02, 2014 +Expires: September 3, 2014 XML Media Types - draft-ietf-appsawg-xml-mediatypes-08 + draft-ietf-appsawg-xml-mediatypes-09 Abstract This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 27, 2014. + This Internet-Draft will expire on September 3, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -69,73 +69,74 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 2.1. Conformance Keywords . . . . . . . . . . . . . . . . . . 4 2.2. Characters, Encodings, Charsets . . . . . . . . . . . . . 4 2.3. MIME Entities, XML Entities . . . . . . . . . . . . . . . 4 3. Encoding Considerations . . . . . . . . . . . . . . . . . . . 5 3.1. XML MIME producers . . . . . . . . . . . . . . . . . . . 6 3.2. XML MIME consumers . . . . . . . . . . . . . . . . . . . 6 3.3. The Byte Order Mark (BOM) and Encoding Conversions . . . 7 4. XML Media Types . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. XML MIME Entities . . . . . . . . . . . . . . . . . . . . 9 - 4.2. Application/xml Registration . . . . . . . . . . . . . . 10 - 4.3. Text/xml Registration . . . . . . . . . . . . . . . . . . 12 - 4.4. Application/xml-external-parsed-entity Registration . . . 12 - 4.5. Text/xml-external-parsed-entity Registration . . . . . . 13 - 4.6. Application/xml-dtd Registration . . . . . . . . . . . . 13 - 5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 14 - 6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7. XML Versions . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8. The '+xml' Naming Convention for XML-Based Media Types . . . 16 - 8.1. +xml Structured Syntax Suffix Registration . . . . . . . 16 - 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 9.1. UTF-8 Charset . . . . . . . . . . . . . . . . . . . . . . 18 - 9.2. UTF-16 Charset . . . . . . . . . . . . . . . . . . . . . 18 - 9.3. Omitted Charset and 8-bit MIME Entity . . . . . . . . . . 19 - 9.4. Omitted Charset and 16-bit MIME Entity . . . . . . . . . 19 - 9.5. Omitted Charset, no Internal Encoding Declaration . . . . 20 - 9.6. UTF-16BE Charset . . . . . . . . . . . . . . . . . . . . 20 - 9.7. Non-UTF Charset . . . . . . . . . . . . . . . . . . . . . 20 - 9.8. INCONSISTENT EXAMPLE: Conflicting Charset and Internal - Encoding Declaration . . . . . . . . . . . . . . . . . . 21 - 9.9. INCONSISTENT EXAMPLE: Conflicting Charset and BOM . . . . 21 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 10.1. Using '+xml' when Registering XML-based Media Types . . 22 - 10.2. Registration Guidelines for XML-based Media Types Not - Using '+xml' . . . . . . . . . . . . . . . . . . . . . . 23 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 - 12.2. Informative References . . . . . . . . . . . . . . . . . 28 + 4.1. XML MIME Entities . . . . . . . . . . . . . . . . . . . . 8 + 4.2. Using '+xml' when Registering XML-based Media Types . . . 10 + 4.3. Registration Guidelines for XML-based Media Types Not + Using '+xml' . . . . . . . . . . . . . . . . . . . . . . 11 + 5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 12 + 6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7. XML Versions . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. UTF-8 Charset . . . . . . . . . . . . . . . . . . . . . . 14 + 8.2. UTF-16 Charset . . . . . . . . . . . . . . . . . . . . . 15 + 8.3. Omitted Charset and 8-bit MIME Entity . . . . . . . . . . 15 + 8.4. Omitted Charset and 16-bit MIME Entity . . . . . . . . . 15 + 8.5. Omitted Charset, no Internal Encoding Declaration . . . . 16 + 8.6. UTF-16BE Charset . . . . . . . . . . . . . . . . . . . . 16 + 8.7. Non-UTF Charset . . . . . . . . . . . . . . . . . . . . . 17 + 8.8. INCONSISTENT EXAMPLE: Conflicting Charset and Internal + Encoding Declaration . . . . . . . . . . . . . . . . . . 17 + 8.9. INCONSISTENT EXAMPLE: Conflicting Charset and BOM . . . . 17 + + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 9.1. Application/xml Registration . . . . . . . . . . . . . . 18 + 9.2. Text/xml Registration . . . . . . . . . . . . . . . . . . 19 + 9.3. Application/xml-external-parsed-entity Registration . . . 20 + 9.4. Text/xml-external-parsed-entity Registration . . . . . . 21 + 9.5. Application/xml-dtd Registration . . . . . . . . . . . . 21 + 9.6. The '+xml' Naming Convention for XML-Based Media Types . 22 + 9.6.1. +xml Structured Syntax Suffix Registration . . . . . 22 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 + 11.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? 30 Appendix B. Core XML specifications . . . . . . . . . . . . . . 30 - Appendix C. Changes from RFC 3023 . . . . . . . . . . . . . . . 31 + Appendix C. Changes from RFC 3023 . . . . . . . . . . . . . . . 30 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 31 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction The World Wide Web Consortium has issued the Extensible Markup Language (XML) 1.0 [XML] and Extensible Markup Language (XML) 1.1 [XML1.1] specifications. To enable the exchange of XML network entities, this specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd and two aliases -- text/xml and text/xml- external-parsed-entity, as well as a naming convention for identifying XML-based MIME media types (using '+xml'). XML has been used as a foundation for other media types, including types in every branch of the IETF media types tree. To facilitate the processing of such types, and in line with the recognition in [RFC6838] of structured syntax name suffixes, a suffix of '+xml' is - described in Section 8. This will allow generic XML-based tools -- - browsers, editors, search engines, and other processors -- to work + registered in Section 9.6. This will allow generic XML-based tools + -- browsers, editors, search engines, and other processors -- to work with all XML-based media types. This specification replaces [RFC3023]. Major differences are in the areas of alignment of text/xml and text/xml-external-parsed-entity with application/xml and application/xml-external-parsed-entity respectively, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, integration of the XPointer Registry and updating of many references. 2. Notational Conventions @@ -362,34 +363,30 @@ specification recommends against the use of UTF-32, but if it is used, the same considerations apply with respect to its being a signature, not part of the document, with respect to transcoding into or out of it and with respect to the MIME charsets "utf-32le" and "utf-32be", as for UTF-16. Consumers which do not support UTF-32 SHOULD none-the-less recognise UTF-32 signatures in order to give helpful error messages (instead of treating them as invalid UTF-16). 4. XML Media Types - Registration information for media types for use with XML MIME - entities is described in the sections below, after some relevant - background information about XML itself. - 4.1. XML MIME Entities Within the XML specification, XML MIME entities can be classified into four types. In the XML terminology, they are called "document entities", "external DTD subsets", "external parsed entities", and "external parameter entities". Appropriate usage for the types registered below is as follows: document entities: The media types application/xml or text/xml, or a - more specific media type (see Section 8), SHOULD be used. + more specific media type (see Section 9.6), SHOULD be used. external DTD subsets: The media type application/xml-dtd SHOULD be used. The media types application/xml and text/xml MUST NOT be used. external parsed entities: The media types application/xml-external- parsed-entity or text/xml-external-parsed-entity SHOULD be used. The media types application/xml and text/xml MUST NOT be used unless the parsed entities are also well-formed "document entities". @@ -435,224 +432,121 @@ which results. XML provides a general framework for defining sequences of structured data. It is often appropriate to define new media types that use XML but define a specific application of XML, due to domain-specific display, editing, security considerations or runtime information. Furthermore, such media types may allow only UTF-8 and/or UTF-16 and prohibit other character sets. This specification does not prohibit such media types and in fact expects them to proliferate. However, developers of such media types are RECOMMENDED to use this - specification as a basis for their registration. See Section 8 for + specification as a basis for their registration. See Section 4.2 for more detailed recommendations on using the '+xml' suffix for registration of such media types. An XML document labeled as application/xml or text/xml, or with a '+xml' media type, might contain namespace declarations, stylesheet- linking processing instructions (PIs), schema information, or other declarations that might be used to suggest how the document is to be processed. For example, a document might have the XHTML namespace and a reference to a CSS stylesheet. Such a document might be handled by applications that would use this information to dispatch the document for appropriate processing. Appendix B lists the core XML specifications which, taken together with [XML] itself, show how to determine an XML document's language-level semantics and suggest how information about its application-level semantics may be locatable. -4.2. Application/xml Registration - - Type name: application - - Subtype name: xml - - Required parameters: none - - Optional parameters: charset - See Section 3. - - Encoding considerations: Depending on the character encoding used, - XML MIME entities can consist of 7bit, 8bit or binary data - [RFC6838]. For 7-bit transports, 7bit data, for example US-ASCII- - encoded data, does not require content-transfer-encoding, but 8bit - or binary data, for example UTF-8 or UTF-16 data, MUST be content- - transfer-encoded in quoted-printable or base64. For 8-bit clean - transport (e.g. 8BITMIME ESMTP [RFC6152] or NNTP [RFC3977]), 7bit - or 8bit data, for example US-ASCII or UTF-8 data, does not require - content-transfer-encoding, but binary data, for example data with - a UTF-16 encoding, MUST be content-transfer-encoded in base64. - For binary clean transports (e.g. BINARY ESMTP [RFC3030] or HTTP - [HTTPbis]), no content-transfer-encoding is necessary (or even - possible, in the case of HTTP) for 7bit, 8bit or binary data. - - Security considerations: See Section 11. - - Interoperability considerations: XML has proven to be interoperable - across both generic and task-specific applications and for import - and export from multiple XML authoring and editing tools. - Validating processors provide maximum interoperability. Although - non-validating processors may be more efficient, they are not - required to handle all features of XML. For further information, - see sub-section 2.9 "Standalone Document Declaration" and section - 5 "Conformance" of [XML] . - - In practice, character set issues have proved to be the biggest - source of interoperability problems. The use of UTF-8, and - careful attention to the guidelines set out in Section 3, are the - best way to avoid such problems. - - Published specification: Extensible Markup Language (XML) 1.0 (Fifth - Edition) [XML] or subsequent editions or versions thereof. - - Applications that use this media type: XML is device-, platform-, - and vendor-neutral and is supported by generic and task-specific - applications and a wide range of generic XML tools (editors, - parsers, Web agents, ...). - - Additional information: - - Magic number(s): None. - - Although no byte sequences can be counted on to always be - present, XML MIME entities in ASCII-compatible character sets - (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C - (" or UTF-8 is the recommended encoding for use with all the media types @@ -838,25 +659,26 @@ provided and there is no overriding BOM, conformant MIME and XML processors must treat the enclosed entity as UTF-8 encoded. If sent using a 7-bit transport (e.g. SMTP [RFC5321]), in general, a UTF-8 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. BINARY ESMTP or HTTP), no content-transfer-encoding is necessary (or even possible, in the case of HTTP). -9.2. UTF-16 Charset +8.2. UTF-16 Charset Content-Type: application/xml; charset=utf-16 {BOM} + or {BOM} For the three application/ media types defined above, 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. BINARY ESMTP or HTTP), no content-transfer-encoding is necessary (or even possible, in the case of HTTP). @@ -864,104 +686,104 @@ 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 A.2 of HTTP [HTTPbis] for details). Hence one of the two text/ media types defined above can be used with this exampleonly 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 (or even possible). -9.3. Omitted Charset and 8-bit MIME Entity +8.3. Omitted Charset and 8-bit MIME Entity Content-Type: application/xml Since the charset parameter is not provided in the Content-Type header and there is no overriding BOM, conformant XML processors must treat the "iso-8859-1" encoding as authoritative. Conformant XML- unaware MIME processors should make no assumptions about the character encoding of the XML MIME entity. -9.4. Omitted Charset and 16-bit MIME Entity +8.4. Omitted Charset and 16-bit MIME Entity Content-Type: application/xml {BOM} or {BOM} - This example shows a 16-bit MIME entity with no charset parameter. However since there is a BOM conformant processors must treat the entity as UTF-16-encoded. Omitting the charset parameter is not recommended in conjunction with media types under the top-level type "application" when used with transports other than HTTP or HTTPS. Media types under the top-level type "text" should not be used for 16-bit MIME with transports other - than HTTP or HTTPS (see discussion above (Section 9.2, Paragraph 7)). + than HTTP or HTTPS (see discussion above (Section 8.2, Paragraph 7)). -9.5. Omitted Charset, no Internal Encoding Declaration +8.5. Omitted Charset, no Internal Encoding Declaration Content-Type: application/xml In this example, the charset parameter has been omitted, there is no internal encoding declaration, and there is no BOM. Since there is no BOM or charset parameter, the XML processor follows the requirements in section 4.3.3, and optionally applies the mechanism described in Appendix F (which is non-normative) of [XML] to determine an encoding of UTF-8. Although the XML MIME entity does not contain an encoding declaration, provided the encoding actually _is_ UTF-8, this is a conforming XML MIME entity. A conformant XML-unaware MIME processor should make no assumptions about the character encoding of the XML MIME entity. - See Section 9.1 for transport-related issues for UTF-8 XML MIME + See Section 8.1 for transport-related issues for UTF-8 XML MIME entities. -9.6. UTF-16BE Charset +8.6. UTF-16BE Charset Content-Type: application/xml; charset=utf-16be Observe that, as required for this encoding, there is no BOM. Since the charset parameter is provided and there is no overriding BOM, conformant MIME and XML processors must treat the enclosed entity as UTF-16BE encoded. See also the additional considerations in the UTF-16 example - (Section 9.2) above. + (Section 8.2) above. -9.7. Non-UTF Charset +8.7. Non-UTF Charset Content-Type: application/xml; charset=iso-2022-kr + This example shows the use of a non-UTF character encoding (in this case Hangul, but this example is intended to cover all non-UTF-family character encodings). Since the charset parameter is provided and there is no overriding BOM, conformant processors must treat the enclosed entity as encoded per RFC 1557. 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 character sets needing 8 or more bits, considerations such as - those discussed above (Section 9.1, Section 9.2) would apply. + those discussed above (Section 8.1, Section 8.2) would apply. -9.8. INCONSISTENT EXAMPLE: Conflicting Charset and Internal Encoding +8.8. INCONSISTENT EXAMPLE: Conflicting Charset and Internal Encoding Declaration Content-Type: application/xml; charset=iso-8859-1 Although the charset parameter is provided in the Content-Type header and there is no BOM and the charset parameter differs from the XML encoding declaration, conformant MIME and XML processors will interoperate. Since the charset parameter is authoritative in the @@ -970,152 +792,328 @@ declaration will be ignored. Conformant processors generating XML MIME entities must not label conflicting character encoding information between the MIME Content- Type and the XML declaration unless they have definitive information about the actual encoding, for example as a result of systematic transcoding. In particular, the addition by servers of an explicit, site-wide charset parameter default has frequently lead to interoperability problems for XML documents. -9.9. INCONSISTENT EXAMPLE: Conflicting Charset and BOM +8.9. INCONSISTENT EXAMPLE: Conflicting Charset and BOM Content-Type: application/xml; charset=iso-8859-1 {BOM} Although the charset parameter is provided in the Content-Type header, there is a BOM, so MIME and XML processors may not interoperate. Since the BOM parameter is authoritative for conformant XML processors, they will treat the enclosed entity as UTF-16-encoded. That is, the "iso-8859-1" charset parameter will be ignored. XML-unaware MIME processors on the other hand may be unaware of the BOM and so treat the entity as encoded in iso-8859-1. Conformant processors generating XML MIME entities must not label conflicting character encoding information between the MIME Content- Type and an entity-initial BOM. -10. IANA Considerations +9. IANA Considerations - As described in Section 8, this specification updates the [RFC6839] - registration for XML-based MIME types (the '+xml' types). +9.1. Application/xml Registration -10.1. Using '+xml' when Registering XML-based Media Types + Type name: application - When a new media type is introduced for an XML-based format, the name - of the media type SHOULD end with '+xml' unless generic XML - processing is in some way inappropriate for documents of the new - type. This convention will allow applications that can process XML - generically to detect that the MIME entity is supposed to be an XML - document, verify this assumption by invoking some XML processor, and - then process the XML document accordingly. Applications may check - for types that represent XML MIME entities by comparing the last four - characters of the subtype to the string '+xml'. (However note that 4 - of the 5 media types defined in this specification -- text/xml, - application/xml, text/xml-external-parsed-entity, and application/ - xml-external-parsed-entity -- also represent XML MIME entities while - not ending with '+xml'.) + Subtype name: xml - NOTE: Section 5.3.2 of HTTPbis [HTTPbis] does not support any form - of Accept header which will match only '+xml' types. In - particular, Accept headers of the form "Accept: */*+xml" are not - allowed, and so this header MUST NOT be used for this purpose. + Required parameters: none - Media types following the naming convention '+xml' SHOULD introduce - the charset parameter for consistency, since XML-generic processing - applies the same program for any such media type. However, there are - some cases that the charset parameter need not be introduced. For - example: + Optional parameters: charset - When an XML-based media type is restricted to UTF-8, it is not - necessary to introduce the charset parameter. UTF-8 is the - default for XML. + See Section 3. - When an XML-based media type is restricted to UTF-8 and UTF-16, it - might not be unreasonable to omit the charset parameter. Neither - UTF-8 nor UTF-16 require XML encoding declarations. + Encoding considerations: Depending on the character encoding used, + XML MIME entities can consist of 7bit, 8bit or binary data + [RFC6838]. For 7-bit transports, 7bit data, for example US-ASCII- + encoded data, does not require content-transfer-encoding, but 8bit + or binary data, for example UTF-8 or UTF-16 data, MUST be content- + transfer-encoded in quoted-printable or base64. For 8-bit clean + transport (e.g. 8BITMIME ESMTP [RFC6152] or NNTP [RFC3977]), 7bit + or 8bit data, for example US-ASCII or UTF-8 data, does not require + content-transfer-encoding, but binary data, for example data with + a UTF-16 encoding, MUST be content-transfer-encoded in base64. + For binary clean transports (e.g. BINARY ESMTP [RFC3030] or HTTP + [HTTPbis]), no content-transfer-encoding is necessary (or even + possible, in the case of HTTP) for 7bit, 8bit or binary data. - XML generic processing is not always appropriate for XML-based media - types. For example, authors of some such media types may wish that - the types remain entirely opaque except to applications that are - specifically designed to deal with that media type. By NOT following - the naming convention '+xml', such media types can avoid XML-generic - processing. Since generic processing will be useful in many cases, - however -- including in some situations that are difficult to predict - ahead of time -- the '+xml' convention is to be preferred unless - there is some particularly compelling reason not to. + Security considerations: See Section 10. - The registration process for specific '+xml' media types is described - in [RFC6838]. The registrar for the IETF tree will encourage new - XML-based media type registrations in the IETF tree to follow this - guideline. Registrars for other trees SHOULD follow this convention - in order to ensure maximum interoperability of their XML-based - documents. Only media subtypes that represent XML MIME entities are - allowed to register with a '+xml' suffix. + Interoperability considerations: XML has proven to be interoperable + across both generic and task-specific applications and for import + and export from multiple XML authoring and editing tools. + Validating processors provide maximum interoperability, because + they have to handle all aspects of XML. Although a non-validating + processor may be more efficient, it might not handle all aspects. + For further information, see sub-section 2.9 "Standalone Document + Declaration" and section 5 "Conformance" of [XML] . - In addition to the changes described above, the change controller has - been changed to be the World Wide Web Consortium (W3C). + In practice, character set issues have proved to be the biggest + source of interoperability problems. The use of UTF-8, and + careful attention to the guidelines set out in Section 3, are the + best ways to avoid such problems. -10.2. Registration Guidelines for XML-based Media Types Not Using - '+xml' + Published specification: Extensible Markup Language (XML) 1.0 (Fifth + Edition) [XML] or subsequent editions or versions thereof. - Registrations for new XML-based media types which do _not_ use the - '+xml' suffix SHOULD, in specifying the charset parameter and - encoding considerations, define them as: "Same as [charset parameter - / encoding considerations] of application/xml as specified in RFC - XXXX." + Applications that use this media type: XML is device-, platform-, + and vendor-neutral and is supported by generic and task-specific + applications and a wide range of generic XML tools (editors, + parsers, Web agents, ...). - Enabling the charset parameter is RECOMMENDED, since this information - can be used by XML processors to determine authoritatively the - character encoding of the XML MIME entity in the absence of a BOM. - If there are some reasons not to follow this advice, they SHOULD be - included as part of the registration. As shown above, two such - reasons are "UTF-8 only" or "UTF-8 or UTF-16 only". + Additional information: - These registrations SHOULD specify that the XML-based media type - being registered has all of the security considerations described in - RFC XXXX plus any additional considerations specific to that media - type. + Magic number(s): None. - These registrations SHOULD also make reference to RFC XXXX in - specifying magic numbers, base URIs, and use of the BOM. + Although no byte sequences can be counted on to always be + present, XML MIME entities in ASCII-compatible character sets + (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C + (". @@ -1267,21 +1265,21 @@ Latest version available at [5]. [XPtrRegPolicy] Hazael-Massieux, D., "XPointer Scheme Name Registry Policy", 2005, . [XPtrReg] Hazael-Massieux, D., "XPointer Registry", 2005, . -12.2. Informative References +11.2. Informative References [ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [AWWW] Jacobs, I. and N. Walsh, "Architecture of the World Wide Web, Volume One", W3C Recommendation REC-webarch-20041215, December 2004, . @@ -1377,22 +1375,23 @@ [XMLid] Marsh, J., Veillard, D., and N. Walsh, "xml:id Version 1.0", W3C Recommendation REC-xml-id-20050909, September 2005, . Latest version available at [10]. Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? [RFC3023] contains a detailed discussion of the (at the time) novel - use of a suffix, a practice which has since become widespread. - Interested parties are referred to [RFC3023], Appendix A. + use of a suffix, a practice which has since become widespread. Those + interested in a historical perspective on this topic are referred to + [RFC3023], Appendix A. The registration process for new '+xml' media types is described in [RFC6838] Appendix B. Core XML specifications The following specifications each articulate key aspects of XML document semantics: Namespaces in XML 1.0 [XMLNS10]/Namespaces in XML 1.1 [XMLNS11]