rfc3023.txt

RFC 的详细文档！

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

   or

   {BOM}<?xml?>

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

   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.14 Application/xml-external-parsed-entity with UTF-16BE Charset

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

   <?xml encoding="utf-16be"?>

   Since the charset parameter is provided, MIME and XML processors MUST
   treat the enclosed entity as UTF-16BE encoded.

8.15 Application/xml-dtd

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

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

   Charset "utf-8" is a recommended charset value for use with
   application/xml-dtd.  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 23]

RFC 3023                    XML Media Types                 January 2001


8.16 Application/mathml+xml

   Content-type: application/mathml+xml

   <?xml version="1.0" ?>

   MathML documents are XML documents whose content describes
   mathematical information, as defined by [MathML].  As a format based
   on XML, MathML documents SHOULD use the '+xml' suffix convention in
   their MIME content-type identifier.  However, no content type has yet
   been registered for MathML and so this media type should not be used
   until such registration has been completed.

8.17 Application/xslt+xml

   Content-type: application/xslt+xml

   <?xml version="1.0" ?>

   Extensible Stylesheet Language (XSLT) documents are XML documents
   whose content describes stylesheets for other XML documents, as
   defined by [XSLT].  As a format based on XML, XSLT documents SHOULD
   use the '+xml' suffix convention in their MIME content-type
   identifier.  However, no content type has yet been registered for
   XSLT and so this media type should not be used until such
   registration has been completed.

8.18 Application/rdf+xml

   Content-type: application/rdf+xml

   <?xml version="1.0" ?>

   RDF documents identified using this MIME type are XML documents whose
   content describes metadata, as defined by [RDF].  As a format based
   on XML, RDF documents SHOULD use the '+xml' suffix convention in
   their MIME content-type identifier.  However, no content type has yet
   been registered for RDF and so this media type should not be used
   until such registration has been completed.

8.19 Image/svg+xml

   Content-type: image/svg+xml

   <?xml version="1.0" ?>






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


   Scalable Vector Graphics (SVG) documents are XML documents whose
   content describes graphical information, as defined by [SVG].  As a
   format based on XML, SVG documents SHOULD use the '+xml' suffix
   convention in their MIME content-type identifier.  However, no
   content type has yet been registered for SVG and so this media type
   should not be used until such registration has been completed.

8.20 INCONSISTENT EXAMPLE: Text/xml with UTF-8 Charset

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

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

   Since the charset parameter is provided in the Content-Type header,
   MIME and XML processors MUST treat the enclosed entity as UTF-8
   encoded.  That is, the "iso-8859-1" encoding MUST be ignored.

   Processors generating XML MIME entities MUST NOT label conflicting
   charset information between the MIME Content-Type and the XML
   declaration.

9. IANA Considerations

   As described in Section 7, this document updates the [RFC2048]
   registration process for XML-based MIME types.

10. Security Considerations

   XML, as a subset of SGML, has all of the same security considerations
   as specified in [RFC1874], and likely more, due to its expected
   ubiquitous deployment.

   To paraphrase section 3 of RFC 1874, XML MIME 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 MIME entities may be a 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.

   In general, any information stored outside of the direct control of
   the user -- including CSS style sheets, XSL transformations, entity
   declarations, and DTDs -- can be a source of insecurity, by either
   obvious or subtle means.  For example, a tiny "whiteout attack"
   modification made to a "master" style sheet could make words in
   critical locations disappear in user documents, without directly



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


   modifying the user document or the stylesheet it references.  Thus,
   the security of any XML document is vitally dependent on all of the
   documents recursively referenced by that document.

   The entity lists and DTDs for XHTML 1.0[XHTML], for instance, are
   likely to be a commonly used set of information.  Many developers
   will use and trust them, few of whom will know much about the level
   of security on the W3C's servers, or on any similarly trusted
   repository.

   The simplest attack involves adding declarations that break
   validation.  Adding extraneous declarations to a list of character
   entities can effectively "break the contract" used by documents.  A
   tiny change that produces a fatal error in a DTD could halt XML
   processing on a large scale.  Extraneous declarations are fairly
   obvious, but more sophisticated tricks, like changing attributes from
   being optional to required, can be difficult to track down.  Perhaps
   the most dangerous option available to crackers is redefining default
   values for attributes: e.g., if developers have relied on defaulted
   attributes for security, a relatively small change might expose
   enormous quantities of information.

   Apart from the structural possibilities, another option, "entity
   spoofing," can be used to insert text into documents, vandalizing and
   perhaps conveying an unintended message.  Because XML 1.0 permits
   multiple entity declarations, and the first declaration takes
   precedence, it's possible to insert malicious content where an entity
   is used, such as by inserting the full text of Winnie the Pooh in
   every occurrence of &mdash;.

   Use of the digital signatures work currently underway by the xmldsig
   working group may eventually ameliorate the dangers of referencing
   external documents not under one's own control.

   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[RFC2413] group is using XML for document metadata, and a new
   effort has begun that 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.



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


   XML may also have some of the same security concerns as plain text.
   Like plain text, XML can contain escape sequences that, 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
   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 that make
   use of what XML terms "entity references" (using the XML meaning of
   the term "entity" as described in Section 2), to construct repeated
   expansions of text.  Recursive expansions are prohibited by [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.

References

   [ASCII]    "US-ASCII. Coded Character Set -- 7-Bit American Standard
              Code for Information Interchange", ANSI X3.4-1986, 1986.

   [CSS]      Bos, B., Lie, H.W., Lilley, C. and I. Jacobs, "Cascading
              Style Sheets, level 2 (CSS2) Specification", World Wide
              Web Consortium Recommendation REC-CSS2, May 1998,
              <http://www.w3.org/TR/REC-CSS2/>.

   [ISO8859]  "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.






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


   [MathML]   Ion, P. and R. Miner, "Mathematical Markup Language
              (MathML) 1.01", World Wide Web Consortium Recommendation
              REC-MathML, July 1999, <http://www.w3.org/TR/REC-MathML/>.

   [PNG]      Boutell, T., "PNG (Portable Network Graphics)
              Specification", World Wide Web Consortium Recommendation
              REC-png, October 1996, <http://www.w3.org/TR/REC-png>.

   [RDF]      Lassila, O. and R.R. Swick, "Resource Description
              Framework (RDF) Model and Syntax Specification", World
              Wide Web Consortium Recommendation REC-rdf-syntax,
              February 1999, <http://www.w3.org/TR/REC-rdf-syntax/>.

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
              821, August 1982.

   [RFC0977]  Kantor, B. and P. Lapsley, "Network News Transfer
              Protocol", RFC 977, February 1986.

   [RFC1557]  Choi, U., Chon, K. and H. Park, "Korean Character Encoding
              for Internet Messages", RFC 1557, December 1993.

   [RFC1652]  Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
              Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
              RFC 1652, July 1994.

   [RFC1874]  Levinson, E., "SGML Media Types", RFC 1874, December 1995.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC2048]  Freed, N., Klensin, J. and J. Postel, "Multipurpose
              Internet Mail Extensions (MIME) Part Four: Registration
              Procedures",