Network Working Group M. Murata
Request for Comments: 3023 IBM Tokyo Research Laboratory
Obsoletes: 2376 S. St.Laurent
Updates: 2048 simonstl.com
Category: Standards Track D. Kohn
Skymoon Ventures
January 2001
XML Media Types
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.
text / xmlで、アプリケーション/ XML、text / xmlで、外部解析されたエンティティ、アプリケーション/ XML-外部解析されたエンティティ、およびアプリケーション/ XML-DTD - - ネットワークの交換で使用するためこのドキュメントでは、5つの新しいメディアタイプを標準化拡張マークアップ言語（XML）に関連するエンティティ。この文書はまた、これらのメディアタイプがXML MIME（多目的インターネットメール拡張）エンティティを表すこれらの5つのタイプの外でメディアタイプを命名（接尾辞を使用して「+ XML」）規則を標準化しています。 XMLのMIMEエンティティが現在World Wide Web上のハイパーテキスト転送プロトコルを介して交換され、リモートのWebオーサリング用のWebDAVプロトコルの不可欠な一部であり、多くのドメインでの有用性を有することが期待されます。
Major differences from RFC 2376 are (1) the addition of text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of "utf-16le" and "utf-16be".
RFC 2376からの主な違いは、テキスト/ XMLの外部の構文解析済みエンティティ、アプリケーション/ XMLの外部の構文解析済みエンティティの（1）また、アプリケーション/ XML-DTD、（2） '+ XML' サフィックス規則（ありますこれはまた、RFC 2048の登録処理）を更新し、（3） "UTF-16LE" の議論と "UTF-16BE"。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Text/xml Registration . . . . . . . . . . . . . . . . . . . 7
3.2 Application/xml Registration . . . . . . . . . . . . . . . . 9
3.3 Text/xml-external-parsed-entity Registration . . . . . . . . 11
3.4 Application/xml-external-parsed-entity Registration . . . . 12
3.5 Application/xml-dtd Registration . . . . . . . . . . . . . . 13
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. The Byte Order Mark (BOM) and Conversions to/from the UTF-16
Charset . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 15
6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 15
7. A Naming Convention for XML-Based Media Types . . . . . . . 16
7.1 Referencing . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1 Text/xml with UTF-8 Charset . . . . . . . . . . . . . . . . 19
8.2 Text/xml with UTF-16 Charset . . . . . . . . . . . . . . . . 19
8.3 Text/xml with UTF-16BE Charset . . . . . . . . . . . . . . . 19
8.4 Text/xml with ISO-2022-KR Charset . . . . . . . . . . . . . 20
8.5 Text/xml with Omitted Charset . . . . . . . . . . . . . . . 20
8.6 Application/xml with UTF-16 Charset . . . . . . . . . . . . 20
8.7 Application/xml with UTF-16BE Charset . . . . . . . . . . . 21
8.8 Application/xml with ISO-2022-KR Charset . . . . . . . . . . 21
8.9 Application/xml with Omitted Charset and UTF-16 XML MIME
Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.10 Application/xml with Omitted Charset and UTF-8 Entity . . . 22
8.11 Application/xml with Omitted Charset and Internal Encoding
Declaration . . . . . . . . . . . . . . . . . . . . . . . . 22
8.12 Text/xml-external-parsed-entity with UTF-8 Charset . . . . . 22
8.13 Application/xml-external-parsed-entity with UTF-16 Charset . 23
8.14 Application/xml-external-parsed-entity with UTF-16BE Charset 23
8.15 Application/xml-dtd . . . . . . . . . . . . . . . . . . . . 23
8.16 Application/mathml+xml . . . . . . . . . . . . . . . . . . . 24
8.17 Application/xslt+xml . . . . . . . . . . . . . . . . . . . . 24
8.18 Application/rdf+xml . . . . . . . . . . . . . . . . . . . . 24
8.19 Image/svg+xml . . . . . . . . . . . . . . . . . . . . . . . 24
8.20 INCONSISTENT EXAMPLE: Text/xml with UTF-8 Charset . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . 25
References . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
A. Why Use the '+xml' Suffix for XML-Based MIME Types? . . . . 32
A.1 Why not just use text/xml or application/xml and let the XML
processor dispatch to the correct application based on the
referenced DTD? . . . . . . . . . . . . . . . . . . . . . . 32
A.2 Why not create a new subtree (e.g., image/xml.svg) to
represent XML MIME types? . . . . . . . . . . . . . . . . . 32
A.3 Why not create a new top-level MIME type for XML-based media
types? . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.4 Why not just have the MIME processor 'sniff' the content to
determine whether it is XML? . . . . . . . . . . . . . . . . 33
A.5 Why not use a MIME parameter to specify that a media type
uses XML syntax? . . . . . . . . . . . . . . . . . . . . . . 33
A.6 How about labeling with parameters in the other direction
(e.g., application/xml; Content-Feature=iotp)? . . . . . . . 34
A.7 How about a new superclass MIME parameter that is defined to
apply to all MIME types (e.g., Content-Type:
application/iotp; $superclass=xml)? . . . . . . . . . . . . 34
A.8 What about adding a new parameter to the Content-Disposition
header or creating a new Content-Structure header to
indicate XML syntax? . . . . . . . . . . . . . . . . . . . . 35
A.9 How about a new Alternative-Content-Type header? . . . . . . 35
A.10 How about using a conneg tag instead (e.g., accept-features:
(syntax=xml))? . . . . . . . . . . . . . . . . . . . . . . . 35
A.11 How about a third-level content-type, such as text/xml/rdf? 35
A.12 Why use the plus ('+') character for the suffix '+xml'? . . 36
A.13 What is the semantic difference between application/foo and
application/foo+xml? . . . . . . . . . . . . . . . . . . . . 36
A.14 What happens when an even better markup language (e.g.,
EBML) is defined, or a new category of data? . . . . . . . . 36
A.15 Why must I use the '+xml' suffix for my new XML-based media
type? . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B. Changes from RFC 2376 . . . . . . . . . . . . . . . . . . . 37
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . 39
The World Wide Web Consortium has issued Extensible Markup Language (XML) 1.0 (Second Edition)[XML]. To enable the exchange of XML network entities, this document standardizes five new media types -- text/xml, application/xml, 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.
World Wide Webコンソーシアムは、拡張マークアップ言語（XML）1.0（第二版）[XML]を発行しています。 text / xmlで、アプリケーション/ XML、text / xmlで、外部解析されたエンティティ、アプリケーション/ XML--外部解析対象実体、およびアプリケーション/ xmlの - XMLのネットワーク・エンティティの交換を可能にするために、このドキュメントは、5つの新しいメディアタイプを標準化-dtd - だけでなく、XMLベースのMIMEメディアタイプを識別するための命名規則。
XML entities are currently exchanged on the World Wide Web, and XML is also used for property values and parameter marshalling by the WebDAV[RFC2518] protocol for remote web authoring. Thus, there is a need for a media type to properly label the exchange of XML network entities.
XMLエンティティは、現在World Wide Web上で交換されており、XMLは、リモートWebオーサリング用のWebDAV [RFC2518]プロトコルでプロパティ値とパラメータのマーシャリングのために使用されています。このように、適切にXMLネットワークエンティティの交換を標識するメディアタイプの必要性があります。
Although XML is a subset of the Standard Generalized Markup Language (SGML) 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 that can process XML, but 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 in [RFC1874] 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 MIME entity. For these reasons, the best approach for labeling XML network entities is to provide new media types for XML.
XMLは、メディアタイプがtext / SGML、アプリケーション/ SGMLが割り当てられている標準一般化マークアップ言語（SGML）ISO 8879 [SGML]のサブセットであるが、いくつかの理由がある理由テキスト/ SGMLまたはアプリケーション/ SGMLの使用にラベルXMLは不適切です。まず、XMLを処理することができ、多くのアプリケーションが存在し、それが原因SGMLの大きな機能セットに、SGMLを処理することはできません。 XMLはSGMLに最近の技術正誤表の機能を使用するため、第二に、SGMLアプリケーションは常に、XMLエンティティを処理することはできません。第三に、[RFC1874]のテキスト/ SGML、アプリケーション/ SGMLの定義はSGMLビット組み合わせ変換フォーマット（SGML-BCTF）、およびSGMLブート属性（SGMLブート）のためのパラメータを含みます。 XMLは、これらのパラメータを使用していないので、このようなパラメータは、XMLのMIMEエンティティのために与えられた場合、それがあいまいになります。これらの理由から、ラベリングXMLネットワークエンティティのための最善のアプローチは、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.
XMLは、オーサリングプロトコル分散のWebDAVの不可欠な一部であり、ワールドワイドウェブコンソーシアムので、推奨事項は、従来、IETF木のメディアタイプが割り当てられている、と同様のメディアタイプ（HTML、SGML）以来、XMLのメディアをIETF木のメディアタイプが割り当てられているので、タイプはまた、IETFのメディアタイプツリーに属しています。
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.
同様に、XMLは、IETFメディアタイプツリーのすべてのブランチのタイプを含む他のメディアタイプ、のための基盤として使用されます。これができるようになりますセクション7で説明したように、このようなタイプの処理を容易にXMLに基づいて、メディアの種類、それがtext / xmlまたはapplication / xmlを使用して識別されていないために、「+ XML」の接尾辞を使用して名前を付ける必要がありXML-ベースのツール - ブラウザ、エディタ、検索エンジン、および他のプロセッサ - すべてのXMLベースのメディアタイプで動作するように。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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".
[RFC2781]で定義されるように、3つの文字セット "UTF-16"、 "UTF-16LE"、及び "UTF-16BE" はラベルUTF-16のテキストに使用されます。この文書では、「UTF-16ファミリは、」これらの3つの文字セットを指します。これとは対照的に、この文書に記載されているフレーズ「UTF-16」またはUTF-16は、単一の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:
時には2つのコミュニティの間で起こるように、MIMEおよびXMLの両方が異なる意味で、用語エンティティを定義しています。 [RFC2045]のセクション2.4は言います：
"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."
「用語 『エンティティ』はMIME定義のヘッダフィールドおよびメッセージまたはマルチパートエンティティの本体内の部品のいずれかの内容を具体的に指します。」
Section 4 of [XML] says:
[XML]のセクション4は述べています：
"An XML document may consist of one or many storage units" called entities that "have content" and are normally "identified by name".
「コンテンツを持っている」と、通常は「名前で識別される」ことを事業体と呼ばれる「XMLドキュメントは、1つのまたは多数のストレージユニットからなるものであってもよいです」。
In this document, "XML MIME entity" is defined as the latter (an XML entity) encapsulated in the former (a MIME entity).
この文書では、「XMLのMIMEエンティティは、」前（MIMEエンティティ）にカプセル化された（XMLエンティティ）後者のように定義されます。
This document standardizes five media types related to XML MIME entities: text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd. Registration information for these media types is described in the sections below.
text / xmlで、アプリケーション/ XML、text / xmlで、外部解析されたエンティティ、アプリケーション/ XML-外部解析されたエンティティ、およびアプリケーション/ XML-DTD：この文書は、XMLのMIMEエンティティに関連する5つのメディアタイプを標準化しています。これらのメディアタイプの登録情報は、以下のセクションで説明されています。
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の用語では、彼らは、「文書実体」、「外部DTDサブセット」、「外部解析対象実体」、および「外部パラメータ実体」と呼ばれています。 text / xmlで、外部解析されたエンティティまたはアプリケーション/ XML-外部解析されたエンティティは、「外部解析対象実体」のために使用されるべきであるメディアタイプがtext / xmlの、アプリケーション/ xmlのは、「文書実体」のために使用されるかもしれません。メディアタイプアプリケーション/ XML-DTDは「外部DTDサブセット」または「外部パラメータ実体」のために使用されるべきです。アプリケーション/ XMLとtext / xmlでは、「外部パラメータ実体」または「外部DTDサブセット」のために使用してはいけません、そして、彼らはまた、よく形成された「文書実体」であり、として参照されない限り、「外部解析対象実体」のために使用してはいけませんそのような。実際には稀であった可能性があるが（この文書は時代遅れ）[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.
外部DTDサブセットや外部パラメータ実体はいずれも、XML文書として解析し、いくつかのXML文書実体が外部解析対象実体とその逆として使用することができる一方で、2は互換性がない場合が多いです。また、XMLは解析対象外実体、内部解析対象実体、および内部パラメータ実体を持っていますが、彼らは、XML MIME実体ではありません。
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.
XML文書の場合は - 、未処理、ソースXML文書である - カジュアルなユーザーによって読み取り可能で、テキスト/ xmlのは、アプリケーション/ xmlのに好適です。 text / xmlで明示的にサポートしていないMIMEユーザエージェント（Webユーザエージェント）は、プレーンテキストとしてXMLのMIMEエンティティを表示することによって、例えば、text / plainのようにそれを扱います。 XMLのMIMEエンティティはカジュアルなユーザーが読み取れない場合は、アプリケーション/ xmlのが好ましいです。同様に、外部解析エンティティはカジュアルユーザーによって読み取り可能である場合、テキスト/ XMLの外部の構文解析済みエンティティが好ましいが、プレーンテキストの表示が不適切な場合、アプリケーション/ XMLの外部の構文解析済みエンティティであることが好ましいです。
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」はMIME実体上のいくつかの制限があり、それらは[RFC2045]と[RFC2046]で説明されています。具体的には、UTF-16ファミリー、UCS-4、UTF-32（MIMEのようなメカニズムを使用して、[RFC2616]、HTTP上を除いて）許可されません。 XML文書や外部解析対象実体は、文字符号化方式で符号化される場合、それはテキスト/ xmlまたは（HTTP以外の）テキスト/ XML-外部解析されたエンティティとして表示することができません。
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.
テキスト/ XMLおよびアプリケーション/ xmlのcharsetパラメータが明示的に指定されていない場合には動作が異なります。 text / xmlでのデフォルトの文字セット（すなわち、US-ASCII）が何らかの理由で不便である場合（例えば、悪いWebサーバ）、アプリケーション/ xmlのは、代替手段を提供します（セクション3.2でのアプリケーション/ XML登録の「オプションパラメータ」を参照してください）。同じルールは、テキスト/ XML-外部構文解析エンティティ及びアプリケーション/ XMLの外部の構文解析済みエンティティとの間の区別にも適用されます。
XML provides a general framework for defining sequences of structured data. In some cases, it may be desirable to define new media types that use XML but define a specific application of XML, perhaps due to domain-specific security considerations or runtime information. Furthermore, such media types may allow UTF-8 or UTF-16 only and prohibit other charsets. This document does not prohibit such media types and in fact expects them to proliferate. However, developers of such media types are STRONGLY RECOMMENDED to use this document as a basis for their registration. In particular, the charset parameter SHOULD be used in the same manner, as described in Section 7.1, in order to enhance interoperability.
XMLは、構造化データのシーケンスを定義するための一般的なフレームワークを提供します。いくつかのケースでは、XMLを使用する新しいメディアタイプを定義することが望ましいかもしれないが、おそらく、ドメイン固有のセキュリティの考慮事項やランタイム情報を、XMLの特定のアプリケーションを定義します。さらに、そのようなメディアタイプは、UTF-8やUTF-16のみを許可し、他の文字セットを禁止することができます。この文書では、このようなメディアタイプを禁止し、実際にそれらが増殖することを期待しません。しかし、そのようなメディアタイプの開発者は強く彼らの登録のための基礎として、この文書を使用することをお勧めします。相互運用性を高めるために、セクション7.1で説明したように、特に、charsetパラメータは、同じ方法で使用されるべきです。
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.
text / xmlまたはapplication / xmlとしてラベル付けされたXMLドキュメントは、スタイルシート・リンク処理命令（PIの）、スキーマ情報、または文書がどのように処理されるかを提案するために使用されるかもしれない他の宣言を名前空間宣言が含まれる場合があります。例えば、文書はXHTML名前空間とCSSスタイルシートへの参照を持っているかもしれません。このような文書は、適切な処理のために文書を派遣するためにこの情報を使用するアプリケーションによって処理される可能性があります。
MIME media type name: text
MIMEメディアタイプ名：テキスト
MIME subtype name: xml
MIMEサブタイプ名：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 MIME entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP. "utf-8" [RFC2279] is the recommended value, representing the UTF-8 charset. UTF-8 is supported by all conforming processors of [XML].
オプションのパラメータとして記載されているが、この情報は、権威のXML MIMEエンティティの文字エンコーディングを決定するために、XMLプロセッサによって使用することができるので、文字セットパラメータを使用することが強く推奨されます。 charsetパラメータはまた、HTTPのcharsetベースのコンテンツネゴシエーションなどのプロトコル固有の操作を提供するために使用することができます。 "UTF-8" [RFC2279]はUTF-8文字セットを表す、推奨値です。 UTF-8は、[XML]の全て準拠プロセッサによってサポートされています。
If the XML 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 [RFC2616]), "utf-16" [RFC2781]) is also recommended. UTF-16 is supported by all conforming processors 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 text/xml; charset="utf-16" to application/xml; charset="utf-16".
XMLのMIMEエンティティは、テキストのトップレベルタイプの制限から免除されMIMEのようなメカニズムを使用してHTTPを介して送信される場合（[RFC2616]のセクション19.4.1を参照）、「UTF-16」[RFC2781] ）もお勧めします。 UTF-16は、[XML]のすべての適合プロセッサーでサポートされています。ほとんどのMIMEアプリケーションにおけるテキストタイプのためのCR、LFとNULの取り扱いはUTF-16のマルチオクテット文字で個々のオクテットの望ましくない変形を引き起こすので、HTTPからこれらのMIMEアプリケーションへのゲートウェイは、テキスト/ XMLからXMLのMIMEエンティティを変換する必要があります。アプリケーション/ XMLへのcharset = "UTF-16"。文字セット= "UTF-16"。
Conformant with [RFC2046], 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"[ASCII]. In cases where the XML MIME entity is transmitted via HTTP, the default charset value is still "us-ascii". (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.)
MIMEプロセッサおよびXMLプロセッサ、[RFC2046]に準拠し、text / xmlでエンティティを省略charsetパラメータで受信されている場合は、[ASCII]「US-ASCII」のデフォルトの文字セット値を使用しなければなりません。 XMLのMIMEエンティティは、HTTPを介して送信される場合には、デフォルトのcharset値はまだ「US-ASCII」です。 （注：歴史的理由のためにデフォルトとしてISO-8859-1 [ISO8859]を使用し、本明細書及びHTTP / 1.1との間の矛盾は、あるXMLは、新しいフォーマットであるため、新たなデフォルトが良いI18Nのために選択されるべきです。それはUTF-8とISO-8859-1の交点であるため、それがすでにMIMEで使用されているので、US-ASCIIは、選ばれました。）
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.
charsetパラメータが権限を持っていることをいくつかの理由があります。まず、いくつかのMIME処理エンジンは、内部コンテンツのいずれかに言及することなく、トップレベルのメディアタイプ「テキスト」のMIMEボディのトランスコーディングを行います。このように、いくつかのエージェントは、テキスト/ XMLを変えるかもしれないことは可能です。文字セット= "ISO-2022-JP" text / xmlであり; charset =「UTF-8」XML文書のエンコーディング宣言を変更せず。テキスト/ XMLを理解していないMIMEエージェントはtext / plainのようにそれを扱うにフォールバックするので、第二に、text / xmlではtext / plainで、と互換性がなければなりません。テキスト/ XMLのcharsetパラメータが権威でなかった場合は、そのようなフォールバックは、データの破損を引き起こします。ユーザーはcharsetパラメータを指定することができるように第三に、最近のWebサーバは改善されました。第四に、[RFC2130]は、推奨スペック方式は、「文字セット」のパラメータであることを指定します。
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 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 MIME entity.
charsetパラメータが権威あるので、文字セットは常にXMLエンコーディング宣言内で宣言されていません。受信者は、（ファイルシステムでは、例えば）MIMEヘッダを取り除き、受信したXML MIMEエンティティの永続ストレージを提供する場合したがって、特別な注意が必要です。文字セットは、UTF-8やUTF-16でない限り、受信者はまた、持続的おそらくXMLのMIMEエンティティ内正しいXMLエンコーディング宣言を埋め込むことにより、文字セットについての情報を格納する必要があります。
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 UTF-8 MUST be encoded in quoted-printable or base64. For 8-bit clean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP[RFC0977]), UTF-8 does not need to be encoded. Over HTTP[RFC2616], no content-transfer-encoding is necessary and UTF-16 may also be used.
エンコードの考慮事項：このメディアタイプは、文字セットと基盤となるMIME輸送の能力に応じて符号化することができます。 7ビットのトランスポートのために、UTF-8のデータは、quoted-printable形式またはBASE64でエンコードされなければなりません。 8ビットクリーンな輸送のため（例えば、8BITMIME [RFC1652] ESMTPまたはNNTP [RFC0977]）、UTF-8でエンコードする必要がありません。 HTTP [RFC2616]上、何らコンテンツ転送符号化が必要でなく、UTF-16を使用してもよいです。
Security considerations: See Section 10.
セキュリティの考慮事項：第10節を参照してください。
Interoperability considerations: XML has proven to be interoperable across WebDAV clients and servers, and for import and export from multiple XML authoring tools. 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].
相互運用性に関する注意事項：XMLは、と複数のXMLオーサリングツールからインポートおよびエクスポートのためのWebDAVクライアントとサーバー間で相互運用可能であることが判明しました。最大の相互運用性のため、有効プロセッサが推奨されています。非検証プロセッサは、より効率的かもしれないが、彼らは、XMLのすべての機能を処理するために必要とされていません。詳細については、サブセクション2.9「スタンドアロン文書宣言」及び[XML]のセクション5「適合」を参照してください。
Published specification: Extensible Markup Language (XML) 1.0 (Second Edition)[XML].
公開された仕様：拡張マークアップ言語（XML）1.0（第二版）[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.
このメディアタイプを使用するアプリケーション：XMLは、デバイスにある、プラットフォーム、およびベンダー中立とWebユーザーエージェントの広い範囲でサポートされ、WebDAVの[RFC2518]クライアントとサーバだけでなく、XMLオーサリングツール。
Additional information:
追加情報：
Magic number(s): None.
マジックナンバー（S）：なし。
Although no byte sequences can be counted on to always be present, XML MIME 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 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 [XML].
何のバイト配列は常に存在することでカウントすることはできないが、（UTF-8を含む）ASCII互換文字セットのXML MIMEエンティティは、多くの場合、UTF-16のもの進3C 3F 78 6D 6C（「<？xmlの」）で始まり、しばしば進数FE FF 00 3C 00 3F 00 78 00 6D 00 6Cか（ "<？xml" で続くバイトオーダーマーク（BOM））FF FE 3C 00 3F 00 78 00 6D 00 6C 00で始まります。詳細については、[XML]の付録Fを参照してください。
File extension(s): .xml
ファイルの拡張子（S）：.xmlファイル
Macintosh File Type Code(s): "TEXT"
Macintoshのファイルタイプコード（S）： "TEXT"
Person and email address for further information:
詳しくは、人とEメールアドレス：
MURATA Makoto (FAMILY Given) <mmurata@trl.ibm.co.jp>
村田誠（FAMILY考える）<mmurata@trl.ibm.co.jp>
Simon St.Laurent <simonstl@simonstl.com>
サイモンSt.Laurent <simonstl@simonstl.com>
Daniel Kohn <dan@dankohn.com>
ダニエル・コーン<dan@dankohn.com>
Intended usage: COMMON
意図している用法：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:
著者/変更コントローラは：XMLの仕様は、World Wide Web ConsortiumのXMLワーキンググループの成果物である、とによって編集されました。
Tim Bray <tbray@textuality.com>
ティム・ブレイ<tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
ジーン・パオリ<jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
C. M. Sperberg-マックイーン<cmsmcq@uic.edu>
Eve Maler <eve.maler@east.sun.com>
イブMALER <eve.maler@east.sun.co I>
The W3C, and the W3C XML Core Working Group, have change control over the XML specification.
W3C、およびW3C XMLコアワーキンググループは、XML仕様の切換制御を持っています。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: xml
MIMEサブタイプ名：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 MIME entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP.
オプションのパラメータとして記載されているが、この情報は、権威のXML MIMEエンティティの文字セットを決定するために、XMLプロセッサによって使用することができるので、文字セットパラメータを使用することが強く推奨されます。 charsetパラメータはまた、HTTPのcharsetベースのコンテンツネゴシエーションなどのプロトコル固有の操作を提供するために使用することができます。
"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 processors of [XML].
"UTF-8" [RFC2279]及び "UTF-16" [RFC2781]は、それぞれ、UTF-8およびUTF-16文字セットを表す、推奨値です。彼らは[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 [XML] that directly address this contingency. However, MIME processors that are not XML processors SHOULD NOT assume a default charset if the charset parameter is omitted from an application/xml entity.
charsetパラメータが省略された場合、アプリケーション/ XMLエンティティが受信した場合、何の情報がMIME Content-Typeヘッダによって文字セットについて提供されていません。 XMLプロセッサを適合することは、直接、この不測のアドレス[XML]のセクション4.3.3の要求に従わなければなりません。 charsetパラメータは、アプリケーション/ XMLエンティティから省略されている場合は、XMLプロセッサではありませんMIMEプロセッサは、デフォルトの文字セットを仮定するべきではありません。
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.
charsetパラメータが権限を持っていることをいくつかの理由があります。ユーザーはcharsetパラメータを指定することができるようにまず、最近のWebサーバは改善されました。第二に、[RFC2130]は、推奨スペック方式は、「文字セット」のパラメータであることを指定します。
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.
一方、文字セットパラメータが省略されるべきであると主張されており、[XML]（非規範的である）の付録Fに記載の機構は、単独に依存すべきです。このアプローチでは、ユーザーがcharsetパラメータの設定を避けるためにできるようになります。ファイルに格納されたXML文書は、オペレーティング・システムは、典型的には、ファイルのための文字セット情報を提供しないので、（必要に応じて）正しいエンコーディング宣言またはBOMが含まれている可能性があります。ユーザーはエンコーディング宣言またはBOMに依存するとプロトコルから文字コード情報を非表示にしたい場合は、パラメータを使用しないように決定することができます。
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 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 MIME entity.
charsetパラメータが権威あるので、文字セットは常にXMLエンコーディング宣言内で宣言されていません。受信者は、（ファイルシステムでは、例えば）MIMEヘッダを取り除き、受信したXML MIMEエンティティの永続ストレージを提供する場合したがって、特別な注意が必要です。文字セットは、UTF-8やUTF-16でない限り、受信者はまた、持続的おそらくXMLのMIMEエンティティ内正しいXMLエンコーディング宣言を埋め込むことにより、文字セットについての情報を格納する必要があります。
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 either UTF-8 or UTF-16 MUST be encoded in quoted-printable or base64. For 8-bit clean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP[RFC0977]), UTF-8 is not encoded, but the UTF-16 family MUST be encoded in base64. For binary clean transports (e.g., HTTP[RFC2616]), no content-transfer-encoding is necessary.
エンコードの考慮事項：このメディアタイプは、文字セットと基盤となるMIME輸送の能力に応じて符号化することができます。 7ビットのトランスポートのために、UTF-8やUTF-16のいずれかのデータが引用され、印刷可能なまたはBASE64でエンコードされなければなりません。 8ビットクリーン搬送のために（例えば、8BITMIME [RFC1652] ESMTPまたはNNTP [RFC0977]）は、UTF-8でエンコードされず、UTF-16ファミリーは、base64で符号化されなければなりません。バイナリクリーントランスポート（例えば、HTTP [RFC2616]）のために、何のコンテンツ転送符号化は不要です。
Security considerations: See Section 10.
セキュリティの考慮事項：第10節を参照してください。
Interoperability considerations: Same as Section 3.1.
相互運用性に関する注意事項：3.1節と同じ。
Published specification: Same as Section 3.1.
公開された仕様：3.1節と同じ。
Applications which use this media type: Same as Section 3.1.
このメディアタイプを使用するアプリケーション：3.1節と同じ。
Additional information: Same as Section 3.1.
追加情報：3.1節と同じ。
Person and email address for further information: Same as Section 3.1.
詳しくは、人とEメールアドレス：3.1節と同じ。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Same as Section 3.1.
著者/変更コントローラ：3.1節と同じ。
MIME media type name: text
MIMEメディアタイプ名：テキスト
MIME subtype name: xml-external-parsed-entity
MIMEサブタイプ名：XML-外部解析されたエンティティ
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.
セクション3.1で説明したように、テキスト/ XMLの外部の構文解析済みエンティティのcharsetパラメータは、テキスト/ XMLのと同様に処理されます。
Encoding considerations: Same as Section 3.1.
エンコードの考慮事項：3.1節と同じ。
Security considerations: See Section 10.
セキュリティの考慮事項：第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.
相互運用性の考慮事項：彼らはあまりしっかりと拘束された構造を有しているので、XMLプロセッサによって適切に処理するためのXML文書によって参照される必要があるものの、XML外部解析対象実体は、XML文書のように相互運用が可能です。外部解析対象実体は、スタンドアロン文書宣言やDTDを持っていることから禁止されているので、同様に、XML文書は確実に外部解析対象実体として使用することはできません。独自のコンテンツタイプとXML外部解析対象実体を識別することは、XMLドキュメントとXML外部解析対象実体の両方の相互運用性を向上させる必要があります。
Published specification: Same as Section 3.1.
公開された仕様：3.1節と同じ。
Applications which use this media type: Same as Section 3.1.
このメディアタイプを使用するアプリケーション：3.1節と同じ。
Additional information:
追加情報：
Magic number(s): Same as Section 3.1.
マジックナンバー（S）：3.1節と同じ。
File extension(s): .xml or .ent
ファイルの拡張子（S）：.xmlファイルまたは.ent
Macintosh File Type Code(s): "TEXT"
Macintoshのファイルタイプコード（S）： "TEXT"
Person and email address for further information: Same as Section 3.1.
詳しくは、人とEメールアドレス：3.1節と同じ。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Same as Section 3.1.
著者/変更コントローラ：3.1節と同じ。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: xml-external-parsed-entity
MIMEサブタイプ名：XML-外部解析されたエンティティ
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.
セクション3.2で説明したように、アプリケーション/ XMLの外部の構文解析済みエンティティのcharsetパラメータは、アプリケーション/ XMLのと同様に処理されます。
Encoding considerations: Same as Section 3.2.
エンコードの考慮事項：3.2節と同じ。
Security considerations: See Section 10.
セキュリティの考慮事項：第10節を参照してください。
Interoperability considerations: Same as those for text/xml-external-parsed-entity as described in Section 3.3.
相互運用性に関する注意事項：3.3節で説明したようにtext / xmlで、外部解析されたエンティティのためのものと同じ。
Published specification: Same as text/xml as described in Section 3.1.
公開された仕様：3.1節で説明したように、テキスト/ xmlのと同じです。
Applications which use this media type: Same as Section 3.1.
このメディアタイプを使用するアプリケーション：3.1節と同じ。
Additional information:
追加情報：
Magic number(s): Same as Section 3.1.
マジックナンバー（S）：3.1節と同じ。
File extension(s): .xml or .ent
ファイルの拡張子（S）：.xmlファイルまたは.ent
Macintosh File Type Code(s): "TEXT"
Macintoshのファイルタイプコード（S）： "TEXT"
Person and email address for further information: Same as Section 3.1.
詳しくは、人とEメールアドレス：3.1節と同じ。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Same as Section 3.1.
著者/変更コントローラ：3.1節と同じ。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: xml-dtd
MIMEサブタイプ名：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.
セクション3.2で説明したように、アプリケーション/ XML-DTDのcharsetパラメータは、アプリケーション/ XMLのと同様に処理されます。
Encoding considerations: Same as Section 3.2.
エンコードの考慮事項：3.2節と同じ。
Security considerations: See Section 10.
セキュリティの考慮事項：第10節を参照してください。
Interoperability considerations: XML DTDs have proven to be interoperable by DTD authoring tools and XML browsers, among others.
相互運用性に関する注意事項：XMLのDTDは、とりわけ、DTDオーサリングツールとXMLブラウザで相互運用可能であることが判明しています。
Published specification: Same as text/xml as described in Section 3.1.
公開された仕様：3.1節で説明したように、テキスト/ xmlのと同じです。
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.
DTDオーサリングツールは、外部DTDサブセットだけでなく、外部パラメータ実体を扱う：このメディアタイプを使用するアプリケーション。 XMLブラウザは、外部DTDサブセット及び外部パラメタ実体にアクセスすることができます。
Additional information:
追加情報：
Magic number(s): Same as Section 3.1.
マジックナンバー（S）：3.1節と同じ。
File extension(s): .dtd or .mod
ファイルの拡張子（S）：.DTDかの.mod
Macintosh File Type Code(s): "TEXT"
Macintoshのファイルタイプコード（S）： "TEXT"
Person and email address for further information: Same as Section 3.1.
詳しくは、人とEメールアドレス：3.1節と同じ。
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: Same as Section 3.1.
著者/変更コントローラ：3.1節と同じ。
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:
以下のリストは、トップレベルタイプこの仕様に従ってcharsetパラメータを定義する「テキスト」の下のテキスト/ XML、テキスト/ XMLの外部の構文解析済みエンティティ、およびXMLベースのメディアタイプに適用されます。
o Charset parameter is strongly recommended.
O charsetパラメータを強くお勧めします。
o If the charset parameter is not specified, the default is "us-ascii". The default of "iso-8859-1" in HTTP is explicitly overridden.
charsetパラメータが指定されていない場合は、O、デフォルトは「US-ASCII」です。 HTTPで、「ISO-8859-1」のデフォルトは、明示的に上書きされます。
o No error handling provisions.
Oエラーが規定を取り扱いません。
o An encoding declaration, if present, is irrelevant, but when saving a received resource as a file, the correct encoding declaration SHOULD be inserted.
Oエンコーディング宣言は、存在する場合、無関係であるが、ファイルとして受信されたリソースを保存するとき、正しいエンコーディング宣言が挿入されます。
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パラメータを定義する「テキスト」以外のトップレベルタイプの下でアプリケーション/ XML、アプリケーション/ XMLの外部の構文解析済みエンティティ、アプリケーション/ XML-DTD、およびXMLベースのメディアタイプに適用されます：
o Charset parameter is strongly recommended, and if present, it takes precedence.
O charsetパラメータが強く推奨され、存在する場合、それが優先されます。
o If the charset parameter is omitted, conforming XML processors MUST follow the requirements in section 4.3.3 of [XML].
charsetパラメータが省略された場合、O、準拠XMLプロセッサは、[XML]のセクション4.3.3の要求に従わなければなりません。
Section 4.3.3 of [XML] specifies that XML MIME entities in the charset "utf-16" MUST begin with a byte order mark (BOM), which is a hexadecimal octet sequence 0xFE 0xFF (or 0xFF 0xFE, 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.
[XML]のセクション4.3.3には、文字セット「UTF-16」のXML MIMEエンティティは（エンディアンに応じて、または0xFFで0xFEの）進オクテットシーケンス0xFEの0xFFであるバイト順マーク（BOM）で始まらなければならないことを指定します。 XML勧告は、さらに、BOMは、符号化署名であり、マークアップまたはXML文書の文字データのいずれかの一部ではないことを述べています。
Due to the presence of the BOM, applications that convert XML from "utf-16" to a non-Unicode encoding MUST strip the BOM before conversion. Similarly, when converting from another encoding into "utf-16", the BOM MUST be added after conversion is complete.
BOMが存在するため、非Unicodeエンコーディングに「UTF-16」からXMLを変換するアプリケーションは、変換前のBOMを削除しなければなりません。 「UTF-16」に別の符号化から変換するときの変換が完了した後、同様に、BOMを追加する必要があります。
In addition to the charset "utf-16", [RFC2781] introduces "utf-16le" (little endian) and "utf-16be" (big endian) as well. The BOM is prohibited for these charsets. When an XML MIME entity is encoded in "utf-16le" or "utf-16be", it MUST NOT begin with the BOM but SHOULD contain an encoding declaration. Conversion from "utf-16" to "utf-16be" or "utf-16le" and conversion in the other direction MUST strip or add the BOM, respectively.
文字セット "UTF-16"、[RFC2781]に加えて、同様に "UTF-16LE"（リトルエンディアン）と "UTF-16BE"（ビッグエンディアン）を導入します。 BOMは、これらの文字セットのために禁止されています。 XMLのMIMEエンティティが「UTF-16LE」または「UTF-16BE」でエンコードされている場合、それはBOMで始めてはいけませんが、エンコードの宣言を含むべきです。他の方向に「UTF-16BE」から「UTF-16」から変換または「UTF-16LE」、変換は、それぞれ、BOMを削除または追加しなければなりません。
Section 4.1 of [RFC2396] notes that the semantics of a fragment identifier (the part of a URI after a "#") is a property of the data resulting from a retrieval action, and that the format and interpretation of fragment identifiers is dependent on the media type of the retrieval result.
[RFC2396]のセクション4.1は、フラグメント識別子（「＃」の後にURIの一部）のセマンティクスが検索行動から生じるデータの特性であり、フラグメント識別子のフォーマット及び解釈は、に依存することと指摘します検索結果のメディアタイプ。
As of today, no established specifications define identifiers for XML media types. However, a working draft published by W3C, namely "XML Pointer Language (XPointer)", attempts to define fragment identifiers for text/xml and application/xml. The current specification for XPointer is available at http://www.w3.org/TR/xptr.
今日の時点で、確立されない仕様はXMLのメディアタイプの識別子を定義します。しかし、ワーキングドラフトは、W3Cによって公開され、すなわち「XMLポインタ言語（XPointerの）」、text / xmlで、アプリケーション/ XMLのフラグメント識別子を定義しようとします。 XPointerのための現在の仕様はhttp://www.w3.org/TR/xptrで入手可能です。
Section 5.1 of [RFC2396] specifies that the semantics of a relative URI reference embedded in a MIME entity is dependent on the base URI. The base URI is either (1) the base URI embedded in the MIME entity, (2) the base URI of the encapsulating MIME entity, (3) the URI used to retrieve the MIME entity, or (4) the application-dependent default base URI, where (1) has the highest precedence. [RFC2396] further specifies that the mechanism for embedding the base URI is dependent on the media type.
[RFC2396]のセクション5.1は、MIMEエンティティに埋め込まれた相対URI参照のセマンティクスは、ベースURIに依存していることを指定します。ベースURIは、MIMEエンティティに埋め込まれた（1）ベースURI、封入MIMEエンティティの（2）ベースURI、（3）URIは、MIMEエンティティを取得するために使用される、または（4）アプリケーションに依存するデフォルトのいずれかであります（1）最も高い優先順位を有するベースURI、。 [RFC2396]は、ベースを埋め込むためのメカニズムはURIがメディアタイプに依存していることを指定します。
As of today, no established specifications define mechanisms for embedding the base URI in XML MIME entities. However, a Proposed Recommendation published by W3C, namely "XML Base", attempts to define such a mechanism for text/xml, application/xml, text/xml-external-parsed-entity, and application/xml-external-parsed-entity. The current specification for XML Base is available at http://www.w3.org/TR/xmlbase.
今日の時点で、確立されない仕様は、XML MIMEエンティティ内のベースURIを埋め込むためのメカニズムを定義します。しかし、W3Cにより公開された勧告案は、すなわち、「XMLベース」は、text / xmlで、アプリケーション/ XML、テキスト/ XMLの外部の構文解析済みエンティティのようなメカニズムを定義しようとすると、アプリケーション/ XMLの外部の構文解析済みエンティティ。 XMLベースの現在の仕様では、http://www.w3.org/TR/xmlbaseで入手可能です。
This document recommends the use of a naming convention (a suffix of '+xml') for identifying XML-based MIME media types, whatever their particular content may represent. This allows the use of generic XML processors and technologies on a wide variety of different XML document types at a minimum cost, using existing frameworks for media type registration.
この文書は、それらの特定のコンテンツを表すことができるものは何でも、XMLベースのMIMEメディアタイプを識別するための命名規則（「+ XML」の接尾語）を使用することをお勧めします。これは、メディアタイプ登録のための既存の枠組みを使用して、最小限のコストで異なるXMLドキュメントタイプの多種多様で、一般的なXMLプロセッサやテクノロジを使用することができます。
Although the use of a suffix was not considered as part of the original MIME architecture, this choice is considered to provide the most functionality with the least potential for interoperability problems or lack of future extensibility. The alternatives to the ' +xml' suffix and the reason for its selection are described in Appendix A.
接尾辞の使用は、元のMIMEアーキテクチャの一部として考慮されなかったが、この選択は、相互運用性の問題や将来の拡張性の欠如のための最も可能性のあるほとんどの機能を提供すると考えられています。 「+ xmlの」接尾辞とその選択の理由に選択肢は付録Aに記載されています
As XML development continues, new XML document types are appearing rapidly. Many of these XML document types would benefit from the identification possibilities of a more specific MIME media type than text/xml or application/xml can provide, and it is likely that many new media types for XML-based document types will be registered in the near and ongoing future.
XML開発が続くと、新しいXMLドキュメントの種類は急速に登場しています。これらのXMLドキュメントタイプの多くは、テキスト/ xmlまたは提供することができるアプリケーション/ xmlのより具体的なMIMEメディアタイプの識別可能性から利益を得るであろう、そしてXMLベースのドキュメントタイプのための多くの新しいメディアタイプはに登録される可能性があります近いと継続的な未来。
While the benefits of specific MIME types for particular types of XML documents are significant, all XML documents share common structures and syntax that make possible common processing.
XML文書の特定の種類の特定のMIMEタイプの利点は重要ですが、すべてのXML文書は、可能な共通の処理を行い、共通の構造と構文を共有しています。
Some areas where 'generic' processing is useful include:
「一般的な」処理が有用である一部の地域では、次のとおりです。
o Browsing - An XML browser can display any XML document with a provided [CSS] or [XSLT] style sheet, whatever the vocabulary of that document.
Oブラウジング - XMLのブラウザが提供する[CSS]または[XSLT]スタイルシートで任意のXML文書は、その文書のどのような語彙を表示することができます。
o Editing - Any XML editor can read, modify, and save any XML document.
O編集 - 任意のXMLエディタは、読み取り、変更、および任意のXMLドキュメントを保存することができます。
o Fragment identification - XPointers (work in progress) can work with any XML document, whatever vocabulary it uses and whether or not it uses XPointer for its own fragment identification.
O断片識別 - XPointers（進行中の作業）は、使用してそれ自身の断片識別のためのXPointerを使用するか否かをどの語彙、任意のXML文書で作業することができます。
o Hypertext linking - XLink (work in progress) hypertext linking is designed to connect any XML documents, regardless of vocabulary.
Oハイパーテキストリンク - XLinkの（作業中）ハイパーテキストリンクは関係なく、語彙の、任意のXML文書を接続するように設計されています。
o Searching - XML-oriented search engines, web crawlers, agents, and query tools should be able to read XML documents and extract the names and content of elements and attributes even if the tools are ignorant of the particular vocabulary used for elements and attributes.
Oによる検索 - XML指向の検索エンジン、ウェブクローラ、エージェント、およびクエリツールは、XML文書を読み込み、要素の名前と内容を抽出し、ツールは要素と属性のために使用される特定の語彙の無知であっても、属性をすることができるはずです。
o Storage - XML-oriented storage systems, which keep XML documents internally in a parsed form, should similarly be able to process, store, and recreate any XML document.
Oストレージ - 解析された形で、内部でXML文書を保つXML指向のストレージシステムは、同様に処理することができるはず、店舗、および任意のXMLドキュメントを再作成します。
o Well-formedness and validity checking - An XML processor can confirm that any XML document is well-formed and that it is valid (i.e., conforms to its declared DTD or Schema).
O適格性と妥当性検査 - XMLプロセッサは、任意のXML文書が整形式であり、それは（すなわち、その宣言DTDまたはスキーマに準拠）有効であることをことを確認することができます。
When a new media type is introduced for an XML-based format, the name
of the media type SHOULD end with '+xml'. This convention will allow
applications that can process XML generically to detect that the MIME
entity is supposed to be an XML document, verify this assumption by
invoking some XML processor, and then process the XML document
accordingly. Applications may match for types that represent XML
MIME entities by comparing the subtype to the pattern '*/*+xml'. (Of
course, 4 of the 5 media types defined in this document -- text/xml,
application/xml, text/xml-external-parsed-entity, and
application/xml-external-parsed-entity -- also represent XML MIME
entities while not conforming to the '*/*+xml' pattern.)
NOTE: Section 14.1 of HTTP[RFC2616] does not support Accept
headers of the form "Accept: */*+xml" and so this header MUST NOT
be used in this way. Instead, content negotiation[RFC2703] could
potentially be used if an XML-based MIME type were needed.
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.
XMLの一般的な処理は、常にXMLベースのメディアタイプのために適切ではありません。例えば、そのようないくつかのメディアタイプの作者は、種類は特にそのメディアタイプに対処するために設計されたアプリケーションを除いて完全に不透明なままであることを望むかもしれません。命名規則「+ XML」を次しないことによって、そのようなメディアタイプは、XML-一般的な処理を回避することができます。一般的な処理は、多くの場合に有用であろうので、しかし - 事前に予測することは困難である状況に含めて - 彼らはしないように、特に魅力的な理由がない限り、これらの登録メディアタイプは「+ xmlの」規則を使用すべきです。
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 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.
これらのメディアタイプのための登録プロセスは、[RFC2048]に記載されています。 IETFツリーのレジストラは、このガイドラインに従うことをIETFツリーに新しいXMLベースのメディアタイプの登録を奨励します。他の木のためのレジストラは、そのXMLベースのドキュメントの最大の相互運用性を確保するために、この規則に従ってください。同様に、XMLのMIMEエンティティを表すものではありませんメディアサブタイプは「+ xmlの」接尾辞に登録することを許してはなりません。
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."
RFCに指定されている「text / xmlでの[charsetパラメータ/エンコーディングの考慮]と同じ：トップレベルのタイプ「テキスト」の下に新しいXMLベースのメディアタイプの登録は、charsetパラメータとエンコーディングの考慮を指定するには、としてそれらを定義する必要があります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."
に指定されている「アプリケーション/ XMLのと同じように[charsetパラメータ/エンコーディングの考慮]：「テキスト」は、charsetパラメータとエンコーディングの考慮を指定するには、としてそれらを定義する必要があります以外のトップレベルのタイプの下に新しいXMLベースのメディアタイプの登録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.
この情報は、権威のXML MIMEエンティティの文字セットを決定するために、XMLプロセッサによって使用することができるので、文字セットパラメータを使用することが強く推奨されます。
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.
これらの登録は、登録されているXMLベースのメディアタイプは、RFC 3023で説明されているセキュリティの考慮事項に加えて、そのメディアタイプに固有の追加の考慮事項のすべてを持っていることを指定する必要があります。
These registrations SHOULD also make reference to RFC 3023 in specifying magic numbers, fragment identifiers, base URIs, and use of the BOM.
これらの登録もマジックナンバー、フラグメント識別子、基底URI、およびBOMの使用を指定するにはRFC 3023への参照を行う必要があります。
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.
これらの考慮事項は、そのメディアタイプに固有の問題で上書きされていない場合、これらの登録は、相互運用性の考慮事項を指定するにはRFC 3023にtext / xmlでの登録を参照してもよいです。
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.
以下の例は、XML MIME実体内部MIME Content-Typeヘッダの値と（エンコーディング宣言を含む）XML宣言を与えます。 UTF-16例については、バイトオーダーマーク文字は、「{} BOM」と表記されており、XML宣言はすぐにBOMを以下、XMLのMIME実体の初めに来ると想定されます。他のMIMEヘッダが存在してもよく、およびXML MIMEエンティティは、XML宣言に加えて、他のデータを含んでいてもよいことに留意されたいです。例としては、Content-Typeヘッダおよび明確にするためにエンコーディング宣言に焦点を当てます。
Content-type: text/xml; charset="utf-8"
コンテンツタイプ：text / xmlで、 charset = "UTF-8" を
<?xml version="1.0" encoding="utf-8"?>
<？xml version = "1.0" エンコード= "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.
これは、text / xmlでの使用のために推奨されるcharset値です。 charsetパラメータが設けられているため、MIMEおよびXMLプロセッサは、UTF-8でエンコードされたように封入されたエンティティを処理しなければなりません。
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.
7ビットの輸送（例えば、SMTP [RFC0821]）を使用して送信された場合は、XMLのMIMEエンティティは、引用された、印刷可能なまたはBASE64のいずれかのコンテンツ転送符号化を使用しなければなりません。 8ビットクリーン輸送（例えば、8BITMIME ESMTPまたはNNTP）、またはバイナリクリーントランスポート（例えば、HTTP）のために、何のコンテンツ転送符号化は不要です。
Content-type: text/xml; charset="utf-16"
コンテンツタイプ：text / xmlで、文字セット= "UTF-16"
{BOM}<?xml version='1.0' encoding='utf-16'?>
{BOM} <？XMLバージョン= '1.0' エンコーディング= 'UTF-16'？>
or
または
{BOM}<?xml version='1.0'?>
{BOM} <？XMLバージョン= '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).
これは、XML MIMEエンティティがMIMEのようなメカニズムを使用してバイナリクリーンプロトコルであるHTTPを介して送信された場合にのみ可能であり、したがってCRやLF変換を実行し、NULオクテットを可能にしません。 [RFC2781]に記載されているように、UTF-16ファミリーは、HTTP上を除くトップレベルタイプ「テキスト」の下にメディアタイプと一緒に使用してはいけません（詳細については[RFC2616]のセクション19.4.1を参照されたいです）。
Since HTTP is binary clean, no content-transfer-encoding is necessary.
HTTPはバイナリクリーンであるので、何のコンテンツ転送符号化は不要です。
Content-type: text/xml; charset="utf-16be"
コンテンツタイプ：text / xmlで、文字セット= "UTF-16BE"
<?xml version='1.0' encoding='utf-16be'?>
<？xmlのバージョン= '1.0' エンコード= 'UTF-16BE'？>
Observe that the BOM does not exist. This is again possible only when the XML MIME entity is transmitted via HTTP.
BOMが存在しないことを確認します。これは、XML MIMEエンティティはHTTPを介して送信されている場合にのみ再び可能です。
Content-type: text/xml; charset="iso-2022-kr"
コンテンツタイプ：text / xmlで、文字セット= "ISO-2022-KR"
<?xml version="1.0" encoding='iso-2022-kr'?>
<？xml version = "1.0" エンコード= '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.
この例では[RFC1557]で指定次の符号化された韓国語文字セット（例えば、ハングル）のテキスト/ XMLを示しています。 charsetパラメータが設けられているため、RFC 1557ごとに符号化されるように、MIMEおよびXMLプロセッサは、囲まれたエンティティを扱わなければなりません。
Since ISO-2022-KR has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport.
ISO-2022-KRは、データの7ビットだけを使用するように定義されているので、何のコンテンツ転送符号化は、任意のトランスポートを持つ必要はありません。
Content-type: text/xml
コンテンツタイプ：text / xmlで
{BOM}<?xml version="1.0" encoding="utf-16"?>
{BOM}の<？xml version = "1.0" エンコード= "UTF-16"？>
or
または
{BOM}<?xml version="1.0"?>
{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.
この例では省略charsetパラメータを使用してテキスト/ XMLを示しています。この場合、MIMEおよびXMLプロセッサは、文字セットが「US-ASCII」、[RFC2046]で指定したテキストメディアタイプのデフォルトのcharset値である仮定しなければなりません。 「US-ASCII」のデフォルトはtext / xmlのエンティティは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".
charsetパラメータを省略すると、text / xmlでは推奨されません。例えば、XMLのMIME実体の内容は、UTF-16またはUTF-8である、またはXML MIMEエンティティは、明示的なエンコーディング宣言、XMLとMIMEプロセッサであっても文字セットが「US-ASCII」であると仮定しなければなりません。
Content-type: application/xml; charset="utf-16"
コンテンツタイプ：アプリケーション/ xmlの;文字セット= "UTF-16"
{BOM}<?xml version="1.0" encoding="utf-16"?>
{BOM}の<？xml version = "1.0" エンコード= "UTF-16"？>
or
または
{BOM}<?xml version="1.0"?>
{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.
これは、アプリケーション/ XMLで使用するための推奨charset値です。 charsetパラメータが設けられているため、MIMEおよびXMLプロセッサは、UTF-16エンコードされたように封入されたエンティティを処理しなければなりません。
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.
7ビットの輸送（例えば、SMTP）または8ビットクリーン輸送（例えば、8BITMIME ESMTPまたはNNTP）を使用して送信された場合は、XMLのMIMEエンティティは、引用された、印刷可能なまたはBASE64でエンコードされなければなりません。バイナリクリーン輸送（例えば、HTTP）のために、何のコンテンツ転送符号化は不要です。
Content-type: application/xml; charset="utf-16be"
コンテンツタイプ：アプリケーション/ xmlの;文字セット= "UTF-16BE"
<?xml version='1.0' encoding='utf-16be'?>
<？xmlのバージョン= '1.0' エンコード= '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.
BOMが存在しないことを確認します。 charsetパラメータが設けられているのでUTF-16BEエンコードとして、MIMEおよびXMLプロセッサは、囲まれたエンティティを扱わなければなりません。
Content-type: application/xml; charset="iso-2022-kr"
コンテンツタイプ：アプリケーション/ xmlの;文字セット= "ISO-2022-KR"
<?xml version="1.0" encoding="iso-2022-kr"?>
<？xml version = "1.0" エンコード= "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).
この例では[RFC1557]で指定次の符号化された韓国語文字セット（例えば、ハングル）を使用してアプリケーション/ XMLを示しています。 charsetパラメータが設けられているため、RFC 1557ごとに符号化されるように、MIMEおよびXMLプロセッサは、XML MIMEエンティティは、内部エンコーディング宣言を持っているかどうかとは無関係に、封入されたエンティティを治療する必要があります（この例では、charsetパラメータと一致するような宣言を、示してい） 。
Since ISO-2022-KR has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport.
ISO-2022-KRは、データの7ビットだけを使用するように定義されているので、何のコンテンツ転送符号化は、任意のトランスポートを持つ必要はありません。
Content-type: application/xml
コンテンツタイプ：アプリケーション/ xmlの
{BOM}<?xml version='1.0' encoding="utf-16"?>
{BOM} <？XMLバージョン= '1.0' エンコード= "UTF-16"？>
or
または
{BOM}<?xml version='1.0'?>
{BOM} <？XMLバージョン= '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.
この例では、XMLのMIMEエンティティは、BOMで始まります。文字セットが省略されているので、準拠XMLプロセッサは、[XML]の要件、セクション4.3.3に従います。具体的には、XMLプロセッサはBOMを読み取り、こうして文字セットがUTF-16で確定することを知っています。
An XML-unaware MIME processor SHOULD make no assumptions about the charset of the XML MIME entity.
XML-気づかないMIMEプロセッサは、XML MIMEエンティティの文字セットについての仮定を行うべきではありません。
Content-type: application/xml
コンテンツタイプ：アプリケーション/ xmlの
<?xml version='1.0'?>
<？xmlのバージョン= '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.
この例では、文字セットパラメータが省略されている、およびNO BOMは存在しません。何BOMがないので、XMLプロセッサは、[XML]のセクション4.3.3の要求に従い、必要に応じて（非規範的である）付録Fに記載の機構を適用する[XML]のUTF-の文字セット符号化を決定します8。 XMLのMIMEエンティティは、エンコーディング宣言が含まれていませんが、エンコーディングがUTF-8であることから、これはまだ準拠するXML MIMEエンティティです。
An XML-unaware MIME processor SHOULD make no assumptions about the charset of the XML MIME entity.
XML-気づかないMIMEプロセッサは、XML MIMEエンティティの文字セットについての仮定を行うべきではありません。
8.11 Application/xml with Omitted Charset and Internal Encoding Declaration
8.11アプリケーション/省略文字セットと内部エンコード宣言とXML
Content-type: application/xml
コンテンツタイプ：アプリケーション/ xmlの
<?xml version='1.0' encoding="iso-10646-ucs-4"?>
<？XMLバージョン= '1.0' エンコーディング= "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).
この例では、文字セットパラメータが省略されている、およびNO BOMは存在しません。しかし、XMLのMIMEエンティティは、エンティティの文字セットを指定するXML MIMEエンティティの内部エンコーディング宣言を持っています。 [XML]のセクション4.3.3の要求に続いて、および必要に応じて[XML]の付録F（非規範的）に記載の機構を適用すること、XMLプロセッサは、この例ではXMLのMIMEエンティティ（UCS-の文字セットを決定します4）。
An XML-unaware MIME processor SHOULD make no assumptions about the charset of the XML MIME entity.
XML-気づかないMIMEプロセッサは、XML MIMEエンティティの文字セットについての仮定を行うべきではありません。
Content-type: text/xml-external-parsed-entity; charset="utf-8"
コンテンツタイプ：text / xmlで、外部解析されたエンティティ。 charset = "UTF-8" を
<?xml encoding="utf-8"?>
<？xmlのエンコーディング= "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.
これは、text / xmlで、外部解析されたエンティティで使用するための推奨charset値です。 charsetパラメータが設けられているため、MIMEおよびXMLプロセッサは、UTF-8でエンコードされたように封入されたエンティティを処理しなければなりません。
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.
7ビットの輸送（例えば、SMTP）を使用して送信された場合は、XMLのMIMEエンティティは、引用された、印刷可能なまたはBASE64のいずれかのコンテンツ転送符号化を使用しなければなりません。 8ビットクリーン輸送（例えば、8BITMIME ESMTPまたはNNTP）、またはバイナリクリーン搬送のために（例えば、HTTP）は、コンテンツ転送符号化は不要です。
Content-type: application/xml-external-parsed-entity; charset="utf-16"
コンテンツタイプ：アプリケーション/ XML-外部解析されたエンティティ。文字セット= "UTF-16"
{BOM}<?xml encoding="utf-16"?>
{BOM} <？XMLエンコード= "UTF-16"？>
or
または
{BOM}<?xml?>
{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.
これは、アプリケーション/ XMLの外部の解析されたエンティティで使用するための推奨charset値です。 charsetパラメータが設けられているため、MIMEおよびXMLプロセッサは、UTF-16エンコードされたように封入されたエンティティを処理しなければなりません。
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.
7ビットの輸送（例えば、SMTP）または8ビットクリーン輸送（例えば、8BITMIME ESMTPまたはNNTP）を使用して送信された場合は、XMLのMIMEエンティティは、引用された、印刷可能なまたはBASE64でエンコードされなければなりません。バイナリクリーン輸送（例えば、HTTP）のために、何のコンテンツ転送符号化は不要です。
Content-type: application/xml-external-parsed-entity; charset="utf-16be"
コンテンツタイプ：アプリケーション/ XML-外部解析されたエンティティ。文字セット= "UTF-16BE"
<?xml encoding="utf-16be"?>
<？xmlのエンコーディング= "UTF-16BE"？>
Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as UTF-16BE encoded.
charsetパラメータが設けられているのでUTF-16BEエンコードとして、MIMEおよびXMLプロセッサは、囲まれたエンティティを扱わなければなりません。
Content-type: application/xml-dtd; charset="utf-8"
コンテンツタイプ：アプリケーション/ XML-DTD; charset = "UTF-8" を
<?xml encoding="utf-8"?>
<？xmlのエンコーディング= "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.
文字セット "UTF-8" は、アプリケーション/ XML-DTDで使用するための推奨charset値です。 charsetパラメータが設けられているため、MIMEおよびXMLプロセッサは、UTF-8でエンコードされたように封入されたエンティティを処理しなければなりません。
Content-type: application/mathml+xml
コンテンツタイプ：アプリケーション/ MathMLの+ xmlの
<?xml version="1.0" ?>
<？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.
MathMLの文書は、その内容が[MathMLの]で定義されるように、数学的な情報を記述したXMLドキュメントです。形式はXMLに基づいているように、MathMLの文書は、そのMIMEコンテンツ・タイプ識別子に「+ xmlの」接尾辞規則を使用すべきです。しかし、コンテンツタイプはまだMathMLのために登録されていないと、そのような登録が完了するまでので、このメディアタイプを使用すべきではありません。
Content-type: application/xslt+xml
コンテンツタイプ：アプリケーション/ XSLT + xmlの
<?xml version="1.0" ?>
<？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.
拡張可能スタイルシート言語（XSLT）ドキュメントは、そのコンテンツ[XSLT]によって定義されるように、他のXML文書のスタイルシートを記述するXML文書です。形式はXMLに基づいているように、XSLTドキュメントは彼らのMIMEコンテンツ・タイプ識別子に「+ xmlの」接尾辞規則を使用すべきです。しかし、コンテンツタイプはまだXSLTのために登録されていないと、そのような登録が完了するまでので、このメディアタイプを使用すべきではありません。
Content-type: application/rdf+xml
コンテンツタイプ：アプリケーション/ RDF + xmlの
<?xml version="1.0" ?>
<？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.
このMIMEタイプを使用して同定RDF文書は、その内容[RDF]によって定義されるように、メタデータを記述するXML文書です。 XMLに基づく形式として、RDF文書は、そのMIMEコンテンツ・タイプ識別子で「+ xmlの」接尾辞規則を使用すべきです。しかし、コンテンツタイプはまだRDFのために登録されていないと、そのような登録が完了するまでので、このメディアタイプを使用すべきではありません。
Content-type: image/svg+xml
コンテンツタイプ：画像/ SVG + xmlの
<?xml version="1.0" ?>
<？xml version = "1.0"？>
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.
スケーラブルベクターグラフィックス（SVG）ドキュメントは、そのコンテンツ[SVG]によって定義されるように、グラフィック情報を記述するXML文書です。 XMLに基づいたフォーマットとして、SVGドキュメントは彼らのMIMEコンテンツ・タイプ識別子で「+ xmlの」接尾辞規則を使用すべきです。しかし、コンテンツタイプはまだSVGのために登録されていないと、そのような登録が完了するまでので、このメディアタイプを使用すべきではありません。
Content-type: text/xml; charset="utf-8"
コンテンツタイプ：text / xmlで、 charset = "UTF-8" を
<?xml version="1.0" encoding="iso-8859-1"?>
<？xml version = "1.0" エンコード= "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.
charsetパラメータはContent-Typeヘッダに設けられているため、MIMEおよびXMLプロセッサは、UTF-8でエンコードされたように封入されたエンティティを処理しなければなりません。それは、「ISO-8859-1」エンコードは無視しなければなりません、です。
Processors generating XML MIME entities MUST NOT label conflicting charset information between the MIME Content-Type and the XML declaration.
XMLのMIMEエンティティを生成するプロセッサは、MIMEのContent-TypeとXML宣言の間に矛盾する文字セット情報を標識してはなりません。
As described in Section 7, this document updates the [RFC2048] registration process for XML-based MIME types.
セクション7で説明したように、このドキュメントは、XMLベースのMIMEタイプの[RFC2048]登録プロセスを更新します。
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.
[RFC1874]で指定され、そしておそらくより、その期待されるユビキタス展開に伴うとしてXMLは、SGMLのサブセットとして、同じセキュリティ上の考慮事項のすべてを持っています。
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.
RFC 1874のセクション3を言い換えするには、XMLのMIMEエンティティは、受信者のXMLシステムによって解析され、処理される情報が含まれています。これらの実体は含まれていてもよいし、そのようなシステムは、明示的なシステムレベルのデータを処理している間に実行されるコマンドを許可することができます。 XMLシステムは、任意のコマンド文字列を実行します限り、XMLのMIMEエンティティの受信者は危険かもしれません。一般的には、不正なファイル操作を実行するコマンドを指定したり、その後の操作に影響を与える表示プロセッサの環境に変更を加えることも可能です。
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 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.
一般的に、ユーザの直接制御の外部に格納されている任意の情報 - CSSスタイルシート、XSL変換、エンティティ宣言、およびDTDを含む - は明白または微妙ないずれかの手段によって、不安の原因であることができます。たとえば、「マスター」スタイルシートに作られた小さな「ホワイトアウト攻撃」の変更は、重要な場所にある単語が直接ユーザーのドキュメントまたはそれが参照するスタイルシートを変更することなく、ユーザー文書に消すことができます。このように、任意のXMLドキュメントのセキュリティは、再帰的にその文書が参照するすべての文書に極めて依存しています。
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.
XHTML 1.0のエンティティリストとDTDは、[XHTML]、例えば、情報の一般的に使用されるセットである可能性が高いです。多くの開発者が使用し、それらを信頼する、人の数は、W3Cのサーバーのセキュリティのレベルについて多くを知っている、または任意の同様の信頼できるリポジトリになります。
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.
最も単純な攻撃は検証を破る宣言を加えることを含みます。文字エンティティのリストに余分な宣言を追加すると効果的に文書で使用される「契約を破る」ことができます。 DTDに致命的なエラーが発生し、小さな変更が大規模にXML処理を停止する可能性があります。余分な宣言が必要にオプションであることから、属性を変更するように、追跡するのは難しいことができ、かなり明白ですが、より洗練された技。おそらく、クラッカーに利用できる最も危険なオプションは、属性のデフォルト値を再定義されています。開発者はセキュリティのためにデフォルトした属性に依存してきた場合には、例えば、比較的小さな変化が情報の莫大な量を公開する可能性があります。
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 —.
別に構造の可能性から、別のオプションは、「実体スプーフィングは、」破壊しつづけ、おそらく意図しないメッセージを伝える、文書にテキストを挿入するために使用することができます。 XML 1.0許可複数のエンティティ宣言、および最初の宣言が優先されるため、それは＆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.
デジタル署名を使用すると、最終的にはない自分の管理下に外部ドキュメントを参照することの危険性を改善し得るXMLDSIGワーキンググループで現在進行中の作業します。
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.
XMLの使用は多様、かつ広範であることが予想されます。 XMLは、コミュニティ固有のメタデータのための一般的な構文として使用するためのコミュニティの広い範囲で監視下にあります。例えば、ダブリンコア[RFC2413]のグループは、ドキュメントのメタデータのためのXMLを使用しており、新たな取り組みは、それが医療情報のためのXMLの使用を検討して始まりました。他のグループは、リモート・プロシージャ・コールのパラメータを整列化するためのメカニズムとしてXMLを表示します。 XMLのより多くの用途は間違いなく発生します。
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の医療記録は、XMLライブラリのメタデータよりもはるかに厳しいプライバシーとセキュリティ考慮事項があります。同様に、パラメータマーシャリングの構文としてXMLを使用すると、ケースのセキュリティレビューによってケースが必要となります。
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.
また、XMLは、プレーンテキストと同じセキュリティ上の懸念のいくつかを有することができます。プレーンテキストと同じように、XMLは表示され、エスケープシーケンスを含むことができ、悪後続の操作に影響を与える方法で、ディスプレイプロセッサ環境を変える可能性を持っています。可能性のある影響が含まれますが、キーボードをロックするが、これらに限定されない、変化する表示パラメータので、その後表示されるテキストは読み取れない、あるいはその意味が失われたり変更されているように、故意にあいまいなまたはそれ以降表示された材料を歪曲するための表示パラメータを変更します。表示プロセッサは、表示されたテキストから、このような材料をフィルタリングしたり、他の特定の表示動作が完了した後に、すべての重要な設定をリセットするようにしてくださいどちらか。
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.
テキストの繰り返し拡張を構築するために、（第2節で述べたように、用語「実体」のXMLの意味を使用して）どのようなXMLの用語「実体参照」を利用してXML文書を構築することも可能であることに注意してください。再帰的展開は[XML]で禁止されており、XMLプロセッサは、それらを検出するために必要とされています。彼らは何度も行っている場合しかし、非再帰的な展開は、コンピュータの有限なコンピューティングリソースの問題を引き起こす可能性があります。
References
リファレンス
[ASCII] "US-ASCII. Coded Character Set -- 7-Bit American Standard Code for Information Interchange", ANSI X3.4-1986, 1986.
[ASCII] "US-ASCIIコード化文字セット - 7ビットの情報交換用米国標準コード"、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/>.
[CSS]ボス、B.、嘘、HW、リリー、C.およびI.ジェイコブス、 "カスケーディングスタイルシート、レベル2（CSS2）仕様書"、World Wide Web Consortium（W3C）の勧告REC-CSS2、1998年5月、<の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.
[ISO8859] "ISO8859国際規格 - 情報処理 - 8ビット・シングルバイト・コード化図形文字セット - パート1：ラテンアルファベット1号、ISO-8859-1：1987"、1987年。
[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/>.
[MathMLの]イオン、P.とR.マイナー、 "数学マークアップ言語（MathMLの）1.01"、World Wide Web Consortium（W3C）の勧告REC-のMathML、1999年7月、<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>.
[PNG] Boutell氏、T.、 "PNG（ポータブルネットワークグラフィックス）仕様"、World Wide Web Consortium（W3C）の勧告REC-PNG、1996年10月、<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/>.
[RDF] Lassila、O.およびRRスウィック、 "リソース記述フレームワーク（RDF）モデルとシンタックス仕様"、World Wide Web Consortium（W3C）の勧告REC-RDF-構文、1999年2月、<http://www.w3.org/TR / REC-RDF-構文/>。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[RFC0977]カンター、B.およびP.ラプスリー、 "ネットワークニュース転送プロトコル"、RFC 977、1986年2月。
[RFC1557] Choi, U., Chon, K. and H. Park, "Korean Character Encoding for Internet Messages", RFC 1557, December 1993.
[RFC1557]チェ、U.、チョン、K.およびH.パーク、 "インターネットメッセージのための韓国語の文字エンコーディング"、RFC 1557、1993年12月。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.およびD.クロッカー、 "8ビット・MIMEtransportためのSMTPサービス拡張"、RFC 1652、1994年7月。
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[RFC1874]レビンソン、E.、 "SGMLメディアタイプ"、RFC 1874、1995年12月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[RFC2048]解放され、N.、Klensin、J.とJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、RFC 2048、1996年11月。
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC2060]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 2060、1996年12月。
[RFC2077] Nelson, S., Parks, C. and Mitra, "The Model Primary Content Type for Multipurpose Internet Mail Extensions", RFC 2077, January 1997.
[RFC2077]ネルソン、S.、公園、C.とミトラ、「多目的インターネットメール拡張のためのモデルのプライマリコンテンツタイプ」、RFC 2077、1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M. and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997.
[RFC2130]ウイダー、C.、プレストン、C.、シモンセン、K.、Alvestrand、H.、アトキンソン、R.、クリスピン、M.およびP. Svanbergは、「ワークショップを設定IAB文字の報告は2月29日に開催されました - 1996" 年3月1日、RFC 2130、1997年4月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.
[RFC2376]ホワイトヘッド、E.およびM.村田、 "XMLのメディアタイプ"、RFC 2376、1998年7月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax.", RFC 2396, August 1998.
[RFC2396]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文。"、RFC 2396、1998年8月。
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core Metadata for Resource Discovery", RFC 2413, September 1998.
[RFC2413]ヴァイベル、S.、クンツェ、J.、Lagoze、C.及びM.ウルフ、 "リソース発見のためのDublin Coreメタデータ"、RFC 2413、1998年9月。
[RFC2445] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[RFC2445]ドーソン、F.とD. Stenerson、 "インターネットカレンダーおよびスケジューリング中核オブジェクト仕様（iCalendar形式）"、RFC 2445、1998年11月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518] Goland、Y.、ホワイトヘッド、E.、フェッチ、A.、カーター、S.、およびD.ジェンセン、 "分散オーサリングのHTTP拡張 - WEBDAV"、RFC 2518、1999年2月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]ローズ、M.、 "ライティングI-DSおよびXMLを使用しているRFC"、RFC 2629、1999年6月。
[RFC2703] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[RFC2703] Klyne、G.、 "プロトコルに依存しないコンテンツネゴシエーションフレームワーク"、RFC 2703、1999年9月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, Februrary 2000.
[RFC2781]ホフマン、P.及びF. Yergeau、 "UTF-16、ISO 10646の符号化"、RFC 2781、Februrary 2000。
[RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
[RFC2801]バーデット、D.、 "インターネットオープン取引プロトコル - IOTPバージョン1.0"、RFC 2801、2000年4月。
[SGML] International Standard Organization, "Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML)", ISO 8879, October 1986.
[SGML]国際標準化機構、 "情報処理 - テキストとオフィスシステム - 標準一般化マークアップ言語（SGML）"、ISO 8879、1986年10月。
[SVG] Ferraiolo, J., "Scalable Vector Graphics (SVG)", World Wide Web Consortium Candidate Recommendation SVG, November 2000, <http://www.w3.org/TR/SVG>.
[SVG] Ferraiolo、J.、 "スケーラブルベクターグラフィックス（SVG）"、World Wide Web Consortium（W3C）の勧告候補のSVG、2000年11月、<http://www.w3.org/TR/SVG>。
[XHTML] Pemberton, S. and et al, "XHTML 1.0: The Extensible HyperText Markup Language", World Wide Web Consortium Recommendation xhtml1, January 2000, <http://www.w3.org/TR/xhtml1>.
[XHTML]ペンバートン、S.らと、 "XHTML 1.0：拡張可能ハイパーテキストマークアップ言語"、World Wide Web Consortium（W3C）の勧告XHTML1、2000年1月、<http://www.w3.org/TR/xhtml1>。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[XML]ブレイ、T.、パオリ、J.、Sperberg-マックイーン、C.M。そしてE. MALER、 "拡張マークアップ言語（XML）1.0（第二版）"、World Wide Web Consortium（W3C）の勧告REC-XML、2000年10月、<http://www.w3.org/TR/REC-xml>。
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation xslt, November 1999, <http://www.w3.org/TR/xslt>.
[XSLT]クラーク、J.、 "XSL変換（XSLT）バージョン1.0"、World Wide Web Consortium（W3C）の勧告XSLT、1999年11月、<http://www.w3.org/TR/xslt>。
Authors' Addresses
著者のアドレス
MURATA Makoto (FAMILY Given) IBM Tokyo Research Laboratory 1623-14, Shimotsuruma Yamato-shi, Kanagawa-ken 242-8502 Japan
むらた まこと （ふぁみＬＹ ぎゔぇん） いＢＭ ときょ れせあｒｃｈ ぁぼらとｒｙ １６２３ー１４、 しもつるま やまとーし、 かながわーけん ２４２ー８５０２ じゃぱん
Phone: +81-46-215-4678 EMail: mmurata@trl.ibm.co.jp
電話：+ 81-46-215-4678 Eメール：mmurata@trl.ibm.co.jp
Simon St.Laurent simonstl.com 1259 Dryden Road Ithaca, New York 14850 USA
サイモンSt.Laurent simonstl.com 1259ドライデン道路イサカ、ニューヨーク14850 USA
EMail: simonstl@simonstl.com URI: http://www.simonstl.com/
電子メール：simonstl@simonstl.com URI：http://www.simonstl.com/
Dan Kohn Skymoon Ventures 3045 Park Boulevard Palo Alto, California 94306 USA
ダンコーンSkymoonベンチャーズ3045公園大通りパロアルト、カリフォルニア94306 USA
Phone: +1-650-327-2600 EMail: dan@dankohn.com URI: http://www.dankohn.com/
電話：+ 1-650-327-2600 Eメール：dan@dankohn.com URI：http://www.dankohn.com/
Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types?
付録A.なぜXMLベースのMIMEタイプのための「+ xmlの」接尾辞を使用しますか？
Although the use of a suffix was not considered as part of the original MIME architecture, this choice is considered to provide the most functionality with the least potential for interoperability problems or lack of future extensibility. The alternatives to the '+xml' suffix and the reason for its selection are described below.
接尾辞の使用は、元のMIMEアーキテクチャの一部として考慮されなかったが、この選択は、相互運用性の問題や将来の拡張性の欠如のための最も可能性のあるほとんどの機能を提供すると考えられています。 「+ xmlの」接尾辞に代替し、その選択した理由は、以下に記載されています。
A.1 Why not just use text/xml or application/xml and let the XML processor dispatch to the correct application based on the referenced DTD?
A.1理由だけではなく、text / xmlまたはapplication / xmlを使用して参照するDTDに基づいて正しいアプリケーションにXMLプロセッサの発送をさせませんか？
text/xml and application/xml remain useful in many situations, especially for document-oriented applications that involve combining XML with a stylesheet in order to present the data. However, XML is also used to define entirely new data types, and an XML-based format such as image/svg+xml fits the definition of a MIME media type exactly as well as image/png[PNG] does. (Note that image/svg+xml is not yet registered.) Although extra functionality is available for MIME processors that are also XML processors, XML-based media types -- even when treated as opaque, non-XML media types -- are just as useful as any other media type and should be treated as such.
text / xmlで、アプリケーション/ xmlのは、特に、データを提示するためにスタイルシートとXMLを組み合わせ伴うドキュメント指向アプリケーションのために、多くの状況で有用残ります。しかしながら、XMLはまた、完全に新しいデータ型を定義するために使用され、このような画像/ SVG + xmlのようなXMLベースのフォーマットは、MIMEメディアタイプの定義正確ならびに画像/ PNGにフィット[PNG]はありません。 （その画像/ SVG + XMLがまだ登録されていません。）追加機能もXMLプロセッサ、XMLベースのメディアタイプであるMIMEプロセッサのために利用可能であるが - 、不透明、非XMLメディアタイプとして扱われても - だけです他のメディアタイプとしてとして有用で、そのようなものとして扱われるべきです。
Since MIME dispatchers work off of the MIME type, use of text/xml or application/xml to label discrete media types will hinder correct dispatching and general interoperability. Finally, many XML documents use neither DTDs nor namespaces, yet are perfectly legal XML.
MIMEのディスパッチャは、MIMEタイプのオフ動作するので、個別のメディアタイプを標識するtext / xmlまたはapplication / xmlの使用は正しい派遣と一般的な相互運用性を妨げます。最後に、多くのXML文書はいずれのDTDや名前空間を使用し、まだ完全に合法XMLです。
A.2 Why not create a new subtree (e.g., image/xml.svg) to represent XML MIME types?
A.2なぜXMLのMIMEタイプを表す新しいサブツリー（例えば、画像/ xml.svg）を作成していませんか？
The subtree under which a media type is registered -- IETF, vendor (*/vnd.*), or personal (*/prs.*); see [RFC2048] for details -- is completely orthogonal from whether the media type uses XML syntax or not. The suffix approach allows XML document types to be identified within any subtree. The vendor subtree, for example, is likely to include a large number of XML-based document types. By using a suffix, rather than setting up a separate subtree, those types may remain in the same location in the tree of MIME types that they would have occupied had they not been based on XML.
メディアタイプが登録されているサブツリー - IETF、ベンダー（* / VND *）、または個人（* / *のPRS）。詳細については[RFC2048]を参照 - メディアタイプがXML構文を使用するか否かとは完全に直交しています。サフィックスのアプローチは、XMLドキュメントタイプは、任意のサブツリー内で識別することができるようになります。ベンダーサブツリーは、例えば、XMLベースの文書タイプの多数を含む可能性があります。接尾辞を使用してではなく、別々のサブツリーを設定することにより、これらの型は、それらがXMLに基づいていなかった彼らが占領していたMIMEタイプのツリー内の同じ場所に残ることがあります。
A.3 Why not create a new top-level MIME type for XML-based media types?
A.3は、なぜXMLベースのメディアタイプのための新たなトップレベルのMIMEタイプを作成しませんか？
The top-level MIME type (e.g., model/*[RFC2077]) determines what kind
of content the type is, not what syntax it uses. For example, agents
using image/* to signal acceptance of any image format should
certainly be given access to media type image/svg+xml, which is in all respects a standard image subtype. It just happens to use XML to
describe its syntax. The two aspects of the media type are
completely orthogonal.
XML-based data types will most likely be registered in ALL top-level categories. Potential, though currently unregistered, examples could include application/mathml+xml[MathML] and image/svg+xml[SVG].
XMLベースのデータ・タイプは、最も可能性の高いすべてのトップレベルカテゴリに登録されます。現在登録されていないものの電位、例としては、[SVG]アプリケーション/ MathMLの+ xmlの【のMathML]及び画像/ SVG + XMLを含むことができます。
A.4 Why not just have the MIME processor 'sniff' the content to determine whether it is XML?
A.4はなぜだけではなく、それがXMLであるかどうかを判断するためにMIMEプロセッサ「スニフのコンテンツがありますか？
Rather than explicitly labeling XML-based media types, the processor could look inside each type and see whether or not it is XML. The processor could also cache a list of XML-based media types.
むしろ明示的にXMLベースのメディアタイプを標識するよりも、プロセッサは、各タイプの内部を見ると、それがXMLであるかどうかを見ることができました。プロセッサはまた、XMLベースのメディアタイプのリストをキャッシュすることができます。
Although this method might work acceptably for some mail applications, it would fail completely in many other uses of MIME. For instance, an XML-based web crawler would have no way of determining whether a file is XML except to fetch it and check. The same issue applies in some IMAP4[RFC2060] mail applications, where the client first fetches the MIME type as part of the message structure and then decides whether to fetch the MIME entity. Requiring these fetches just to determine whether the MIME type is XML could have significant bandwidth and latency disadvantages in many situations.
この方法は、いくつかのメールアプリケーションのために許容可能に働くかもしれないが、それはMIMEの多くの他の用途に完全に失敗していました。例えば、XMLベースのWebクローラは、ファイルがそれを取得し、チェックする以外にXMLであるかどうかを判断する方法はありません。同じ問題は、クライアントが最初のメッセージ構造の一部としてMIMEタイプをフェッチした後、MIMEエンティティをフェッチするかどうかを決定するいくつかのIMAP4 [RFC2060]メールアプリケーション、に適用されます。ちょうどMIMEタイプがXMLであるかどうかを決定するために、これらのフェッチを要求することは、多くの状況に重要な帯域幅と遅延欠点を持つことができます。
Sniffing XML also isn't as simple as it might seem. DOCTYPE declarations aren't required, and they can appear fairly deep into a document under certain unpreventable circumstances. (E.g., the XML declaration, comments, and processing instructions can occupy space before the DOCTYPE declaration.) Even sniffing the DOCTYPE isn't completely reliable, thanks to a variety of issues involving default values for namespaces within external DTDs and overrides inside the internal DTD. Finally, the variety in potential character encodings (something XML provides tools to deal with), also makes reliable sniffing less likely.
XMLを盗聴しても、それが見えるかもしれないほど簡単ではありません。 DOCTYPE宣言が必要とされていない、と彼らは、特定の状況下でunpreventable文書にかなり深く見えることができます。 （例えば、XML宣言、コメント、および処理命令は、DOCTYPE宣言の前にスペースを占有することができます。）であってもDOCTYPEを盗聴することは、内部の内部外部のDTDとオーバーライド内の名前空間のデフォルト値を含むさまざまな問題のおかげで完全に信頼できるものではありませんDTD。最後に、可能性のある文字エンコーディング（何かXMLを扱うためのツールを提供しています）での様々な、また少ないスニッフィング信頼性を向上させ。
A.5 Why not use a MIME parameter to specify that a media type uses XML syntax?
A.5なぜメディアタイプがXML構文を使用するように指定するMIMEパラメータを使用していませんか？
For example, one could use "Content-Type: application/iotp;
alternate-type=text/xml" or "Content-Type: application/iotp;
syntax=xml".
Section 5 of [RFC2045] says that "Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content". However, all XML-based media types are by their nature always XML. Parameters, as they have been defined in the MIME architecture, are never invariant across all instantiations of a media type.
[RFC2045]のセクション5は、「パラメータには、メディアサブタイプの修飾子であり、そのように基本的にコンテンツの性質に影響を与えることはありません」と述べています。しかし、すべてのXMLベースのメディアタイプは、その性質上、常にXMLです。パラメータは、彼らはMIMEアーキテクチャで定義されているとして、メディアタイプのすべてのインスタンス間で不変されることはありません。
More practically, very few if any MIME dispatchers and other MIME agents support dispatching off of a parameter. While MIME agents on the receiving side will need to be updated in either case to support (or fall back to) generic XML processing, it has been suggested that it is easier to implement this functionality when acting off of the media type rather than a parameter. More important, sending agents require no update to properly tag an image as "image/svg+xml", but few if any sending agents currently support always tagging certain content types with a parameter.
より実用的に、非常に少数の任意のMIMEディスパッチャや他のMIMEエージェントは、パラメータのオフ派遣サポートしています。受信側のMIMEエージェントがサポートする（または背面にフォール）するかのいずれかの場合に更新する必要がありますが、一般的なXML処理、メディアタイプではなく、パラメータのオフ動作する場合、この機能を実装することが容易であることが示唆されています。さらに重要なのは、送信エージェントは、適切に、「画像/ SVG + xmlの」などの画像をタグ付けするために何のアップデートを必要としないが、いくつかの任意の送信薬は現在、常にパラメータを指定して、特定のコンテンツタイプをタグ付けをサポートする場合。
A.6 How about labeling with parameters in the other direction (e.g., application/xml; Content-Feature=iotp)?
A.6どのように他の方向のパラメータによる標識について（例えば、アプリケーション/ xmlの;のContent-特集= IOTP）？
This proposal fails under the simplest case, of a user with neither knowledge of XML nor an XML-capable MIME dispatcher. In that case, the user's MIME dispatcher is likely to dispatch the content to an XML processing application when the correct default behavior should be to dispatch the content to the application responsible for the content type (e.g., an ecommerce engine for application/iotp+xml[RFC2801], once this media type is registered).
この提案は、XMLのどちらも知識もXML対応のMIMEディスパッチャを持つユーザーで、最も単純なケースの下に失敗します。正しいデフォルトの動作は、コンテンツの種類（例えば、アプリケーション/ IOTP + xmlのためのeコマースエンジンを担当するアプリケーションにコンテンツを派遣するべきであるとき、その場合には、ユーザーのMIMEディスパッチャは、XML処理アプリケーションにコンテンツを派遣する可能性があります[RFC2801]、このメディアタイプが登録されます）。
Note that even if the user had already installed the appropriate application (e.g., the ecommerce engine), and that installation had updated the MIME registry, many operating system level MIME registries such as .mailcap in Unix and HKEY_CLASSES_ROOT in Windows do not currently support dispatching off a parameter, and cannot easily be upgraded to do so. And, even if the operating system were upgraded to support this, each MIME dispatcher would also separately need to be upgraded.
ユーザが既に適切なアプリケーションをインストールした場合でも（例えば、eコマースエンジン）、およびそのインストールが派遣MIMEレジストリなどのWindowsでのUnixでの.mailcapファイルおよびHKEY_CLASSES_ROOTなど、多くのオペレーティング・システム・レベルのMIMEのレジストリは、現在サポートしていませんを更新していたことに注意してくださいパラメータオフ、簡単にそうするようにアップグレードすることはできません。そして、オペレーティングシステムがこれをサポートするためにアップグレードされた場合でも、各MIMEディスパッチャはまた、個別にアップグレードする必要があります。
A.7 How about a new superclass MIME parameter that is defined to apply to all MIME types (e.g., Content-Type: application/iotp; $superclass=xml)?
A.7どのようにすべてのMIMEタイプ（例えば、Content-Typeの：アプリケーション/ IOTP; $スーパークラス= XML）に適用するように定義された新しいスーパーMIMEパラメータについてはどうですか？
This combines the problems of Appendix A.5 and Appendix A.6.
これは付録A.5および付録A.6の問題を兼ね備えています。
If the sender attaches an image/svg+xml file to a message and includes the instructions "Please copy the French text on the road sign", someone with an XML-aware MIME client and an XML browser but no support for SVG can still probably open the file and copy the text. By contrast, with superclasses, the sender must add superclass support to her existing mailer AND the receiver must add superclass support to his before this transaction can work correctly.
送信者がメッセージに画像/ SVG + xmlファイルを添付し、指示に含まれている場合はXMLを意識したMIMEクライアントとXMLブラウザおそらくすることができ、まだSVGのサポートはありませんし、誰かを「道路標識にフランス語のテキストをコピーしてください」ファイルを開いて、テキストをコピーします。これとは対照的に、スーパークラスで、送信者は、彼女の既存のメーラーにスーパークラスのサポートを追加する必要がありますし、このトランザクションが正常に動作することができます前に、受信機は、彼にスーパークラスのサポートを追加する必要があります。
If the receiver comes to rely on the superclass tag being present and applications are deployed relying on that tag (as always seems to happen), then only upgraded senders will be able to interoperate with those receiving applications.
受信機は（常に起こるようですとして）存在し、アプリケーションがそのタグに頼って展開されているスーパークラスのタグに依存していた場合、唯一のアップグレードされた送信者は、これらの受信アプリケーションと相互運用することができるようになります。
A.8 What about adding a new parameter to the Content-Disposition header or creating a new Content-Structure header to indicate XML syntax?
A.8何のContent-Dispositionヘッダーに新しいパラメータを追加したり、XML構文を示すために、新たなコンテンツの構造ヘッダーの作成について？
This has nearly identical problems to Appendix A.7, in that it requires both senders and receivers to be upgraded, and few if any operating systems and MIME dispatchers support working off of anything other than the MIME type.
これは、任意のオペレーティング・システムとMIMEのディスパッチャは、MIMEタイプ以外のオフに取り組んでサポートしている場合、それがアップグレードされる送信側と受信側の両方を必要とし、いくつかの点で、付録A.7とほぼ同じ問題を抱えています。
A.9 How about a new Alternative-Content-Type header?
A.9どのように新しい代替-Content-Typeヘッダは？
This is better than Appendix A.8, in that no extra functionality needs to be added to a MIME registry to support dispatching of information other than standard content types. However, it still requires both sender and receiver to be upgraded, and it will also fail in many cases (e.g., web hosting to an outsourced server), where the user can set MIME types (often through implicit mapping to file extensions), but has no way of adding arbitrary HTTP headers.
余分な機能は、標準のコンテンツタイプ以外の情報のディスパッチをサポートするために、MIMEレジストリに追加する必要がないという点で、これは、付録A.8よりも優れています。しかし、それはまだアップグレードされる送信者と受信者の両方が必要であり、それはまた、ユーザーが（拡張を提出することが多い暗黙的なマッピングを通じて）MIMEタイプを設定することができ、（例えば、ウェブ外部委託サーバーにホスティング）多くの場合失敗しますが、任意のHTTPヘッダを追加する方法がありません。
A.10 How about using a conneg tag instead (e.g., accept-features: (syntax=xml))?
A.10方法（例えば、-機能を受け入れる：= XML（構文））の代わりにconnegタグを使用してはどうですか？
When the conneg protocol is fully defined, this may potentially be a reasonable thing to do. But given the limited current state of conneg[RFC2703] development, it is not a credible replacement for a MIME-based solution.
connegプロトコルが完全に定義されている場合、これは潜在的に行うための合理的なものになるかもしれませんね。しかしconneg [RFC2703]開発の限られた現在の状態を考えると、それはMIMEベースのソリューションのための信頼できる代わるものではありません。
A.11 How about a third-level content-type, such as text/xml/rdf?
A.11どのようなテキスト/ XML / RDFとしての第3レベルのコンテンツ・タイプ、どうですか？
MIME explicitly defines two levels of content type, the top-level for the kind of content and the second-level for the specific media type. [RFC2048] extends this in an interoperable way by using prefixes to specify separate trees for IETF, vendor, and personal registrations. This specification also extends the two-level type by using the ' +xml' suffix. In both cases, processors that are unaware of these later specifications treat them as opaque and continue to interoperate. By contrast, adding a third-level type would break the current MIME architecture and cause numerous interoperability failures.
MIMEは、明示的にコンテンツタイプの2つのレベル、コンテンツの種類及び特定のメディアタイプのための第二のレベルの最上位を定義します。 [RFC2048]はIETF、ベンダー、および個人登録のための別々のツリーを指定する接頭辞を使用して相互運用可能な方法でこれを拡張します。本明細書はまた、「+ XML」サフィックスを使用して、2つのレベルのタイプを拡張します。どちらの場合も、これらの後の仕様に気づいていないプロセッサが不透明として扱うとの相互運用を継続します。これとは対照的に、第3レベルのタイプを追加すると、現在のMIMEアーキテクチャを壊し、多数の相互運用性の障害を引き起こします。
A.12 Why use the plus ('+') character for the suffix '+xml'?
A.12なぜサフィックスの文字「+ xmlの」（「+」）プラスを使うのか？
As specified in Section 5.1 of [RFC2045], a tspecial can't be used:
[RFC2045]のセクション5.1で指定されるように、tspecialを使用することができません。
tspecials := "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "="
tspecials：= "（" / "）" / "<" / ">" / "@" / "" / ";" / "：" / "\" / < "> "/"/ "["/ "]"/ ""/ "="？
It was thought that "." would not be a good choice since it is already used as an additional hierarchy delimiter. Also, "*" has a common wildcard meaning, and "-" and "_" are common word separators and easily confused. The characters %'`#& are frequently used for quoting or comments and so are not ideal.
これは、と考えられていました「」それはすでに追加階層の区切り文字として使用されているので、良い選択ではないでしょう。また、「*」の一般的なワイルドカードの意味を持ち、そして「 - 」と「_」一般的な単語の区切りと簡単に混乱しています。文字％が ' `＃＆は頻繁に引用やコメントなど理想的ではないために使用されています。
That leaves: ~!$^+{}|
それは葉：〜$ ^ + {} |！
Note that "-" is used heavily in the current registry. "$" and "_" are used once each. The others are currently unused.
「 - 」現在のレジストリに頻繁に使用されることに注意してください。 「$」および「_」は一回ごとに使用されています。他の人は、現在使用されていません。
It was thought that '+' expressed the semantics that a MIME type can be treated (for example) as both scalable vector graphics AND ALSO as XML; it is both simultaneously.
これは、「+」は、MIMEタイプは、また、XMLの両方として、スケーラブルベクタグラフィックスとして（例えば）で処理することができ、セマンティクスを発現していることが考えられました。それは同時に両方のです。
A.13 What is the semantic difference between application/foo and application/foo+xml?
A.13アプリケーション/ fooとアプリケーション/ fooの+ xmlの間の意味の違いは何ですか？
MIME processors that are unaware of XML will treat the '+xml' suffix as completely opaque, so it is essential that no extra semantics be assigned to its presence. Therefore, application/foo and application/foo+xml SHOULD be treated as completely independent media types. Although, for example, text/calendar+xml could be an XML version of text/calendar[RFC2445], it is possible that this (hypothetical) new media type would include new semantics as well as new syntax, and in any case, there would be many applications that support text/calendar but had not yet been upgraded to support text/calendar+xml.
余分なセマンティクスがその存在に割り当てられていないことが不可欠であるように、XMLの気づいていないMIMEプロセッサは、完全に不透明として「+ xmlの」接尾辞を扱います。したがって、アプリケーション/ fooとアプリケーション/ FOO + XMLは完全に独立したメディアタイプとして扱われるべきです。例えば、テキスト/カレンダー+ XMLはテキスト/カレンダー[RFC2445]のXMLバージョンであってもよい、が、この（仮想）新しいメディアタイプが、新しい意味論だけでなく、新しい構文を含む、いずれの場合になることが可能ですテキスト/カレンダーをサポートする多くのアプリケーションになりますが、まだテキスト/カレンダー+ XMLをサポートするようにアップグレードされていませんでした。
A.14 What happens when an even better markup language (e.g., EBML) is defined, or a new category of data?
A.14何がより良いマークアップ言語（例えば、EBML）が定義されている場合に発生、またはデータの新しいカテゴリ？
In the ten years that MIME has existed, XML is the first generic data format that has seemed to justify special treatment, so it is hoped that no further suffixes will be necessary. However, if some are later defined, and these documents were also XML, they would need to specify that the '+xml' suffix is always the outermost suffix (e.g., application/foo+ebml+xml not application/foo+xml+ebml). If they were not XML, then they would use a regular suffix (e.g., application/foo+ebml).
MIMEが存在してきた10年間で、XMLは、特別な治療を正当化するように見えたした第1の一般的なデータ形式であるので、それ以上のサフィックスは必要ではないだろうことが期待されます。しかし、いくつかは、後に定義されている場合、これらの文書もXMLだった、彼らは「+ xmlの」接尾辞は常に最も外側の接尾辞（例えば、アプリケーション/ fooの+ EBML + xmlのないアプリケーション/ fooの+ xmlの+ EBMLであることを指定する必要があります）。彼らはXMLでなかった場合、それらは通常の接尾辞（例えば、アプリケーション/ fooの+ EBML）を使用します。
A.15 Why must I use the '+xml' suffix for my new XML-based media type?
A.15は、なぜ私は私の新しいXMLベースのメディアタイプのための「+ xmlの」接尾辞を使用する必要がありますか？
You don't have to, but unless you have a good reason to explicitly disallow generic XML processing, you should use the suffix so as not to curtail the options of future users and developers.
あなたがする必要はありませんが、あなたが明示的に汎用的なXML処理を禁止する正当な理由がない限り、将来のユーザーと開発者の選択肢を削減しないように、あなたは接尾辞を使用する必要があります。
Whether the inventors of a media type, today, design it for dispatch to generic XML processing machinery (and most won't) is not the critical issue. The core notion is that the knowledge that some media type happens to use XML syntax opens the door to unanticipated kinds of processing beyond those envisioned by its inventors, and on this basis identifying such encoding is a good and useful thing.
メディアタイプの発明者らは、今日、一般的なXML処理機械への発送のためにそれを設計し（ほとんどのではないでしょう）かどうかは重要な問題ではありません。コア概念は、いくつかのメディアタイプがXML構文を使用するように起こっていることの知識はその発明者によって想定されるものを超えて処理の予期せぬ種類への扉を開くことであり、これに基づいて、このようなエンコーディングを特定することは良いと便利なものです。
Developers of new media types are often tightly focused on a particular type of processing that meets current needs. But there is no need to rule out generic processing as well, which could make your media type more valuable over time. It is believed that registering with the '+xml' suffix will cause no interoperability problems whatsoever, while it may enable significant new functionality and interoperability now and in the future. So, the conservative approach is to include the '+xml' suffix.
新しいメディアタイプの開発者は、多くの場合、しっかりと現在のニーズを満たしている処理の特定のタイプに焦点を当てています。しかし、時間をかけて、あなたのメディアタイプは、より多くの貴重な作ることができただけでなく、一般的な処理を排除する必要はありません。それが現在および将来の重要な新機能性と相互運用性を可能にしながら、「+ xmlの」接尾辞に登録すると、一切の相互運用性の問題が発生しないだろうと考えられています。だから、保守的なアプローチは、「+ xmlの」接尾辞を含めることです。
Appendix B. Changes from
付録B.変更から
There are numerous and significant differences between this specification and [RFC2376], which it obsoletes. This appendix summarizes the major differences only.
それは廃止この仕様書と[RFC2376]、間に数多くの重要な違いがあります。この付録では、唯一の主要な相違点をまとめました。
First, text/xml-external-parsed-entity and application/xml-external-parsed-entity are added as media types for external parsed entities, and text/xml and application/xml are now prohibited.
まず、text / xmlで、外部解析されたエンティティおよびアプリケーション/ XML-外部解析されたエンティティが外部解析対象実体のためのメディアタイプ、およびtext / xmlで、アプリケーション/ xmlのようになりまし禁止されている追加されます。
Second, application/xml-dtd is added as a media type for external DTD subsets and external parameter entities, and text/xml and application/xml are now prohibited.
第二に、アプリケーション/ XML-DTDは現在禁止されている外部DTDサブセットや外部パラメータ実体、およびtext / xmlで、アプリケーション/ XMLのメディアタイプとして追加されます。
Third, "utf-16le" and "utf-16be" are added. RFC 2781 has introduced these BOM-less variations of the UTF-16 family.
第三に、 "UTF-16LE" と "UTF-16BE" が追加されます。 RFC 2781はUTF-16ファミリのこれらのBOMレスバリエーションを導入しています。
Fourth, a naming convention ('+xml') for XML-based media types has been added, which also updates [RFC2048] as described in Section 7. By following this convention, an XML-based media type can be easily recognized as such.
第四に、XMLベースのメディアタイプの命名規則（「+ XML」）はまた、これは、この規則に従うことにより、セクション7で説明したようにアップデート[RFC2048]、XMLベースのメディアタイプが容易にそのように認識することができ、追加されました。
Appendix C. Acknowledgements
付録C.謝辞
This document reflects the input of numerous participants to the ietf-xml-mime@imc.org mailing list, though any errors are the responsibility of the authors. Special thanks to:
何らかのエラーが筆者の責任であるにもかかわらずこの文書は、ietf-xml-mime@imc.orgメーリングリストへの多数の参加者の入力を反映しています。に感謝します：
Mark Baker, James Clark, Dan Connolly, Martin Duerst, Ned Freed, Yaron Goland, Rick Jelliffe, Larry Masinter, David Megginson, Keith Moore, Chris Newman, Gavin Nicol, Marshall Rose, Jim Whitehead and participants of the XML activity at the W3C.
マーク・ベイカー、ジェームズ・クラーク、ダン・コノリー、マーティンDuerst、ネッドフリード、ヤロンGoland、リック・ジェリフ、ラリーMasinter、デイビット・メギンソン、キース・ムーア、クリス・ニューマン、ギャビン・ニコル、マーシャルローズ、ジム・ホワイトヘッドとW3CのXML活動の参加者。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。