2.1 Conformance Keywords

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119].

2.2 Characters, Encodings, Charsets

Both XML (in an XML or Text declaration using the encoding pseudo- attribute) and MIME (in a Content-Type header field using the charset parameter) use a common set of labels [IANA-charsets] to identify the MIME charset (mapping from byte stream to character sequence [RFC2978]).

In this specification we will use the phrases "charset parameter" and "encoding declaration" to refer to whatever MIME charset is specified by a MIME charset parameter or XML encoding declaration respectively. We reserve the phrase "character encoding" (or, when the context makes the intention clear, simply "encoding") for the MIME charset actually used in a particular XML MIME entity.

[UNICODE] defines three "encoding forms", which are independent of serialization, namely UTF-8, UTF-16 and UTF-32. This specification follows this precedent. Furthermore, note that UTF-16 XML documents may be serialised into MIME entities in one of two ways: either big-endian, labelled (optionally) "utf-16" or "utf-16be", or little-endian, labelled (optionally) "utf-16" or "utf-16le". As UTF-8 can only be serialized in one way, the only possible label for UTF-8-encoded documents when serialised into MIME entities is "utf-8".

2.3 MIME Entities, XML Entities

As sometimes happens between two communities, both MIME and XML have defined the term entity, with different meanings. Section 2.4 of [RFC2045] says:

• "The term 'entity' refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity."

Section 4 of [XML] says:

• "An XML document may consist of one or many storage units. These are called entities; they all have content and are all (except for the document entity and the external DTD subset) identified by entity name".

In this specification, "XML MIME entity" is defined as the latter (an XML entity) encapsulated in the former (a MIME entity).

Furthermore, XML provides for the naming and referencing of entities for purposes of inclusion and/or substitution. In this specification "XML-entity declaration/reference/..." is used to avoid confusion when referring to such cases.

3.1 XML MIME producers

XML-aware MIME producers SHOULD supply a charset parameter and/or an appropriate BOM with non-UTF-8-encoded XML MIME entities which lack an encoding declaration, and SHOULD remove or correct an encoding declaration which is known to be incorrect (for example, as a result of transcoding).

XML-aware MIME producers MUST supply an XML text declaration at the beginning of non-UNICODE XML external parsed entities which would otherwise begin with the hexadecimal octet sequences 0xFE 0xFF, 0xFF 0xFE or 0xEF 0xBB 0xBF, in order to avoid the mistaken detection of a BOM.

XML-unaware MIME producers MUST NOT supply a charset parameter with an XML MIME entity unless the entity's character encoding is reliably known.

XML MIME producers are RECOMMENDED to provide means for XML MIME entity authors to determine what value, if any, is given to charset parameters for their entities, for example by enabling user-level configuration of filename-to-Content-Type-header mappings on a file-by-file or suffix basis.

The use of UTF-32 is NOT RECOMMENDED for XML MIME entities.

3.2 XML MIME consumers

For XML MIME consumers, the question of priority arises in cases when the available character encoding information is not consistent. Again, we must distinguish betweeen XML-aware and XML-unaware agents.

When a charset parameter is specified for an XML MIME entity, the normative component of the [XML] specification leaves the question open as to how to determine the encoding with which to attempt to process the entity. This is true independently of whether or not the entity contains in-band encoding information, that is, either a BOM (Section 3.3) or an XML encoding declaration, or both, or neither. In particular, in the case where there is in-band information and it conflicts with the charset parameter, the [XML] specification does not specify which is authoritative. In its (non-normative) Appendix F it defers to this specification:

[T]he preferred method of handling conflict should be specified as part of the higher-level protocol used to deliver XML. In particular, please refer to [IETF RFC 3023] or its successor…

Accordingly, to conform with deployed processors and content and to avoid conflicting with this or other normative specifications, this specification sets the priority as follows:

• All consumers SHOULD treat a BOM (Section 3.3) as authoritative if it is present in an XML MIME entity. In the absence of a BOM (Section 3.3), all consumers SHOULD treat the charset parameter as authoritative if it is present. For XML-aware consumers, note that Section 4.3.3 of [XML] does not make it an error for the charset parameter and the XML encoding declaration (or the UTF-8 default in the absence of encoding declaration and BOM) to be inconsistent, although such consumers might choose to issue a warning in this case.

When MIME producers conform to the requirements stated above (Section 3) (Section 3.1), such inconsistencies will not arise---this statement of priorities only has practical impact in the case of non-conforming XML MIME entities.

If an XML MIME entity is received where the charset parameter is omitted, no information is being provided about the character encoding by the MIME Content-Type header. XML-aware consumers MUST follow the requirements in section 4.3.3 of [XML] that directly address this case. XML-unaware MIME consumers SHOULD NOT assume a default encoding in this case.

3.3 The Byte Order Mark (BOM) and Encoding Conversions

Section 4.3.3 of [XML] specifies thatUTF-16 XML MIME entitiesnot labelled as "utf-16le" or "utf16-be" MUST begin with a byte order mark (BOM), U+FEFF, which appears as the hexadecimal octet sequence 0xFE 0xFF (big-endian) or 0xFF 0xFE (little-endian). [XML] further states that the BOM is an encoding signature, and is not part of either the markup or the character data of the XML document.

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 conversion. Similarly, when converting from another encoding into UTF-16, either without a charset parameter, or labelled "utf-16", the BOM MUST be added unless the original encoding was UTF-8 and a BOM was already present, in which case it MUST be transcoded into the appropriate UTF-16 BOM.

Section 4.3.3 of [XML] also allows for UTF-8 XML MIME entities to begin with a BOM, which appears as the hexadecimal octet sequence 0xEF 0xBB 0xBF. This is likewise defined to be an encoding signature, and not part of either the markup or the character data of the XML document.

Applications that convert XML from UTF-8 to an encoding other than UTF-16 MUST strip the BOM, if present, before conversion. Applications which convert XML into UTF-8 MAY add a BOM.

In addition to the MIME charset "utf-16", [RFC2781] introduces "utf-16le" (little endian) and "utf-16be" (big endian). The BOM is prohibited in MIME entities with these labels. When an XML MIME entity is encoded in "utf-16le" or "utf-16be", it MUST NOT begin with the BOM but SHOULD contain an in-band XML encoding declaration. Conversion from UTF-8 or UTF-16 (unlabelled, or labelled with "utf-16") to "utf-16be" or "utf-16le" MUST strip a BOM if present, and conversion in the other direction MUST (for UTF-16) or MAY (for UTF-8) add the appropriate BOM.

Appendix F of [XML] also implies the a UTF-32 BOM may be used in conjunction with UTF-32-encoded documents. As noted above, this 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.1 XML MIME Entities

Note that [RFC3023] (which this specification obsoletes) recommended the use of text/xml and text/xml-external-parsed-entity for document entities and external parsed entities, respectively, but described handling of character encoding which differed from common implementation practice. These media types are still commonly used, and this specification aligns the handling of character encoding with industry practice.

Note that [RFC2376] (which is obsolete) allowed application/xml and text/xml to be used for any of the four types, although in practice it is likely to have been rare.

Neither external DTD subsets nor external parameter entities parse as XML documents, and while some XML document entities may be used as external parsed entities and vice versa, there are many cases where the two are not interchangeable. XML also has unparsed entities, internal parsed entities, and internal parameter entities, but they are not XML MIME entities.

Compared to [RFC2376] or [RFC3023], this specification alters the handling of character encoding of text/xml and text/xml-external-parsed-entity, treating them no differently from the respective application/ types. However application/xml and application/xml-external-parsed-entity are still RECOMMENDED, to avoid possible confusion based on the earlier distinction. The former confusion around the question of default character sets for the two text/ types no longer arises because

• [HTTPbis] changes [RFC2616] by removing the ISO-8859-1 default and not defining any default at all;
• [RFC6657] updates [RFC2046] to remove the US-ASCII default.

See Section 3 for the now-unified approach to the charset parameter 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 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 at both the language level and the application leveland 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] .

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 ("<?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 00 6C 00 (the Byte Order Mark (BOM) followed by "<?xml"). For more information, see Appendix F of [XML].

File extension(s):

.xml

Macintosh File Type Code(s):

"TEXT"

Base URI:

See Section 6

Person and email address for further information:

See Authors' Addresses section

Intended usage:

COMMON

Author:

See Authors' Addresses section

Change controller:

The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over this specification.

4.3 Text/xml Registration

The registration information for text/xml is in all respects the same as that given for application/xml above (Section 4.2).

4.4 Application/xml-external-parsed-entity Registration

Type name:

application

Subtype name:

xml-external-parsed-entity

Required parameters:

none

Optional parameters:

charset

• See Section 3.

Encoding considerations:

Same as for application/xml (Section 4.2).

Security considerations:

See Section 11.

Interoperability considerations:

XML external parsed entities are as interoperable as XML documents, though they have a less tightly constrained structure and therefore need to be referenced by XML documents for proper handling by XML processors. Similarly, XML documents cannot be reliably used as external parsed entities because external parsed entities are prohibited from having standalone document declarations or DTDs. Identifying XML external parsed entities with their own content type enhances interoperability of both XML documents and XML external parsed entities.

Published specification:

Same as for application/xml (Section 4.2).

Applications which use this media type:

Same as for application/xml (Section 4.2).

Additional information:

Magic number(s):

Same as for application/xml (Section 4.2).

File extension(s):

.xml or .ent

Macintosh File Type Code(s):

"TEXT"

Base URI:

See Section 6

Person and email address for further information:

See Authors' Addresses section.

Intended usage:

COMMON

Author:

See Authors' Addresses section.

Change controller:

The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over this specification.

4.5 Text/xml-external-parsed-entity Registration

The registration information for text/xml-external-parsed-entity is in all respects the same as that given for application/xml-external-parsed-entity above (Section 4.4).

4.6 Application/xml-dtd Registration

Type name:

application

Subtype name:

xml-dtd

Required parameters:

none

Optional parameters:

charset

• See Section 3.

Encoding considerations:

Same as for application/xml (Section 4.2).

Security considerations:

See Section 11.

Interoperability considerations:

XML DTDs have proven to be interoperable by DTD authoring tools and XML validators, among others.

Published specification:

Same as for application/xml (Section 4.2).

Applications which use this media type:

DTD authoring tools handle external DTD subsets as well as external parameter entities. XML validators may also access external DTD subsets and external parameter entities.

Additional information:

Magic number(s):

Same as for application/xml (Section 4.2).

File extension(s):

.dtd or .mod

Macintosh File Type Code(s):

"TEXT"

Person and email address for further information:

See Authors' Addresses section.

Intended usage:

COMMON

Author:

See Authors' Addresses section.

Change controller:

The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over this specification.

8.1 XML-based Media Types

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'.)

• NOTE: Section 5.3.2HTTPbis [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.

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:

• 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.
• 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.

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.

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. Media subtypes that do not represent XML MIME 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.2 +xml Structured Syntax Suffix Registration

Name:

Extensible Markup Language (XML)

+suffix:

+xml

Reference:

This specification

Encoding considerations:

Same as Section 4.2.

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.

• In practice these constraints imply that for a fragment identifier addressed to an instance of a specific "xxx/yyy+xml" type, there are three cases:
  • For fragment identifiers matching the syntax defined in [XPointerFramework], where the fragment identifier resolves per the rules specified there, then process as specified there;
  • For fragment identifiers matching the syntax defined in [XPointerFramework], where the fragment identifier does not resolve per the rules specified there, then process as specified in "xxx/yyy+xml";
  • For fragment identifiers not matching the syntax defined in [XPointerFramework], then process as specified in "xxx/yyy+xml". A fragment identifier of the form "xywh=160,120,320,240", as defined in [MediaFrags], which might be used in a URI for an XML-encoded image, would fall in this category.

Interoperability considerations:

Same as Section 4.2. See above, and also Section 3, for guidelines on the use of the 'charset' parameter.

Security considerations:

See Section 11.

Contact:

See Authors' Addresses section.

Author:

See Authors' Addresses section.

Change controller:

The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over this specification.

8.3 Registration guidelines for XML-based media types not using '+xml'

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."

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".

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.

These registrations SHOULD also make reference to RFC XXXX in specifying magic numbers, base URIs, and use of the BOM.

These registrations MAY reference the application/xml registration in RFC XXXX in specifying interoperability and fragment identifier considerations, if these considerations are not overridden by issues specific to that media type.

9.1 UTF-8 Charset

Content-Type: application/xml; charset=utf-8

<?xml version="1.0" encoding="utf-8"?>

or

<?xml version="1.0"?>

UTF-8 is the recommended encoding for use with all the media types defined in this specification. Since the charset parameter is provided and there is no overriding BOM, both 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

Content-Type: application/xml; charset=utf-16

{BOM}<?xml version="1.0" encoding="utf-16"?>

or

{BOM}<?xml version="1.0"?>

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).

9.3 Omitted Charset and 8-bit MIME Entity

Content-Type: application/xml

<?xml version="1.0" encoding="iso-8859-1"?>

Since the charset parameter is not provided in the Content-Type header and there is no overriding BOM, XML processors must treat the "iso-8859-1" encoding as authoritative. 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

Content-Type: application/xml

{BOM}<?xml version="1.0" encoding="utf-16"?>

or

{BOM}<?xml version="1.0"?>

This example shows a 16-bit MIME entity with no charset parameter. However since there is a BOM all 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).

9.5 Omitted Charset, no Internal Encoding Declaration

Content-Type: application/xml

<?xml version='1.0'?>

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.

An 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 entities.

9.6 UTF-16BE Charset

Content-Type: application/xml; charset=utf-16be

<?xml version='1.0' encoding='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, 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.

9.7 Non-UTF Charset

Content-Type: application/xml; charset=iso-2022-kr

<?xml version="1.0" encoding="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, all 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.

9.8 INCONSISTENT EXAMPLE: Conflicting Charset and Internal Encoding Declaration

Content-Type: application/xml; charset=iso-8859-1

<?xml version="1.0" encoding="utf-8"?>

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, MIME and XML processors will interoperate. Since the charset parameter is authoritative in the absence of a BOM, all processors will treat the enclosed entity as iso-8859-1 encoded. That is, the "UTF-8" encoding declaration will be ignored.

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

Content-Type: application/xml; charset=iso-8859-1

{BOM}<?xml version="1.0"?>

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 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.

Processors generating XML MIME entities must not label conflicting character encoding information between the MIME Content-Type and an entity-initial BOM.