rfc3023.txt

RFC 的详细文档！

   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 -- those registering media types SHOULD use the '+xml'
   convention unless they have a particularly compelling reason not to.

   The registration process for these media types is described in
   [RFC2048].  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



Murata, et al.              Standards Track                    [Page 17]

RFC 3023                    XML Media Types                 January 2001


   in order to ensure maximum interoperability of their XML-based
   documents.  Similarly, media subtypes that do not represent XML MIME
   entities MUST NOT be allowed to register with a '+xml' suffix.

7.1 Referencing

   Registrations for new XML-based media types under the top-level type
   "text" SHOULD, in specifying the charset parameter and encoding
   considerations, define them as: "Same as [charset parameter /
   encoding considerations] of text/xml as specified in RFC 3023."

   Registrations for new XML-based media types under top-level types
   other than "text" 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
   3023."

   The use of the charset parameter is STRONGLY RECOMMENDED, since this
   information can be used by XML processors to determine
   authoritatively the charset of the XML MIME entity.

   These registrations SHOULD specify that the XML-based media type
   being registered has all of the security considerations described in
   RFC 3023 plus any additional considerations specific to that media
   type.

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

   These registrations MAY reference the text/xml registration in RFC
   3023 in specifying interoperability considerations, if these
   considerations are not overridden by issues specific to that media
   type.

8. Examples

   The examples below give the value of the MIME Content-type header and
   the XML declaration (which includes the encoding declaration) inside
   the XML MIME entity.  For UTF-16 examples, the Byte Order Mark
   character is denoted as "{BOM}", and the XML declaration is assumed
   to come at the beginning of the XML MIME entity, immediately
   following the BOM.  Note that other MIME headers may be present, and
   the XML MIME entity may contain other data in addition to the XML
   declaration; the examples focus on the Content-type header and the
   encoding declaration for clarity.





Murata, et al.              Standards Track                    [Page 18]

RFC 3023                    XML Media Types                 January 2001


8.1 Text/xml with UTF-8 Charset

   Content-type: text/xml; charset="utf-8"

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

   This is the recommended charset value for use with text/xml.  Since
   the charset parameter is provided, MIME and XML processors MUST treat
   the enclosed entity as UTF-8 encoded.

   If sent using a 7-bit transport (e.g., SMTP[RFC0821]), the XML MIME
   entity MUST use a content-transfer-encoding of either quoted-
   printable or base64.  For an 8-bit clean transport (e.g., 8BITMIME
   ESMTP or NNTP), or a binary clean transport (e.g., HTTP), no
   content-transfer-encoding is necessary.

8.2 Text/xml with UTF-16 Charset

   Content-type: text/xml; charset="utf-16"

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

   or

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

   This is possible only when the XML MIME entity is transmitted via
   HTTP, which uses a MIME-like mechanism and is a binary-clean
   protocol, hence does not perform CR and LF transformations and allows
   NUL octets.  As described in [RFC2781], the UTF-16 family MUST NOT be
   used with media types under the top-level type "text" except over
   HTTP (see section 19.4.1 of [RFC2616] for details).

   Since HTTP is binary clean, no content-transfer-encoding is
   necessary.

8.3 Text/xml with UTF-16BE Charset

   Content-type: text/xml; charset="utf-16be"

   <?xml version='1.0' encoding='utf-16be'?>

   Observe that the BOM does not exist.  This is again possible only
   when the XML MIME entity is transmitted via HTTP.







Murata, et al.              Standards Track                    [Page 19]

RFC 3023                    XML Media Types                 January 2001


8.4 Text/xml with ISO-2022-KR Charset

   Content-type: text/xml; charset="iso-2022-kr"

   <?xml version="1.0" encoding='iso-2022-kr'?>

   This example shows text/xml with a Korean charset (e.g., Hangul)
   encoded following the specification in [RFC1557].  Since the charset
   parameter is provided, MIME and XML processors MUST treat the
   enclosed entity as encoded per RFC 1557.

   Since ISO-2022-KR has been defined to use only 7 bits of data, no
   content-transfer-encoding is necessary with any transport.

8.5 Text/xml with Omitted Charset

   Content-type: text/xml

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

   or

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

   This example shows text/xml with the charset parameter omitted.  In
   this case, MIME and XML processors MUST assume the charset is "us-
   ascii", the default charset value for text media types specified in
   [RFC2046].  The default of "us-ascii" holds even if the text/xml
   entity is transported using HTTP.

   Omitting the charset parameter is NOT RECOMMENDED for text/xml.  For
   example, even if the contents of the XML MIME entity are UTF-16 or
   UTF-8, or the XML MIME entity has an explicit encoding declaration,
   XML and MIME processors MUST assume the charset is "us-ascii".

8.6 Application/xml with UTF-16 Charset

   Content-type: application/xml; charset="utf-16"

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

   or

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

   This is a recommended charset value for use with application/xml.
   Since the charset parameter is provided, MIME and XML processors MUST
   treat the enclosed entity as UTF-16 encoded.



Murata, et al.              Standards Track                    [Page 20]

RFC 3023                    XML Media Types                 January 2001


   If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean
   transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be
   encoded in quoted-printable or base64.  For a binary clean transport
   (e.g., HTTP), no content-transfer-encoding is necessary.

8.7 Application/xml with UTF-16BE Charset

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

   <?xml version='1.0' encoding='utf-16be'?>

   Observe that the BOM does not exist.  Since the charset parameter is
   provided, MIME and XML processors MUST treat the enclosed entity as
   UTF-16BE encoded.

8.8 Application/xml with ISO-2022-KR Charset

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

   <?xml version="1.0" encoding="iso-2022-kr"?>

   This example shows application/xml with a Korean charset (e.g.,
   Hangul) encoded following the specification in [RFC1557].  Since the
   charset parameter is provided, MIME and XML processors MUST treat the
   enclosed entity as encoded per RFC 1557, independent of whether the
   XML MIME entity has an internal encoding declaration (this example
   does show such a declaration, which agrees with the charset
   parameter).

   Since ISO-2022-KR has been defined to use only 7 bits of data, no
   content-transfer-encoding is necessary with any transport.

8.9 Application/xml with Omitted Charset and UTF-16 XML MIME Entity

   Content-type: application/xml

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

   or

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

   For this example, the XML MIME entity begins with a BOM.  Since the
   charset has been omitted, a conforming XML processor follows the
   requirements of [XML], section 4.3.3.  Specifically, the XML
   processor reads the BOM, and thus knows deterministically that the
   charset is UTF-16.




Murata, et al.              Standards Track                    [Page 21]

RFC 3023                    XML Media Types                 January 2001


   An XML-unaware MIME processor SHOULD make no assumptions about the
   charset of the XML MIME entity.

8.10 Application/xml with Omitted Charset and UTF-8 Entity

   Content-type: application/xml

   <?xml version='1.0'?>

   In this example, the charset parameter has been omitted, and there is
   no BOM.  Since there is no BOM, the XML processor follows the
   requirements in section 4.3.3 of [XML], and optionally applies the
   mechanism described in Appendix F (which is non-normative) of [XML]
   to determine the charset encoding of UTF-8.  The XML MIME entity does
   not contain an encoding declaration, but since the encoding is UTF-8,
   this is still a conforming XML MIME entity.

   An XML-unaware MIME processor SHOULD make no assumptions about the
   charset of the XML MIME entity.

8.11 Application/xml with Omitted Charset and Internal Encoding
     Declaration

   Content-type: application/xml

   <?xml version='1.0' encoding="iso-10646-ucs-4"?>

   In this example, the charset parameter has been omitted, and there is
   no BOM.  However, the XML MIME entity does have an encoding
   declaration inside the XML MIME entity that specifies the entity's
   charset.  Following the requirements in section 4.3.3 of [XML], and
   optionally applying the mechanism described in Appendix F (non-
   normative) of [XML], the XML processor determines the charset of the
   XML MIME entity (in this example, UCS-4).

   An XML-unaware MIME processor SHOULD make no assumptions about the
   charset of the XML MIME entity.

8.12 Text/xml-external-parsed-entity with UTF-8 Charset

   Content-type: text/xml-external-parsed-entity; charset="utf-8"

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

   This is the recommended charset value for use with text/xml-
   external-parsed-entity.  Since the charset parameter is provided,
   MIME and XML processors MUST treat the enclosed entity as UTF-8
   encoded.



Murata, et al.              Standards Track                    [Page 22]

RFC 3023                    XML Media Types                 January 2001


   If sent using a 7-bit transport (e.g., SMTP), the XML MIME entity
   MUST use a content-transfer-encoding of either quoted-printable or
   base64.  For an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP),
   or a binary clean transport (e.g., HTTP) no content-transfer-encoding
   is necessary.

8.13 Application/xml-external-parsed-entity with UTF-16 Charset

   Content-type: application/xml-external-parsed-entity;
    charset="utf-16"