rfc2376.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

6.4 text/xml with Omitted Charset

   Content-type: text/xml

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

   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
   [RFC-2046]. 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 entity are UTF-16 or UTF-8,
   or the XML entity has an explicit encoding declaration, XML and MIME
   processors must assume the charset is "us-ascii".

6.5 application/xml with UTF-16 Charset

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

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

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

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




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


6.7 application/xml with Omitted Charset and UTF-16 XML Entity

   Content-type: application/xml

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

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

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

6.8 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, and optionally applies the mechanism
   described in appendix F (which is non-normative) of [REC-XML] to
   determine the charset encoding of UTF-8. The XML entity does not
   contain an encoding declaration, but since the encoding is UTF-8,
   this is still a conforming XML entity.

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

6.9 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 entity does have an encoding declaration
   inside the XML entity which specifies the entity's charset. Following
   the requirements in section 4.3.3, and optionally applying the
   mechanism described in appendix F (non-normative) of [REC-XML], the
   XML processor determines the charset encoding of the XML entity (in
   this example, UCS-4).





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


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

7  References

   [ISO-10646] ISO/IEC, Information Technology - Universal Multiple-
               Octet Coded Character Set (UCS) - Part 1: Architecture
               and Basic Multilingual Plane, May 1993.

   [ISO-8897]  ISO (International Organization for Standardization) ISO
               8879:1986(E) Information Processing -- Text and Office
               Systems -- Standard Generalized Markup Language (SGML).
               First edition -- 1986- 10-15.

   [REC-XML]   T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible
               Markup Language (XML)" World Wide Web Consortium
               Recommendation REC- xml-19980210.
               http://www.w3.org/TR/1998/REC-xml-19980210.

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

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

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

   [RFC-2068]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
               Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
               RFC 2068, January 1997.

   [RFC-2279]  Yergeau, F., "UTF-8, a transformation format of ISO
               10646", RFC 2279, January 1998.

   [UNICODE]   The Unicode Consortium, "The Unicode Standard -- Version
               2.0", Addison-Wesley, 1996.





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


8  Acknowledgements

   Chris Newman and Yaron Y. Goland both contributed content to the
   security considerations section of this document.  In particular,
   some text in the security considerations section is copied verbatim
   from work in progress, draft-newman-mime-textpara-00, by permission
   of the author.  Chris Newman additionally contributed content to the
   encoding considerations sections. Dan Connolly contributed content
   discussing when to use text/xml. Discussions with Ned Freed and Dan
   Connolly helped refine the author's understanding of the text media
   type; feedback from Larry Masinter was also very helpful in
   understanding media type registration issues.

   Members of the W3C XML Working Group and XML Special Interest group
   have made significant contributions to this document, and the authors
   would like to specially recognize James Clark, Martin Duerst, Rick
   Jelliffe, Gavin Nicol for their many thoughtful comments.

9  Addresses of Authors

   E. James Whitehead, Jr.
   Dept. of Information and Computer Science
   University of California, Irvine
   Irvine, CA 92697-3425

   EMail: [e-mail]


   Murata Makoto (Family Given)
   Fuji Xerox Information Systems,
   KSP 9A7, 2-1, Sakado 3-chome, Takatsu-ku,
   Kawasaki-shi, Kanagawa-ken,
   213 Japan

   EMail: [e-mail]
















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


10  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Whitehead & Murata           Informational                     [Page 15]