rfc2376.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 844 行 · 第 1/3 页


RFC 2376                    XML Media Types                    July 1998


3.2 Application/xml Registration

   MIME media type name: application

   MIME subtype name: xml

   Mandatory parameters: none

   Optional parameters: charset

      Although listed as an optional parameter, 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 entity. The charset parameter can also be used to provide
      protocol-specific operations, such as charset-based content
      negotiation in HTTP.

      "UTF-8" [RFC-2279] and "UTF-16" (Appendix C.3 of [UNICODE] and
      Amendment 1 of [ISO-10646]) are the recommended values,
      representing the UTF-8 and UTF-16 charsets, respectively. These
      charsets are  preferred since they are supported by all conforming
      XML processors [REC-XML].

      If an application/xml entity is received where the charset
      parameter is omitted, no information is being provided about the
      charset by the MIME Content-Type header. Conforming XML processors
      MUST follow the requirements in section 4.3.3 of [REC-XML] which
      directly address this contingency. However, MIME processors which
      are not XML processors should not assume a default charset if the
      charset parameter is omitted from an application/xml entity.

      Since the charset parameter is authoritative, the charset is not
      always declared within an XML encoding declaration.  Thus, special
      care is needed when the recipient strips the MIME header and
      provides persistent storage of the received XML entity (e.g., in a
      file system).  Unless the charset is UTF-8 or UTF-16, the
      recipient SHOULD also persistently store information about the
      charset, perhaps by embedding a correct XML encoding declaration
      within the XML entity.












Whitehead & Murata           Informational                      [Page 6]

RFC 2376                    XML Media Types                    July 1998


   Encoding considerations:

      This media type MAY be encoded as appropriate for the charset and
      the capabilities of the underlying MIME transport. For 7-bit
      transports, data in both UTF-8 and UTF-16 is encoded in quoted-
      printable or base64.  For 8-bit clean transport (e.g., ESMTP,
      8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64
      encoded.  For binary clean transport (e.g., HTTP), no content-
      transfer-encoding is necessary.

   Security considerations:

      See section 4 below.

   Interoperability considerations:

      XML has proven to be interoperable for import and export from
      multiple XML authoring tools.

   Published specification: see [REC-XML]

   Applications which use this media type:

      XML is device-, platform-, and vendor-neutral and is supported by
      a wide range of Web user agents and XML authoring tools.

   Additional information:

      Magic number(s): none

      Although no byte sequences can be counted on to always be present,
      XML entities in ASCII-compatible charsets (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
      or FF FE 3C 00 3F 00 78 00 6D 00 (the Byte Order Mark (BOM)
      followed by "<?xml").  For more information, see Annex F of [REC-
      XML].

      File extension(s): .xml, .dtd
      Macintosh File Type Code(s): "TEXT"

   Person & email address for further information:

      Dan Connolly <[e-mail]>
      Murata Makoto (Family Given) <[e-mail]>

   Intended usage: COMMON




Whitehead & Murata           Informational                      [Page 7]

RFC 2376                    XML Media Types                    July 1998


   Author/Change controller:

      The XML specification is a work product of the World Wide Web
      Consortium's XML Working Group, and was edited by:

      Tim Bray <[e-mail]>
      Jean Paoli <[e-mail]>
      C. M. Sperberg-McQueen <[e-mail]>

      The W3C, and the W3C XML working group, has change control over
      the XML specification.

4  Security Considerations

   XML, as a subset of SGML, has the same security considerations as
   specified in [RFC-1874].

   To paraphrase section 3 of [RFC-1874], XML entities contain
   information to be parsed and processed by the recipient's XML system.
   These entities may contain and such systems may permit explicit
   system level commands to be executed while processing the data.  To
   the extent that an XML system will execute arbitrary command strings,
   recipients of XML entities may be at risk. In general, it may be
   possible to specify commands that perform unauthorized file
   operations or make changes to the display processor's environment
   that affect subsequent operations.

   Use of XML is expected to be varied, and widespread.  XML is under
   scrutiny by a wide range of communities for use as a common syntax
   for community-specific metadata.  For example, the Dublin Core group
   is using XML for document metadata, and a new effort has begun which
   is considering use of XML for medical information.  Other groups view
   XML as a mechanism for marshalling parameters for remote procedure
   calls.  More uses of XML will undoubtedly arise.

   Security considerations will vary by domain of use.  For example, XML
   medical records will have much more stringent privacy and security
   considerations than XML library metadata. Similarly, use of XML as a
   parameter marshalling syntax necessitates a case by case security
   review.

   XML may also have some of the same security concerns as plain text.
   Like plain text, XML can contain escape sequences which, when
   displayed, have the potential to change the display processor
   environment in ways that adversely affect subsequent operations.
   Possible effects include, but are not limited to, locking the
   keyboard, changing display parameters so subsequent displayed text is
   unreadable, or even changing display parameters to deliberately



Whitehead & Murata           Informational                      [Page 8]

RFC 2376                    XML Media Types                    July 1998


   obscure or distort subsequent displayed material so that its meaning
   is lost or altered.  Display processors should either filter such
   material from displayed text or else make sure to reset all important
   settings after a given display operation is complete.

   Some terminal devices have keys whose output, when pressed, can be
   changed by sending the display processor a character sequence. If
   this is possible the display of a text object containing such
   character sequences could reprogram keys to perform some illicit or
   dangerous action when the key is subsequently pressed by the user.
   In some cases not only can keys be programmed, they can be triggered
   remotely, making it possible for a text display operation to directly
   perform some unwanted action. As such, the ability to program keys
   should be blocked either by filtering or by disabling the ability to
   program keys entirely.

   Note that it is also possible to construct XML documents which make
   use of what XML terms "entity references" (using the XML meaning of
   the term "entity", which differs from the MIME definition of this
   term), to construct repeated expansions of text. Recursive expansions
   are prohibited [REC-XML] and XML processors are required to detect
   them.  However, even non-recursive expansions may cause problems with
   the finite computing resources of computers, if they are performed
   many times.

5  The Byte Order Mark (BOM) and Conversions to/from UTF-16

   The XML Recommendation, in section 4.3.3, specifies that UTF-16 XML
   entities must begin with a byte order mark (BOM), which is the ZERO
   WIDTH NO-BREAK SPACE character, hexadecimal sequence 0xFEFF (or
   0xFFFE, depending on endian). The XML Recommendation 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 BOM, applications which convert XML from the UTF-16
   encoding to another encoding SHOULD strip the BOM before conversion.
   Similarly, when converting from another encoding into UTF-16, the BOM
   SHOULD be added after conversion is complete.

6  Examples

   The examples below give the value of the Content-type MIME header and
   the XML declaration (which includes the encoding declaration) inside
   the XML 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 entity, immediately following the BOM. Note
   that other MIME headers may be present, and the XML entity may




Whitehead & Murata           Informational                      [Page 9]

RFC 2376                    XML Media Types                    July 1998


   contain other data in addition to the XML declaration; the examples
   focus on the Content-type header and the encoding declaration for
   clarity.

6.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), the XML entity must use
   a content-transfer-encoding of either quoted-printable or base64.
   For an 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), or a
   binary clean transport (e.g., HTTP) no content-transfer-encoding is
   necessary.

6.2 text/xml with UTF-16 Charset

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

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

   This is possible only when the XML 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. This differs from typical text MIME type processing (see
   section 19.4.1 of HTTP 1.1 [RFC-2068] for details).

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

6.3 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 [RFC-1557].  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.



Whitehead & Murata           Informational                     [Page 10]

RFC 2376                    XML Media Types                    July 1998