ids/8/843.txt

#?SuikaWiki/0.9 import="XML訳語集,メッセージ訳語集,RFC訳語集,その他の訳語集"
[1] [[RFC3023]] と [[RFC2679]] の差分, そしてその和訳。
詳しくは [[..//]] 参照。
*1[INS[.]] Introduction [INS[初めに]]
>The World Wide Web Consortium [DEL[(W3C)]] has issued [DEK[a Recommendation [REC-XML] which defines the]] Extensible Markup Language
(XML)[DEL[, version 1]] [INS[1.0 (Second Edition)[XML] ]].  To enable the exchange of XML
network entities, this document [DEL[proposes two]] [INS[standardizes five]] new media types[DEL[,]] [INS[--]]
text/xml[INS[,]] [DEL[and]] application/xml[INS[, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd -- as well as a naming convention for identifying XML-based MIME media types]].
>XML entities are currently exchanged on the World Wide Web, and XML
is also used for property values and parameter marshalling by the
WebDAV[INS[[RFC2518] ]] protocol for remote web authoring.  Thus, there is a
need for a media type to properly label the exchange of XML network
entities. [DEL[(Note that, as sometimes happens between two communities, both MIME and XML have defined the term entity, with different meanings.)]]
>Although XML is a subset of the Standard Generalized Markup Language
(SGML) [DEL[[ISO-8897], and currently is]] [INS[ISO 8879[SGML], which has been]] assigned the media types
text/sgml and application/sgml, there are several reasons why use of
text/sgml or application/sgml to label XML is inappropriate.  First,
there exist many applications [DEL[which]] [INS[that]] can process XML, but [DEK[which]] [INS[that]] cannot
process SGML, due to SGML's larger feature set.  Second, SGML
applications cannot always process XML entities, because XML uses
features of recent technical corrigenda to SGML.  Third, the
definition of text/sgml and application/sgml [INS[in]] [RFC[DEL[-]]1874] includes
parameters for SGML bit combination transformation format (SGML-
bctf), and SGML boot attribute (SGML-boot).  Since XML does not use
these parameters, it would be ambiguous if such parameters were given
for an XML [INS[MIME]] entity.  For these reasons, the best approach for
labeling XML network entities is to provide new media types for XML.
>Since XML is an integral part of the WebDAV Distributed Authoring
Protocol, and since World Wide Web Consortium Recommendations have
conventionally been assigned IETF tree media types, and since similar
media types (HTML, SGML) have been assigned IETF tree media types,
the XML media types also belong in the IETF media types tree.

[INS[
>Similarly, XML will be used as a foundation for other media types,
including types in every branch of the IETF media types tree.  To
facilitate the processing of such types, media types based on XML,
but that are not identified using text/xml or application/xml, SHOULD
be named using a suffix of '+xml' as described in Section 7.  This
will allow XML-based tools -- browsers, editors, search engines, and
other processors -- to work with all XML-based media types.
]INS]

[INS[
*2. Notational Conventions
]INS]
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC[DEL[-]]2119].

[INS[
>As defined in [RFC2781], the three charsets "utf-16", "utf-16le", and
"utf-16be" are used to label UTF-16 text.  In this document, "the
UTF-16 family" refers to those three charsets.  By contrast, the
phrases "utf-16" or UTF-16 in this document refer specifically to the
single charset "utf-16".
>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" called
entities that "have content" and are normally "identified by
name".
>In this document, "XML MIME entity" is defined as the latter (an XML
entity) encapsulated in the former (a MIME entity).
]INS]

*3[INS[.]] XML Media Types
>This document [DEL[introduces two new]] [INS[standardizes five]] media types [DEL[for]] [INS[related to]] XML [DEL[MIME]]
entities[DEL[,]][INS[:]] text/xml[INS[,]] [DEL[and]] application/xml[INS[, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd]].
Registration information for these media types [DEL[are]] [INS[is]] described in the
sections below.

[DEL[
>Every XML entity is suitable for use with the application/xml media
type without modification.  But this does not exploit the fact that
XML can be treated as plain text in many cases.  MIME user agents
(and web user agents) that do not have explicit support for
application/xml will treat it as application/octet-stream, for
example, by offering to save it to a file.
>To indicate that an XML entity should be treated as plain text by
default, use the text/xml media type.  This restricts the encoding
used in the XML entity to those that are compatible with the
requirements for text media types as described in [RFC-2045] and
[RFC-2046], e.g., UTF-8, but not UTF-16 (except for HTTP).
]DEL]

[INS[
>Within the XML specification, XML MIME entities can be classified
into four types.  In the XML terminology, they are called "document
entities", "external DTD subsets", "external parsed entities", and
"external parameter entities".  The media types text/xml and
application/xml MAY be used for "document entities", while text/xml-external-parsed-entity or application/xml-external-parsed-entity
SHOULD be used for "external parsed entities".  The media type
application/xml-dtd SHOULD be used for "external DTD subsets" or
"external parameter entities".  application/xml and text/xml MUST NOT
be used for "external parameter entities" or "external DTD subsets",
and MUST NOT be used for "external parsed entities" unless they are
also well-formed "document entities" and are referenced as such.
Note that [RFC2376] (which this document obsoletes) allowed such
usage, although in practice it is likely to have been rare.

XML 仕様書のによれば、 XML MIME 実体は4種類に分類できます。
XML の用語では、[CODE[[[文書実体]]]], [CODE[[[外部解析実体]]]],
[CODE[[[外部DTD部分集合]]]], [CODE[[[外部引数集合]]]]と呼びます。
媒体型 [CODE[[[text/xml]]]] 及び
[CODE[[[application/xml]]]] を、
[CODE[文書実体]]に使っても'''構いません'''。
[CODE[[[text/xml-external-parsed-entity]]]]
又は [CODE[[[application/xml-external-parsed-entity]]]]
を[CODE[外部解析実体]]に使う'''べきです'''。
[CODE[[[application/xml-dtd]]]] 
を[CODE[外部 DTD 部分集合]]及び[CODE[外部引数実体]]に使う'''べきです'''。
[CODE[application/xml]] 及び [CODE[text/xml]]
は、[CODE[外部引数実体]]や[CODE[外部 DTD 部分集合]]には使っては'''ならず'''、
[CODE[外部解析実体]]には、これが[CODE[文書実体]]として[[整形式]]であって、そう参照される場合を除いて使っては'''なりません'''。
(この文書が廃止する) [[RFC2376]] はそのような使い方を認めていますが、
実際のところこれは稀でしょう。

>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.
>If an XML document -- that is, the unprocessed, source XML document
-- is readable by casual users, text/xml is preferable to
application/xml.  MIME user agents (and web user agents) that do not
have explicit support for text/xml will treat it as text/plain, for
example, by displaying the XML MIME entity as plain text.
Application/xml is preferable when the XML MIME entity is unreadable
by casual users.  Similarly, text/xml-external-parsed-entity is
preferable when an external parsed entity is readable by casual
users, but application/xml-external-parsed-entity is preferable when
a plain text display is inappropriate.

>NOTE: Users are in general not used to text containing tags such
as <price>, and often find such tags quite disorienting or
annoying.  If one is not sure, the conservative principle would
suggest using application/* instead of text/* so as not to put
information in front of users that they will quite likely not
understand.

>The top-level media type "text" has some restrictions on MIME
entities and they are described in [RFC2045] and [RFC2046].  In
particular, the UTF-16 family, UCS-4, and UTF-32 are not allowed
(except over HTTP[RFC2616], which uses a MIME-like mechanism).  Thus,
if an XML document or external parsed entity is encoded in such
character encoding schemes, it cannot be labeled as text/xml or
text/xml-external-parsed-entity (except for HTTP).
>Text/xml and application/xml behave differently when the charset
parameter is not explicitly specified.  If the default charset (i.e.,
US-ASCII) for text/xml is inconvenient for some reason (e.g., bad web
servers), application/xml provides an alternative (see "Optional
parameters" of application/xml registration in Section 3.2).  The
same rules apply to the distinction between text/xml-external-
parsed-entity and application/xml-external-parsed-entity.
]INS]

>XML provides a general framework for defining sequences of structured
data.  In some cases, it may be desirable to define new media
types [DEL[which]] [INS[that]] use XML but define a specific application of XML, perhaps due to
domain-specific security considerations or runtime information. [INS[Furthermore, such media types may allow UTF-8 or UTF-16 only and prohibit other charsets.]]  This document does not prohibit [DEL[future]] [INS[such]] media
types [DEL[dedicated to such XML applications]] [INS[and in fact expects them to proliferate]].  However, developers
of such media types are [DEL[recommended]] [INS[STRONGLY RECOMMENDED]] to use this document as
a basis [INS[for their registration]].  In particular, the charset 
parameter [DEL[should]] [INS[SHOULD]] be used in the same manner[INS[, as described in Section 7.1, in order to enhance interoperability]].

[INS[
>An XML document labeled as text/xml or application/xml 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.
]INS]
[DEL[
>Within the XML specification, XML entities can be classified into
four types.  In the XML terminology, they are called "document
entities", "external DTD subsets", "external parsed entities", and
"external parameter entities".  The media types text/xml and
application/xml can be used for any of these four types.
]DEL]

**3.1 Text/xml Registration
:MIME media type name: text
: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 character
      encoding of the XML [INS[MIME]] entity.  The charset parameter can also
      be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP.  "utf-8" [RFC[DEL[-]]2279] is the
      recommended value, representing the UTF-8 charset.  UTF-8 is
      supported by all conforming [DEL[XML]] processors [DEL[[REC-XML] ]] [INS[of [XML] ]].

      If the XML [INS[MIME]] entity is transmitted via HTTP, which uses a
      MIME-like mechanism that is exempt from the restrictions on the
      text top-level type (see section 19.4.1 of [DEL[HTTP 1.1]] [RFC2616]), [DEL["UTF-16"]] [INS["utf-16"]] [DEL[(Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646])]]
      [INS[[RFC2781])]] [INS[(訳注: ママ)]] is also recommended.  UTF-16 is supported by all
      conforming [DEL[XML]] processors [DEL[[REC-XML] ]] [INS[of [XML] ]].  Since the handling of CR, LF and
      NUL for text types in most MIME applications would cause undesired
      transformations of individual octets in UTF-16 multi-octet
      characters, gateways from HTTP to these MIME applications MUST
      transform the XML MIME entity from [DEL[a]] text/xml; charset="utf-16" to
      application/xml; charset="utf-16".

      Conformant with [RFC[DEL[-]]2046], if a text/xml entity is received with
      the charset parameter omitted, MIME processors and XML processors
      MUST use the default charset value of "us-ascii"[INS[[ASCII] ]].  In cases
      where the XML [INS[MIME]] entity is transmitted via HTTP, the default
      charset value is still "us-ascii".  [INS[(Note: There is an inconsistency between this specification and HTTP/1.1, which uses ISO-8859-1[ISO8859] as the default for a historical reason.  Since XML is a new format, a new default should be chosen for better I18N.  US-ASCII was chosen, since it is the intersection of UTF-8 and ISO-8859-1 and since it is already used by MIME.)]]

[INS[
>There are several reasons that the charset parameter is
authoritative.  First, some MIME processing engines do transcoding
of MIME bodies of the top-level media type "text" without
reference to any of the internal content.  Thus, it is possible
that some agent might change text/xml; charset="iso-2022-jp" to
text/xml; charset="utf-8" without modifying the encoding
declaration of an XML document.  Second, text/xml must be
compatible with text/plain, since MIME agents that do not
understand text/xml will fallback to handling it as text/plain.
If the charset parameter for text/xml were not authoritative, such
fallback would cause data corruption.  Third, recent web servers
have been improved so that users can specify the charset
parameter.  Fourth, [RFC2130] specifies that the recommended
specification scheme is the "charset" parameter.
]INS]

>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 [INS[MIME]] 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 [INS[MIME]] entity.

   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 [DEL[both]] UTF-8 [DEL[and UTF-16 is]] [INS[MUST be]]
      encoded in quoted-printable or base64.  For 8-bit clean transport
      (e.g., [DEL[ESMTP,]] 8BITMIME[INS[[RFC1652] ESMTP]][DEL[,]] or NNTP[INS[[RFC0977] ]]), UTF-8 [DEL[is]] [INS[does]] not
      [INS[need to be]] encoded.  [DEL[For binary clean transports (e.g., HTTP)]] [INS[Over HTTP[RFC2616] ]], no content-transfer-encoding is necessary [INS[and UTF-16 may also be used]].

:Security considerations: See [DEL[4 below]] [INS[Section 10]].

   Interoperability considerations: XML has proven to be interoperable
      across WebDAV clients and servers, and for import and export from
      multiple XML authoring tools.  [INS[For maximum interoperability, validating processors are recommended.  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: [DEL[see [REC-XML] ]] [INS[Extensible Markup Language (XML) 1.0 (Second Edition)[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, WebDAV[RFC2518] clients and servers, as well as XML
      authoring tools.

   Additional information:

      Magic number(s): None.

         Although no byte sequences can be counted on to always be
         present, XML [INS[MIME]] entities in ASCII-compatible charsets
         (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C
         ("<?xml")[INS[, 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 [[DEL[REC-]]XML].

      File extension(s): .xml[DEL[, .dtd]]

      Macintosh File Type Code(s): "TEXT"

   Person [DEL[&]] [INS[and]] email address for further information:

[DEL[
- Dan Connolly <connolly@w3.org>
- Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp>
]DEL]
[INS[
- MURATA Makoto (FAMILY Given) <mmurata@trl.ibm.co.jp>
- Simon St.Laurent <simonstl@simonstl.com>
- Daniel Kohn <dan@dankohn.com>
]INS]
   Intended usage: COMMON

   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 <tbray@textuality.com>
- Jean Paoli <jeanpa@microsoft.com>
- C. M. Sperberg-McQueen <cmsmcq@uic.edu>
- Eve Maler <eve.maler@east.sun.com>

>The W3C, and the W3C XML [INS[Core]] [DEL[w]][INS[W]]orking [DEL[g]][INS[G]]roup, have change control
over the XML specification.

**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 [INS[MIME]] entity.  The charset parameter can also be used to
      provide protocol-specific operations, such as charset-based
      content negotiation in HTTP.

      [DEL["UTF-8" [RFC-2279] and "UTF-16" (Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646])]] [INS["utf-8" [RFC2279] and "utf-16" [RFC2781] ]] are the recommended
      values, representing the UTF-8 and UTF-16 charsets, respectively.
      These charsets are preferred since they are supported by all
      conforming [DEL[XML]] processors [INS[of]] [[DEL[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 [[DEL[REC-]]XML]
      [DEL[which]] [INS[that]] directly address this contingency.  However, MIME processors
      [DEL[which]] [INS[that]] are not XML processors [DEL[should not]] [INS[SHOULD NOT]] assume a default charset if
      the charset parameter is omitted from an application/xml entity.

[INS[
>There are several reasons that the charset parameter is
authoritative.  First, recent web servers have been improved so
that users can specify the charset parameter.  Second, [RFC2130]
specifies that the recommended specification scheme is the
"charset" parameter.
>On the other hand, it has been argued that the charset parameter
should be omitted and the mechanism described in Appendix F of
[XML] (which is non-normative) should be solely relied on.  This
approach would allow users to avoid configuration of the charset
parameter; an XML document stored in a file is likely to contain a
correct encoding declaration or BOM (if necessary), since the
operating system does not typically provide charset information
for files.  If users would like to rely on the encoding
declaration or BOM and to hide charset information from protocols,
they may determine not to use the parameter.
]INS]
>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 [INS[MIME]] 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 [INS[MIME]] entity.

   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 [DEL[both]] [INS[either]] UTF-8 [DEL[and]] [INS[or]]
      UTF-16 [DEL[is]] [INS[MUST be]] encoded in quoted-printable or base64.  For 8-bit
      clean transport (e.g., [DEL[ESMTP, 8BITMIME]] [INS[8BITMIME[RFC1652] ESMTP]] or NNTP[INS[[RFC0977] ]]),
      UTF-8 is not encoded, but the UTF-16 [DEL[is base64]] [INS[family MUST be]] encoded [INS[in base64]].  For binary clean transport[INS[s]] (e.g., HTTP[INS[[RFC2616] ]]), no
      content-transfer-encoding is necessary.

   Security considerations: [DEL[See section 4 below.]] [INS[See Section 10.]]

   Interoperability considerations: [INS[Same as Section 3.1.]]

[DEL[
>XML has proven to be interoperable for import and export from
multiple XML authoring tools.
]DEL]
: Published specification: [DEL[see [REC-XML] ]] [INS[Same as Section 3.1.]]
:Applications which use this media type: [INS[Same as Section 3.1.]]
[DEL[
>XML is device-, platform-, and vendor-neutral and is supported by
a wide range of Web user agents and XML authoring tools.
]DEL]
:Additional information: Same as Section 3.1.

[DEL[
: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

]DEL]

:Person and email address for further information: [INS[Same as Section 3.1.]]
[DEL[
- Dan Connolly <connolly@w3.org>
- Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp>
]DEL]
:Intended usage: COMMON
:Author/Change controller: [INS[Same as Section 3.1.]]
[DEL[
>The XML specification is a work product of the World Wide Web
Consortium's XML Working Group, and was edited by:
]DEL]
[INS[
**3.3 Text/xml-external-parsed-entity Registration
:MIME media type name: text
:MIME subtype name: xml-external-parsed-entity
:Mandatory parameters: none
:Optional parameters: charset

      The charset parameter of text/xml-external-parsed-entity is
      handled the same as that of text/xml as described in Section 3.1.

:Encoding considerations: Same as Section 3.1.
:Security considerations: See Section 10.

   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 should
      enhance interoperability of both XML documents and XML external
      parsed entities.

:Published specification: Same as Section 3.1.
:Applications which use this media type: Same as Section 3.1.
:Additional information:

      Magic number(s): Same as Section 3.1.

      File extension(s): .xml or .ent

      Macintosh File Type Code(s): "TEXT"

:Person and email address for further information: Same as Section 3.1.
:Intended usage: COMMON
:Author/Change controller: Same as Section 3.1.

**3.4 Application/xml-external-parsed-entity Registration
:MIME media type name: application
:MIME subtype name: xml-external-parsed-entity
:Mandatory parameters: none
:Optional parameters: charset

      The charset parameter of application/xml-external-parsed-entity is
      handled the same as that of application/xml as described in
      Section 3.2.

:Encoding considerations: Same as Section 3.2.
:Security considerations: See Section 10.
:Interoperability considerations: Same as those for text/xml-external-parsed-entity as described in Section 3.3.
:Published specification: Same as text/xml as described in Section 3.1.
:Applications which use this media type: Same as Section 3.1.
:Additional information:

      Magic number(s): Same as Section 3.1.

      File extension(s): .xml or .ent

      Macintosh File Type Code(s): "TEXT"

:Person and email address for further information: Same as Section 3.1.
:Intended usage: COMMON
:Author/Change controller: Same as Section 3.1.

**3.5 Application/xml-dtd Registration
:MIME media type name: application
:MIME subtype name: xml-dtd
:Mandatory parameters: none
:Optional parameters: charset

      The charset parameter of application/xml-dtd is handled the same
      as that of application/xml as described in Section 3.2.

:Encoding considerations: Same as Section 3.2.
:Security considerations: See Section 10.

   Interoperability considerations: XML DTDs have proven to be
      interoperable by DTD authoring tools and XML browsers, among
      others.

:Published specification: Same as text/xml as described in Section 3.1.

   Applications which use this media type: DTD authoring tools handle
      external DTD subsets as well as external parameter entities.  XML
      browsers may also access external DTD subsets and external
      parameter entities.

:Additional information:

      Magic number(s): Same as Section 3.1.

      File extension(s): .dtd or .mod

      Macintosh File Type Code(s): "TEXT"

:Person and email address for further information: Same as Section 3.1.
:Intended usage: COMMON
:Author/Change controller: Same as Section 3.1.

**3.6 Summary
>The following list applies to text/xml, text/xml-external-parsed-
entity, and XML-based media types under the top-level type "text"
that define the charset parameter according to this specification:

   o  Charset parameter is strongly recommended.

   o  If the charset parameter is not specified, the default is "us-
      ascii".  The default of "iso-8859-1" in HTTP is explicitly
      overridden.

   o  No error handling provisions.

   o  An encoding declaration, if present, is irrelevant, but when
      saving a received resource as a file, the correct encoding
      declaration SHOULD be inserted.

>The next list applies to application/xml, application/xml-external-
parsed-entity, application/xml-dtd, and XML-based media types under
top-level types other than "text" that define the charset parameter
according to this specification:

- Charset parameter is strongly recommended, and if present, it
takes precedence.
- If the charset parameter is omitted, conforming XML processors
MUST follow the requirements in section 4.3.3 of [XML].
]INS]
*License
[[RFCのライセンス]]
* メモ
- [[..//]] 参照。