[要約] RFC 7303は、XMLメディアタイプの定義と使用方法に関するガイドラインです。このRFCの目的は、XMLデータの正確な識別と処理を容易にすることです。
Internet Engineering Task Force (IETF) H. Thompson
Request for Comments: 7303 University of Edinburgh
Obsoletes: 3023 C. Lilley
Updates: 6839 W3C
Category: Standards Track July 2014
ISSN: 2070-1721
XML Media Types
CMLメディアタイプ
Abstract
概要
This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.
この仕様は、テキストの定義中にExtensible Markup Language（XML）に関連するネットワークエンティティを交換する際に使用するために、application / xml、application / xml-external-parsed-entity、application / xml-dtdの3つのメディアタイプを標準化しています。 / xmlおよびtext / xml-external-parsed-entityは、それぞれのapplication /タイプのエイリアスとして使用されます。この仕様では、メディアタイプがXML MIMEエンティティを表す場合、これらの5つのタイプ以外のメディアタイプに名前を付けるための「+ xml」サフィックスも標準化されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7303.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7303で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Characters, Encodings, Charsets . . . . . . . . . . . . . 4
2.3. MIME Entities, XML Entities . . . . . . . . . . . . . . . 5
3. Encoding Considerations . . . . . . . . . . . . . . . . . . . 6
3.1. XML MIME Producers . . . . . . . . . . . . . . . . . . . 6
3.2. XML MIME Consumers . . . . . . . . . . . . . . . . . . . 7
3.3. The BOM and Encoding Conversions . . . . . . . . . . . . 8
4. XML Media Types . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. XML MIME Entities . . . . . . . . . . . . . . . . . . . . 9
4.2. Using '+xml' when Registering XML-Based Media Types . . . 11
4.3. Registration Guidelines for XML-Based Media Types Not
Using '+xml' . . . . . . . . . . . . . . . . . . . . . 12
5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 13
6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 14
7. XML Versions . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. UTF-8 Charset . . . . . . . . . . . . . . . . . . . . . . 15
8.2. UTF-16 Charset . . . . . . . . . . . . . . . . . . . . . 16
8.3. Omitted Charset and 8-Bit MIME Entity . . . . . . . . . . 16
8.4. Omitted Charset and 16-Bit MIME Entity . . . . . . . . . 16
8.5. Omitted Charset, No Internal Encoding Declaration . . . . 17
8.6. UTF-16BE Charset . . . . . . . . . . . . . . . . . . . . 17
8.7. Non-UTF Charset . . . . . . . . . . . . . . . . . . . . . 18
8.8. INCONSISTENT EXAMPLE: Conflicting Charset and Internal
Encoding Declaration . . . . . . . . . . . . . . . . . . 18
8.9. INCONSISTENT EXAMPLE: Conflicting Charset and BOM . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. application/xml Registration . . . . . . . . . . . . . . 19
9.2. text/xml Registration . . . . . . . . . . . . . . . . . . 21
9.3. application/xml-external-parsed-entity Registration . . . 21
9.4. text/xml-external-parsed-entity Registration . . . . . . 22
9.5. application/xml-dtd Registration . . . . . . . . . . . . 22
9.6. The '+xml' Naming Convention for XML-Based Media Types . 23
9.6.1. The '+xml' Structured Syntax Suffix Registration . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types? 32
Appendix B. Core XML Specifications . . . . . . . . . . . . . . 32
Appendix C. Operational Considerations . . . . . . . . . . . . . 32
C.1. General Considerations . . . . . . . . . . . . . . . . . 33
C.2. Considerations for Producers . . . . . . . . . . . . . . 33
C.3. Considerations for Consumers . . . . . . . . . . . . . . 34
Appendix D. Changes from RFC 3023 . . . . . . . . . . . . . . . 34
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 35
The World Wide Web Consortium has issued the Extensible Markup Language (XML) 1.0 [XML] and Extensible Markup Language (XML) 1.1 [XML1.1] specifications. To enable the exchange of XML network entities, this specification standardizes three media types (application/xml, application/xml-external-parsed-entity, and application/xml-dtd), two aliases (text/xml and text/xml-external-parsed-entity), and a naming convention for identifying XML-based MIME media types (using '+xml').
World Wide Webコンソーシアムは、Extensible Markup Language（XML）1.0 [XML]およびExtensible Markup Language（XML）1.1 [XML1.1]仕様を発行しました。 XMLネットワークエンティティの交換を可能にするために、この仕様では3つのメディアタイプ（application / xml、application / xml-external-parsed-entity、application / xml-dtd）、2つのエイリアス（text / xmlおよびtext / xml-external）を標準化しています。 -parsed-entity）、およびXMLベースのMIMEメディアタイプを識別するための命名規則（「+ xml」を使用）。
XML has been 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, and in line with the recognition in [RFC6838] of structured syntax name suffixes, a suffix of '+xml' is registered in Section 9.6. This will allow generic XML-based tools -- browsers, editors, search engines, and other processors -- to work with all XML-based media types.
XMLは、IETFメディアタイプツリーのすべてのブランチのタイプを含む、他のメディアタイプの基礎として使用されています。そのようなタイプの処理を容易にするために、[RFC6838]での構造化構文名サフィックスの認識に合わせて、「+ xml」のサフィックスがセクション9.6に登録されています。これにより、ブラウザー、エディター、検索エンジン、およびその他のプロセッサーなどの一般的なXMLベースのツールが、すべてのXMLベースのメディアタイプで機能するようになります。
This specification replaces [RFC3023]. Major differences are in the areas of alignment of text/xml and text/xml-external-parsed-entity with application/xml and application/xml-external-parsed-entity respectively, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, integration of the XPointer Registry and updating of many references.
この仕様は[RFC3023]を置き換えます。主な違いは、text / xmlおよびtext / xml-external-parsed-entityとapplication / xmlおよびapplication / xml-external-parsed-entityとのアラインメントの領域であり、フラグメント識別子およびベースとしてXPointerおよびXML Baseが追加されています。 XPointerレジストリの統合と、多くの参照の更新。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの仕様の「は、[RFC2119]で説明されているように解釈されます。
Both XML (in an XML or Text declaration using the encoding pseudo-attribute) and MIME (in a Content-Type header field using the charset parameter) use a common set of labels [IANA-CHARSETS] to identify the MIME charset (mapping from byte stream to character sequence [RFC2978]).
XML（エンコーディング疑似属性を使用したXMLまたはテキスト宣言内）とMIME（charsetパラメーターを使用したContent-Typeヘッダーフィールド内）の両方が、共通のラベルセット[IANA-CHARSETS]を使用してMIME文字セット（からのマッピング）を識別します。文字シーケンスへのバイトストリーム[RFC2978]）。
In this specification, we will use the phrases "charset parameter" and "encoding declaration" to refer to whatever MIME charset is specified by a MIME charset parameter or XML encoding declaration, respectively. We reserve the phrase "character encoding" (or, when the context makes the intention clear, simply "encoding") for the MIME charset actually used in a particular XML MIME entity.
この仕様では、「charsetパラメータ」および「エンコーディング宣言」という語句を使用して、それぞれMIME charsetパラメータまたはXMLエンコーディング宣言によって指定されたMIME文字セットを参照します。特定のXML MIMEエンティティで実際に使用されるMIME文字セットのために、「文字エンコーディング」という語句（または、コンテキストが明確にする場合は単に「エンコーディング」）を予約しています。
[UNICODE] defines three "encoding forms", namely UTF-8, UTF-16, and UTF-32. As UTF-8 can only be serialized in one way, the only possible label for UTF-8-encoded documents when serialised into MIME entities is "utf-8". UTF-16 XML documents, however, can be serialised into MIME entities in one of two ways: either big-endian, labelled (optionally) "utf-16" or "utf-16be", or little-endian, labelled (optionally) "utf-16" or "utf-16le". See Section 3.3 below for how a Byte Order Mark (BOM) is required when the "utf-16" serialization is used.
[UNICODE]は、UTF-8、UTF-16、UTF-32の3つの「エンコード形式」を定義しています。 UTF-8は1つの方法でのみシリアル化できるため、MIMEエンティティにシリアル化されたときにUTF-8でエンコードされたドキュメントで可能なラベルは「utf-8」のみです。ただし、UTF-16 XMLドキュメントは、2つの方法のいずれかでMIMEエンティティにシリアル化できます。ビッグエンディアン（「オプション」）「utf-16」または「utf-16be」、またはリトルエンディアン（「オプション」） 「utf-16」または「utf-16le」。 「utf-16」シリアル化を使用する場合にバイトオーダーマーク（BOM）がどのように必要になるかについては、以下のセクション3.3を参照してください。
UTF-32 has four potential serializations, of which only two (UTF-32BE and UTF-32LE) are given names in [UNICODE]. Support for the various serializations varies widely, and security concerns about their use have been raised (for example, see [Sivonen]). The use of UTF-32 is NOT RECOMMENDED for XML MIME entities.
UTF-32には4つの潜在的なシリアル化があり、そのうち2つ（UTF-32BEとUTF-32LE）だけが[UNICODE]で名前が付けられています。さまざまなシリアライゼーションのサポートはさまざまであり、それらの使用に関するセキュリティ上の懸念が提起されています（たとえば、[Sivonen]を参照）。 XML MIMEエンティティでは、UTF-32の使用は推奨されません。
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. These are called entities; they all have content and are all (except for the document entity and the external DTD subset) identified by entity name.
XMLドキュメントは、1つ以上のストレージユニットで構成されます。これらはエンティティと呼ばれます。それらはすべてコンテンツを持ち、すべて（ドキュメントエンティティと外部DTDサブセットを除く）エンティティ名で識別されます。
In this specification, "XML MIME entity" is defined as the latter (an XML entity) encapsulated in the former (a MIME entity).
この仕様では、「XML MIMEエンティティ」は、前者（MIMEエンティティ）にカプセル化された後者（XMLエンティティ）として定義されています。
Furthermore, XML provides for the naming and referencing of entities for purposes of inclusion and/or substitution. In this specification, "XML-entity declaration/reference/..." is used to avoid confusion when referring to such cases.
さらに、XMLは、包含や置換の目的でエンティティの命名と参照を提供します。この仕様では、「XMLエンティティ宣言/参照/ ...」を使用して、このような場合に言及するときの混乱を回避しています。
The registrations below all address issues around character encoding in the same way, by referencing this section.
以下の登録はすべて、このセクションを参照することにより、同じ方法で文字エンコードに関する問題に対処しています。
As many as three distinct sources of information about character encoding may be present for an XML MIME entity: a charset parameter, a BOM (see Section 3.3 below), and an XML encoding declaration (see Section 4.3.3 of [XML]). Ensuring consistency among these sources requires coordination between entity authors and MIME agents (that is, processes that package, transfer, deliver, and/or receive MIME entities).
XML MIMEエンティティには、文字エンコーディングに関する3つの異なる情報源が存在する可能性があります。文字セットパラメータ、BOM（以下のセクション3.3を参照）、およびXMLエンコーディング宣言（[XML]のセクション4.3.3を参照）。これらのソース間の整合性を確保するには、エンティティの作成者とMIMEエージェント（つまり、MIMEエンティティをパッケージ化、転送、配信、受信するプロセス）間の調整が必要です。
The use of UTF-8, without a BOM, is RECOMMENDED for all XML MIME entities.
BOMなしのUTF-8の使用は、すべてのXML MIMEエンティティに推奨されます。
Some MIME agents will be what we will call "XML-aware", that is, capable of processing XML MIME entities as XML and detecting the XML encoding declaration (or its absence). All three sources of information about encoding are available to them, and they can be expected to be aware of this specification.
一部のMIMEエージェントは、「XML対応」と呼ばれるものです。つまり、XML MIMEエンティティをXMLとして処理し、XMLエンコーディング宣言（またはその不在）を検出できます。エンコーディングに関する3つの情報源すべてが利用可能であり、この仕様を知っていることが期待できます。
Other MIME agents will not be XML-aware; thus, they cannot know anything about the XML encoding declaration. Not only do they lack one of the three sources of information about encoding, they are also less likely to be aware of or responsive to this specification.
他のMIMEエージェントはXML対応ではありません。したがって、XMLエンコーディング宣言については何も知ることができません。エンコーディングに関する3つの情報源の1つが不足しているだけでなく、この仕様を認識していないか、この仕様に反応する可能性も低いです。
Some MIME agents, such as proxies and transcoders, both consume and produce MIME entities.
プロキシやトランスコーダなどの一部のMIMEエージェントは、MIMEエンティティを消費および生成します。
This mixture of two kinds of agents handling XML MIME entities increases the complexity of the coordination task. The recommendations given below are intended to maximise interoperability in the face of this: on the one hand, by mandating consistent production and encouraging maximally robust forms of production and, on the other, by specifying recovery strategies to maximize the interoperability of consumers when the production rules are broken.
XML MIMEエンティティを処理する2種類のエージェントのこの混合により、調整タスクが複雑になります。以下の推奨事項は、これに直面して相互運用性を最大化することを目的としています。一方で、一貫した生産を義務付け、最大限に堅牢な生産形態を奨励することにより、他方では、生産時にコンシューマの相互運用性を最大化する回復戦略を指定することルールが破られています。
XML-aware MIME producers SHOULD supply a charset parameter and/or an appropriate BOM with non-UTF-8-encoded XML MIME entities that lack an encoding declaration. Such producers SHOULD remove or correct an encoding declaration that is known to be incorrect (for example, as a result of transcoding).
XML対応のMIMEプロデューサーは、エンコーディング宣言のない、UTF-8でエンコードされていないXML MIMEエンティティを含む文字セットパラメータや適切なBOMを提供する必要があります（SHOULD）。そのようなプロデューサーは、（たとえば、トランスコーディングの結果として）正しくないことがわかっているエンコーディング宣言を削除または修正する必要があります。
XML-aware MIME producers MUST supply an XML text declaration at the beginning of non-UNICODE XML external parsed entities that would otherwise begin with the hexadecimal octet sequences 0xFE 0xFF, 0xFF 0xFE or 0xEF 0xBB 0xBF, in order to avoid the mistaken detection of a BOM.
XMLを認識するMIMEプロデューサーは、UNICODE以外のXML外部解析エンティティの先頭に、そうでなければ16進数のオクテットシーケンス0xFE 0xFF、0xFF 0xFEまたは0xEF 0xBB 0xBFで始まるXMLテキスト宣言を提供する必要があります。 BOM。
XML-unaware MIME producers MUST NOT supply a charset parameter with an XML MIME entity unless the entity's character encoding is reliably known. Note that this is particularly relevant for central configuration of web servers, where configuring a default for the charset parameter will almost certainly violate this requirement.
XML非対応MIMEプロデューサーは、エンティティの文字エンコーディングが確実にわかっている場合を除き、XML MIMEエンティティで文字セットパラメータを提供してはなりません（MUST NOT）。これは、Webサーバーの中央構成に特に関係があることに注意してください。charsetパラメータのデフォルトを構成すると、ほぼ確実にこの要件に違反します。
XML MIME producers are RECOMMENDED to provide means for users to control what value, if any, is given to charset parameters for XML MIME entities, for example, by giving users control of the configuration of Web server filename-to-Content-Type-header mappings on a file-by-file or suffix basis.
XML MIMEプロデューサーは、ユーザーがWebサーバーのファイル名からコンテンツタイプヘッダーの構成を制御できるようにするなど、ユーザーがXML MIMEエンティティの文字セットパラメーターに与える値を制御する手段を提供することを推奨します。ファイルごとまたはサフィックスごとのマッピング。
For XML MIME consumers, the question of priority arises in cases when the available character encoding information is not consistent. Again, we must distinguish between XML-aware and XML-unaware agents.
XML MIMEコンシューマーの場合、使用可能な文字エンコード情報に一貫性がない場合に優先順位の問題が発生します。ここでも、XML対応のエージェントとXML非対応のエージェントを区別する必要があります。
When a charset parameter is specified for an XML MIME entity, the normative component of the [XML] specification leaves the question open as to how to determine the encoding with which to attempt to process the entity. This is true independently of whether or not the entity contains in-band encoding information, that is, either a BOM (Section 3.3) or an XML encoding declaration, both, or neither. In particular, in the case where there is in-band information and it conflicts with the charset parameter, the [XML] specification does not specify which is authoritative. In its (non-normative) Appendix F, it defers to this specification:
XML MIMEエンティティにcharsetパラメータが指定されている場合、[XML]仕様の規範的なコンポーネントは、エンティティの処理を試みるエンコーディングを決定する方法についての疑問を残します。これは、エンティティに帯域内エンコーディング情報が含まれているかどうか、つまりBOM（セクション3.3）またはXMLエンコーディング宣言のいずれか、または両方に関係なく当てはまります。特に、インバンド情報があり、それがcharsetパラメータと競合する場合、[XML]仕様はどちらが信頼できるかを指定しません。 （非規範的）付録Fでは、この仕様に従います。
[T]he preferred method of handling conflict should be specified as part of the higher-level protocol used to deliver XML. In particular, please refer to [IETF RFC 3023] or its successor...
[T]優先する競合処理方法は、XMLの配信に使用される上位レベルのプロトコルの一部として指定する必要があります。特に、[IETF RFC 3023]またはその後継を参照してください...
Accordingly, to conform with deployed processors and content and to avoid conflicting with this or other normative specifications, this specification sets the priority as follows:
したがって、展開されたプロセッサとコンテンツに準拠し、この仕様または他の規範的な仕様との競合を回避するために、この仕様は次のように優先順位を設定します。
A BOM (Section 3.3) is authoritative if it is present in an XML MIME entity;
BOM（セクション3.3）は、XML MIMEエンティティに存在する場合に信頼できます。
In the absence of a BOM (Section 3.3), the charset parameter is authoritative if it is present.
BOMがない場合（セクション3.3）、charsetパラメータが存在する場合、それが信頼できます。
Whenever the above determines a source of encoding information as authoritative, consumers SHOULD process XML MIME entities based on that information.
上記がエンコーディング情報のソースを信頼できると判断した場合は常に、コンシューマはその情報に基づいてXML MIMEエンティティを処理する必要があります（SHOULD）。
When MIME producers conform to the requirements stated above (Section 3.1, Section 3) inconsistencies will not arise -- the above statement of priorities only has practical impact in the case of non-conforming XML MIME entities. In the face of inconsistencies, no uniform strategy can deliver the 'right' answer every time: the purpose of specifying one here is to encourage convergence over time, first on the part of consumers, then on the part of producers.
MIMEプロデューサーが上記の要件（セクション3.1、セクション3）に準拠している場合、不整合は発生しません。上記の優先順位のステートメントは、XML MIMEエンティティが準拠していない場合にのみ実際的な影響があります。一貫性がないと、統一された戦略では毎回「正しい」答えを出すことができません。ここで1つを指定する目的は、最初は消費者の側で、次にプロデューサーの側で、時間の経過とともに収束を促すことです。
For XML-aware consumers, note that Section 4.3.3 of [XML] does _not_ make it an error for the charset parameter and the XML encoding declaration (or the UTF-8 default in the absence of encoding declaration and BOM) to be inconsistent, although such consumers might choose to issue a warning in this case.
XML対応のコンシューマーの場合、[XML]のセクション4.3.3ではcharsetパラメータとXMLエンコーディング宣言（またはエンコーディング宣言とBOMがない場合のUTF-8デフォルト）が矛盾しているとエラーにならないことに注意してくださいただし、この場合、そのような消費者は警告を出すことを選択するかもしれません。
If an XML MIME entity is received where the charset parameter is omitted, no information is being provided about the character encoding by the MIME Content-Type header. XML-aware consumers MUST follow the requirements in section 4.3.3 of [XML] that directly address this case. XML-unaware MIME consumers SHOULD NOT assume a default encoding in this case.
charsetパラメーターが省略されているXML MIMEエンティティが受信された場合、MIME Content-Typeヘッダーによる文字エンコードに関する情報は提供されません。 XML対応のコンシューマーは、このケースに直接対処する[XML]のセクション4.3.3の要件に従う必要があります。この場合、XML非対応MIMEコンシューマーはデフォルトのエンコーディングを想定してはなりません（SHOULD NOT）。
Section 4.3.3 of [XML] specifies that UTF-16 XML MIME entities not labelled as "utf-16le" or "utf-16be" MUST begin with a BOM, U+FEFF, which appears as the hexadecimal octet sequence 0xFE 0xFF (big-endian) or 0xFF 0xFE (little-endian). [XML] 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-16le」または「utf-16be」としてラベル付けされていないUTF-16 XML MIMEエンティティは、16進数のオクテットシーケンス0xFE 0xFF（ビッグエンディアン）または0xFF 0xFE（リトルエンディアン）。 [XML]はさらに、BOMはエンコード署名であり、XMLドキュメントのマークアップまたは文字データの一部ではないことを述べています。
Due to the presence of the BOM, applications that convert XML from UTF-16 to an encoding other than UTF-8 MUST strip the BOM before conversion. Similarly, when converting from another encoding into UTF-16, either without a charset parameter or labelled "utf-16", the BOM MUST be added unless the original encoding was UTF-8 and a BOM was already present, in which case it MUST be transcoded into the appropriate UTF-16 BOM.
BOMが存在するため、XMLをUTF-16からUTF-8以外のエンコーディングに変換するアプリケーションは、変換前にBOMを削除する必要があります。同様に、charsetパラメータなしまたは「utf-16」というラベルの付いた別のエンコーディングからUTF-16に変換する場合、元のエンコーディングがUTF-8で、BOMがすでに存在している場合を除き、BOMを追加する必要があります。適切なUTF-16 BOMにトランスコードされます。
Section 4.3.3 of [XML] also allows for UTF-8 XML MIME entities to begin with a BOM, which appears as the hexadecimal octet sequence 0xEF 0xBB 0xBF. This is likewise defined to be an encoding signature, and not part of either the markup or the character data of the XML document.
[XML]のセクション4.3.3では、UTF-8 XML MIMEエンティティをBOMで開始することもできます。BOMは、16進数のオクテットシーケンス0xEF 0xBB 0xBFとして表示されます。同様に、これはエンコーディングシグネチャであると定義されており、XMLドキュメントのマークアップまたは文字データの一部ではありません。
Applications that convert XML from UTF-8 to an encoding other than UTF-16 MUST strip the BOM, if present, before conversion. Applications that convert XML into UTF-8 MAY add a BOM.
XMLをUTF-8からUTF-16以外のエンコーディングに変換するアプリケーションは、変換前にBOMを削除する必要があります（存在する場合）。 XMLをUTF-8に変換するアプリケーションは、BOMを追加する場合があります。
In addition to the MIME charset "utf-16", [RFC2781] introduces "utf-16le" (little-endian) and "utf-16be" (big-endian). When an XML MIME entity is encoded in "utf-16le" or "utf-16be", it MUST NOT begin with the BOM but SHOULD contain an in-band XML encoding declaration. Conversion from UTF-8 or UTF-16 (unlabelled, or labelled with "utf-16") to "utf-16be" or "utf-16le" MUST strip a BOM if present. Conversion from UTF-16 labelled "utf-16le" or "utf-16be" to UTF-16 without a label or labelled "utf-16" MUST add the appropriate BOM. Conversion from UTF-16 labelled "utf-16le" or "utf-16be" to UTF-8 MAY add a UTF-8 BOM, but this is NOT RECOMMENDED.
[RFC2781]は、MIME文字セット "utf-16"に加えて、 "utf-16le"（リトルエンディアン）と "utf-16be"（ビッグエンディアン）を導入しています。 XML MIMEエンティティが「utf-16le」または「utf-16be」でエンコードされている場合、BOMで始めてはなりませんが、インバンドXMLエンコーディング宣言を含める必要があります。 UTF-8またはUTF-16（ラベルなし、または "utf-16"でラベル付け）から "utf-16be"または "utf-16le"への変換では、BOMが存在する場合は削除する必要があります。 「utf-16le」または「utf-16be」とラベル付けされたUTF-16から、ラベルなしまたは「utf-16」とラベル付けされたUTF-16への変換では、適切なBOMを追加する必要があります。 「utf-16le」または「utf-16be」というラベルの付いたUTF-16からUTF-8への変換により、UTF-8 BOMが追加される場合がありますが、これは推奨されません。
Appendix F of [XML] also implies that a UTF-32 BOM may be used in conjunction with UTF-32-encoded documents. As noted above, this specification recommends against the use of UTF-32. If it is used, the same considerations as UTF-16 apply with respect to its being a signature (not part of the document), transcoding into or out of it, and transcoding into or out of the MIME charsets "utf-32le" and "utf-32be". Consumers that do not support UTF-32 SHOULD nonetheless recognise UTF-32 signatures in order to give helpful error messages (instead of treating them as invalid UTF-16).
[XML]の付録Fは、UTF-32 BOMをUTF-32でエンコードされたドキュメントと組み合わせて使用できることも示唆しています。上記のように、この仕様ではUTF-32の使用を推奨していません。これを使用する場合、UTF-16と同じ考慮事項が、署名（ドキュメントの一部ではない）、MIME文字セット "utf-32le"へのトランスコード、MIME文字セットへのトランスコード、およびそれらからのトランスコードに関して適用されます。 「utf-32be」。それでもUTF-32をサポートしないコンシューマは、有用なエラーメッセージを表示するために（無効なUTF-16として扱うのではなく）、UTF-32署名を認識する必要があります（SHOULD）。
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". Appropriate usage for the types registered below is as follows:
XML仕様では、XML MIMEエンティティを4つのタイプに分類できます。 XML用語では、「ドキュメントエンティティ」、「外部DTDサブセット」、「外部解析エンティティ」、「外部パラメータエンティティ」と呼ばれます。以下に登録されているタイプの適切な使用法は次のとおりです。
document entities: The media types application/xml or text/xml, or a more specific media type (see Section 9.6), SHOULD be used.
ドキュメントエンティティ：メディアタイプapplication / xmlまたはtext / xml、またはより具体的なメディアタイプ（セクション9.6を参照）を使用する必要があります。
external DTD subsets: The media type application/xml-dtd SHOULD be used. The media types application/xml and text/xml MUST NOT be used.
外部DTDサブセット：メディアタイプapplication / xml-dtdを使用する必要があります（SHOULD）。メディアタイプapplication / xmlおよびtext / xmlを使用してはなりません（MUST NOT）。
external parsed entities: The media types application/xml-external-parsed-entity or text/xml-external-parsed-entity SHOULD be used. The media types application/xml and text/xml MUST NOT be used unless the parsed entities are also well-formed "document entities".
外部解析エンティティ：メディアタイプapplication / xml-external-parsed-entityまたはtext / xml-external-parsed-entityを使用する必要があります（SHOULD）。解析されたエンティティが整形式の「ドキュメントエンティティ」でもない限り、メディアタイプapplication / xmlおよびtext / xmlを使用してはなりません（MUST NOT）。
external parameter entities: The media type application/xml-dtd SHOULD be used. The media types application/xml and text/xml MUST NOT be used.
外部パラメーターエンティティ：メディアタイプapplication / xml-dtdを使用する必要があります（SHOULD）。メディアタイプapplication / xmlおよびtext / xmlを使用してはなりません（MUST NOT）。
Note that [RFC3023] (which this specification obsoletes) recommended the use of text/xml and text/xml-external-parsed-entity for document entities and external parsed entities, respectively, but described handling of character encoding that differed from common implementation practice. These media types are still commonly used, and this specification aligns the handling of character encoding with industry practice.
[RFC3023]（この仕様では廃止されました）は、ドキュメントエンティティと外部解析エンティティに対してそれぞれtext / xmlとtext / xml-external-parsed-entityの使用を推奨しましたが、一般的な実装方法とは異なる文字エンコーディングの処理について説明しました。 。これらのメディアタイプは今でも一般的に使用されており、この仕様は文字エンコーディングの処理を業界の慣行に合わせています。
Note that [RFC2376] (which is obsolete) allowed application/xml and text/xml to be used for any of the four types, although in practice it is likely to have been rare.
[RFC2376]（廃止）では、4つのタイプのいずれにもapplication / xmlおよびtext / xmlを使用できることに注意してください。ただし、実際にはまれでした。
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エンティティではありません。
Compared to [RFC2376] or [RFC3023], this specification alters the handling of character encoding of text/xml and text/xml-external-parsed-entity, treating them no differently from the respective application/ types. However, application/xml and application/xml-external-parsed-entity are still RECOMMENDED, to avoid possible confusion based on the earlier distinction. The former confusion around the question of default character sets for the two text/ types no longer arises because
[RFC2376]または[RFC3023]と比較して、この仕様はtext / xmlおよびtext / xml-external-parsed-entityの文字エンコーディングの処理を変更し、それぞれのapplication /タイプと同じように扱います。ただし、application / xmlおよびapplication / xml-external-parsed-entityは、以前の区別に基づく混乱を避けるために、引き続き推奨されます。 2つのテキスト/タイプのデフォルトの文字セットの問題に関する以前の混乱は、もはや発生しません。
[RFC7231] changes [RFC2616] by removing the ISO-8859-1 default and not defining any default at all;
[RFC7231]は、ISO-8859-1のデフォルトを削除し、デフォルトをまったく定義しないことで[RFC2616]を変更します。
[RFC6657] updates [RFC2046] to remove the US-ASCII [ASCII] default.
[RFC6657]は[RFC2046]を更新してUS-ASCII [ASCII]デフォルトを削除します。
See Section 3 for the now-unified approach to the charset parameter that results.
結果として生じるcharsetパラメータへの今統一されたアプローチについてはセクション3を参照してください。
XML provides a general framework for defining sequences of structured data. It is often appropriate to define new media types that use XML but define a specific application of XML, due to domain-specific display, editing, security considerations, or runtime information. Furthermore, such media types may allow only UTF-8 and/or UTF-16 and prohibit other character sets. This specification does not prohibit such media types; in fact, they are expected to proliferate.
XMLは、構造化データのシーケンスを定義するための一般的なフレームワークを提供します。多くの場合、ドメイン固有の表示、編集、セキュリティの考慮事項、または実行時情報のため、XMLを使用する新しいメディアタイプを定義し、XMLの特定のアプリケーションを定義することが適切です。さらに、このようなメディアタイプでは、UTF-8および/またはUTF-16のみが許可され、他の文字セットは禁止されます。この仕様では、このようなメディアタイプを禁止していません。実際、彼らは急増すると予想されています。
However, developers of such media types are RECOMMENDED to use this specification as a basis for their registration. See Section 4.2 for more detailed recommendations on using the '+xml' suffix for registration of such media types.
ただし、そのようなメディアタイプの開発者は、この仕様を登録の基礎として使用することをお勧めします。そのようなメディアタイプの登録に「+ xml」サフィックスを使用することに関するより詳細な推奨事項については、セクション4.2を参照してください。
An XML document labeled as application/xml or text/xml, or with a '+xml' media type, 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 Cascading Style Sheets (CSS) stylesheet. Such a document might be handled by applications that would use this information to dispatch the document for appropriate processing. Appendix B lists the core XML specifications that, taken together with [XML] itself, show how to determine an XML document's language-level semantics and suggest how information about its application-level semantics may be locatable.
application / xmlまたはtext / xmlとラベル付けされた、または「+ xml」メディアタイプのXMLドキュメントには、名前空間宣言、スタイルシートリンク処理命令（PI）、スキーマ情報、または方法を提案するために使用できる他の宣言が含まれる場合があります文書は処理されます。たとえば、ドキュメントにはXHTML名前空間とカスケードスタイルシート（CSS）スタイルシートへの参照がある場合があります。このようなドキュメントは、この情報を使用して適切な処理のためにドキュメントをディスパッチするアプリケーションによって処理される場合があります。付録Bは、[XML]自体と合わせて、XMLドキュメントの言語レベルのセマンティクスを決定する方法を示し、そのアプリケーションレベルのセマンティクスに関する情報を特定できる方法を提案するコアXML仕様を示しています。
In Section 9.6, this specification updates the registration in [RFC6839] for XML-based MIME types (the '+xml' types).
セクション9.6では、この仕様は[RFC6839]のXMLベースのMIMEタイプ（ '+ xml'タイプ）の登録を更新します。
When a new media type is introduced for an XML-based format, the name of the media type SHOULD end with '+xml' unless generic XML processing is in some way inappropriate for documents of the new type. 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 check for types that represent XML MIME entities by comparing the last four characters of the subtype to the string '+xml'. (However, note that four of the five media types defined in this specification -- text/ xml, application/xml, text/xml-external-parsed-entity, and application/xml-external-parsed-entity -- also represent XML MIME entities while not ending with '+xml'.)
XMLベースのフォーマットに新しいメディアタイプが導入された場合、ジェネリックXML処理が新しいタイプのドキュメントに何らかの形で不適切でない限り、メディアタイプの名前は「+ xml」で終わる必要があります（SHOULD）。この規則により、XMLを一般的に処理できるアプリケーションは、MIMEエンティティがXMLドキュメントであることになっていることを検出し、XMLプロセッサを呼び出してこの仮定を確認し、それに応じてXMLドキュメントを処理できます。アプリケーションは、サブタイプの最後の4文字を文字列 '+ xml'と比較することにより、XML MIMEエンティティを表すタイプをチェックできます。 （ただし、この仕様で定義されている5つのメディアタイプのうち4つ-text / xml、application / xml、text / xml-external-parsed-entity、およびapplication / xml-external-parsed-entity-もXMLを表すことに注意してください「+ xml」で終わっていないMIMEエンティティ。）
NOTE: Section 5.3.2 of [RFC7231] does not support any form of Accept header that will match only '+xml' types. In particular, Accept headers of the form "Accept: */*+xml" are not allowed, and will not work for this purpose.
注：[RFC7231]のセクション5.3.2は、「+ xml」タイプのみに一致するAcceptヘッダーの形式をサポートしていません。特に、「Accept：* / * + xml」形式のAcceptヘッダーは許可されておらず、この目的には使用できません。
Media types following the naming convention '+xml' SHOULD define the charset parameter for consistency, since XML-generic processing by definition treats all XML MIME entities uniformly as regards character encoding information. However, there are some cases that the charset parameter need not be defined. For example:
命名規則「+ xml」に従うメディアタイプは、XMLジェネリック処理がすべてのXML MIMEエンティティを文字エンコーディング情報に関して均一に扱うため、整合性のために文字セットパラメータを定義する必要があります（SHOULD）。ただし、charsetパラメータを定義する必要がない場合もあります。例えば：
When an XML-based media type is restricted to UTF-8, it is not necessary to define the charset parameter. UTF-8 is the default for XML.
XMLベースのメディアタイプがUTF-8に制限されている場合、charsetパラメータを定義する必要はありません。 XMLのデフォルトはUTF-8です。
When an XML-based media type is restricted to UTF-8 and UTF-16, it might not be unreasonable to omit the charset parameter. Neither UTF-8 nor UTF-16 require XML encoding declarations.
XMLベースのメディアタイプがUTF-8およびUTF-16に制限されている場合、charsetパラメータを省略することは不合理ではない可能性があります。 UTF-8もUTF-16もXMLエンコーディング宣言を必要としません。
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 -- the '+xml' convention is to be preferred unless there is some particularly compelling reason not to use it.
XMLの汎用処理は、XMLベースのメディアタイプには必ずしも適切ではありません。たとえば、そのようなメディアタイプの作成者は、そのメディアタイプを処理するように特別に設計されたアプリケーションを除いて、タイプが完全に不透明であることを望んでいる場合があります。命名規則「+ xml」に従わないことにより、そのようなメディアタイプはXMLジェネリック処理を回避できます。ただし、一般的な処理は多くの場合に役立ちます-事前に予測するのが難しい状況を含む-使用しない特別な説得力のある理由がない限り、 '+ xml'の方が好ましいでしょう。
The registration process for specific '+xml' media types is described in [RFC6838]. New XML-based media type registrations in the IETF must follow these guidelines. When other organisations register XML-based media types via the "Specification Required" IANA registration policy [RFC5226], the relevant Media Reviewer should ensure that they use the '+xml' convention, in order to ensure maximum interoperability of their XML-based documents. Only media subtypes that represent XML MIME entities are allowed to register with a '+xml' suffix.
特定の「+ xml」メディアタイプの登録プロセスは、[RFC6838]で説明されています。 IETFでの新しいXMLベースのメディアタイプ登録は、これらのガイドラインに従う必要があります。他の組織が "Specification Required" IANA登録ポリシー[RFC5226]を介してXMLベースのメディアタイプを登録する場合、関連するMedia Reviewerは、XMLベースのドキュメントの相互運用性を最大限に確保するために、「+ xml」規則を使用していることを確認する必要があります。 。 XML MIMEエンティティを表すメディアサブタイプのみが「+ xml」サフィックスで登録できます。
In addition to the changes described above, the change controller has been changed to be the World Wide Web Consortium (W3C).
上記の変更に加えて、変更コントローラーはWorld Wide Web Consortium（W3C）に変更されました。
Registrations for new XML-based media types that do _not_ use the '+xml' suffix 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 7303".
新しいXMLベースのメディアタイプの登録では、「+ xml」接尾辞を使用しないでください（SHOULD）。charsetパラメータの指定とエンコードに関する考慮事項では、次のように定義します。 RFC 7303」。
Defining the charset parameter is RECOMMENDED, since this information can be used by XML processors to determine authoritatively the character encoding of the XML MIME entity in the absence of a BOM. If there are some reasons not to follow this advice, they SHOULD be included as part of the registration. As shown above, two such reasons are "UTF-8 only" or "UTF-8 or UTF-16 only".
BOMがない場合にXML MIMEエンティティの文字エンコーディングを正式に決定するためにこの情報をXMLプロセッサが使用できるため、charsetパラメータの定義は推奨されています。このアドバイスに従わない理由がある場合は、それらを登録の一部として含める必要があります。上記のように、2つの理由は「UTF-8のみ」または「UTF-8またはUTF-16のみ」です。
These registrations SHOULD specify that the XML-based media type being registered has all of the security considerations described in this specification plus any additional considerations specific to that media type.
これらの登録は、登録されるXMLベースのメディアタイプに、この仕様で説明されているすべてのセキュリティの考慮事項と、そのメディアタイプに固有の追加の考慮事項があることを指定する必要があります（SHOULD）。
These registrations SHOULD also make reference to this specification in specifying magic numbers, base URIs, and use of the BOM.
これらの登録は、マジックナンバー、ベースURI、およびBOMの使用を指定する際にも、この仕様を参照する必要があります（SHOULD）。
These registrations MAY reference the application/xml registration in this document in specifying interoperability and fragment identifier considerations, if these considerations are not overridden by issues specific to that media type.
これらの考慮事項がそのメディアタイプに固有の問題によって上書きされない場合、これらの登録は、相互運用性とフラグメント識別子の考慮事項を指定する際に、このドキュメントのapplication / xml登録を参照する場合があります。
Uniform Resource Identifiers (URIs) can contain fragment identifiers (see Section 3.5 of [RFC3986]). Specifying the syntax and semantics of fragment identifiers is devolved by [RFC3986] to the appropriate media type registration.
Uniform Resource Identifier（URI）にはフラグメント識別子を含めることができます（[RFC3986]のセクション3.5を参照）。フラグメント識別子の構文とセマンティクスの指定は、[RFC3986]によって適切なメディアタイプ登録に委譲されています。
The syntax and semantics of fragment identifiers for the XML media
types defined in this specification are based on the
[XPointerFramework] W3C Recommendation. It allows simple names and
more complex constructions based on named schemes. When the syntax
of a fragment identifier part of any URI or Internationalized
Resource Identifier (IRI) ([RFC3987]) with a retrieved media type
governed by this specification conforms to the syntax specified in
[XPointerFramework], conforming applications MUST interpret such
fragment identifiers as designating whatever is specified by the
[XPointerFramework] together with any other specifications governing
the XPointer schemes used in those identifiers that the applications
support. Conforming applications MUST support the 'element' scheme
as defined in [XPointerElement], but need not support other schemes.
If an XPointer error is reported in the attempt to process the part, this specification does not define an interpretation for the part.
パーツを処理しようとしてXPointerエラーが報告された場合、この仕様はパーツの解釈を定義していません。
A registry of XPointer schemes [XPtrReg] is maintained at the W3C. Generic processors of XML MIME entities SHOULD NOT implement unregistered XPointer schemes ([XPtrRegPolicy] describes requirements and procedures for registering schemes).
XPointerスキームのレジストリ[XPtrReg]はW3Cで管理されています。 XML MIMEエンティティの汎用プロセッサは、未登録のXPointerスキームを実装してはなりません（[XPtrRegPolicy]は、スキーマを登録するための要件と手順を説明しています）。
See Section 4.2 for additional requirements that apply when an XML-based media type follows the naming convention '+xml'.
XMLベースのメディアタイプが命名規則「+ xml」に従う場合に適用される追加の要件については、セクション4.2を参照してください。
If [XPointerFramework] and [XPointerElement] are inappropriate for some XML-based media type, it SHOULD NOT follow the naming convention '+xml'.
[XPointerFramework]と[XPointerElement]が一部のXMLベースのメディアタイプに不適切な場合は、命名規則 '+ xml'に従わないでください。
When a URI has a fragment identifier, it is encoded by a limited subset of the repertoire of US-ASCII characters, see [XPointerFramework] for details.
URIにフラグメント識別子がある場合、それはUS-ASCII文字のレパートリーの限定されたサブセットによってエンコードされます。詳細については、[XPointerFramework]を参照してください。
An XML MIME entity of type application/xml, text/xml, application/ xml-external-parsed-entity, or text/xml-external-parsed-entity MAY use the xml:base attribute, as described in [XMLBase], to embed a base URI in that entity for use in resolving relative URI references (see Section 5.1 of [RFC3986]).
タイプapplication / xml、text / xml、application / xml-external-parsed-entity、またはtext / xml-external-parsed-entityのXML MIMEエンティティは、[XMLBase]で説明されているように、xml：base属性を使用して、相対URI参照の解決に使用するために、そのエンティティにベースURIを埋め込みます（[RFC3986]のセクション5.1を参照）。
Note that the base URI itself might be embedded in a different MIME entity, since the default value for the xml:base attribute can be specified in an external DTD subset or external parameter entity. Since conforming XML processors need not always read and process external entities, the effect of such an external default is uncertain; therefore, its use is NOT RECOMMENDED.
xml：base属性のデフォルト値は外部DTDサブセットまたは外部パラメーターエンティティで指定できるため、ベースURI自体が別のMIMEエンティティに埋め込まれている可能性があることに注意してください。準拠するXMLプロセッサは常に外部エンティティを読み取って処理する必要がないため、そのような外部デフォルトの影響は不確かです。したがって、その使用は推奨されません。
application/xml, application/xml-external-parsed-entity, application/ xml-dtd, text/xml, and text/xml-external-parsed-entity are to be used with [XML]. In all examples herein where version="1.0" is shown, it is understood that version="1.1" might also appear, providing the content does indeed conform to [XML1.1].
application / xml、application / xml-external-parsed-entity、application / xml-dtd、text / xml、およびtext / xml-external-parsed-entityは、[XML]で使用されます。ここでversion = "1.0"が示されているすべての例では、コンテンツが実際に[XML1.1]に準拠している場合、version = "1.1"も表示される可能性があることがわかります。
The normative requirement of this specification upon XML documents and processors is to follow the requirements of [XML], Section 4.3.3.
XML文書およびプロセッサに対するこの仕様の標準的な要件は、[XML]、セクション4.3.3の要件に従うことです。
Except for minor clarifications, that section is substantially identical from the first edition to the current (5th) edition of XML 1.0, and for XML 1.1 first or second edition [XML1.1]. Therefore, references herein to [XML] may be interpreted as referencing any existing version or edition of XML, or any subsequent edition or version that makes no incompatible changes to that section.
軽微な説明を除いて、そのセクションは、XML 1.0の初版から現在（第5版）まで、およびXML 1.1の初版または第2版[XML1.1]と実質的に同じです。したがって、ここでの[XML]への言及は、XMLの既存のバージョンまたはエディション、またはそのセクションに互換性のない変更を行わない後続のエディションまたはバージョンを指すと解釈される場合があります。
Specifications and recommendations based on or referring to this RFC SHOULD indicate any limitations on the particular versions or editions of XML to be used.
このRFCに基づく、またはこれを参照する仕様と推奨事項は、使用されるXMLの特定のバージョンまたはエディションに対する制限を示しています。
This section is non-normative. In particular, note that all [RFC2119] language herein reproduces or summarizes the consequences of normative statements already made above, and has no independent normative force, and accordingly does not appear in uppercase.
このセクションは非規範的です。特に、ここでのすべての[RFC2119]言語は、すでに上で作成された規範的ステートメントの結果を複製または要約し、独立した規範的な力がないため、大文字で表示されないことに注意してください。
The examples below give the MIME Content-Type header, including the charset parameter, if present and the XML declaration or Text declaration (which includes the encoding declaration) inside the XML MIME entity. For UTF-16 examples, the Byte Order Mark character appropriately UTF-16 encoded is denoted as "{BOM}", and the XML or Text declaration is assumed to come at the beginning of the XML MIME entity, immediately following the encoded BOM. Note that other MIME headers may be present, and the XML MIME entity will normally contain other data in addition to the XML declaration; the examples focus on the Content-Type header and the encoding declaration for clarity.
次の例は、charsetパラメータを含むMIME Content-Typeヘッダーと、XML MIMEエンティティ内のXML宣言またはテキスト宣言（エンコーディング宣言を含む）を示しています。 UTF-16の例の場合、適切にUTF-16でエンコードされたバイトオーダーマーク文字は「{BOM}」として示され、XMLまたはテキスト宣言は、エンコードされたBOMの直後のXML MIMEエンティティの先頭にあると想定されます。他のMIMEヘッダーが存在する場合があり、XML MIMEエンティティには通常、XML宣言に加えて他のデータが含まれることに注意してください。例では、わかりやすくするためにContent-Typeヘッダーとエンコーディング宣言に焦点を当てています。
Although they show a content type of 'application/xml', all the examples below apply to all five media types declared below in Section 9, as well as to any media types declared using the '+xml' convention (with the exception of the examples involving the charset parameter for any such media types that do not enable its use). See the XML MIME entities table (Section 4.1, Paragraph 1) for discussion of which types are appropriate for which varieties of XML MIME entity.
これらは「application / xml」のコンテンツタイプを示していますが、以下のすべての例は、セクション9で宣言された5つすべてのメディアタイプ、および「+ xml」規則を使用して宣言されたすべてのメディアタイプに適用されます（ただし、その使用を有効にしないメディアタイプのcharsetパラメータを含む例）。 XML MIMEエンティティのどの種類にどのタイプが適しているかについては、XML MIMEエンティティの表（セクション4.1、パラグラフ1）を参照してください。
Content-Type: application/xml; charset=utf-8
<?xml version="1.0" encoding="utf-8"?>
or
または
<?xml version="1.0"?>
UTF-8 is the recommended encoding for use with all the media types defined in this specification. Since the charset parameter is provided and there is no overriding BOM, conformant MIME and XML processors must treat the enclosed entity as UTF-8 encoded.
UTF-8は、この仕様で定義されているすべてのメディアタイプで使用するための推奨エンコーディングです。 charsetパラメーターが提供され、オーバーライドするBOMがないため、準拠するMIMEおよびXMLプロセッサーは、囲まれたエンティティーをUTF-8エンコードとして処理する必要があります。
If sent using a 7-bit transport (e.g., SMTP [RFC5321]), in general, a UTF-8 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., BINARY ESMTP or HTTP), no content-transfer-encoding is necessary (or even possible, in the case of HTTP).
7ビットトランスポート（SMTP [RFC5321]など）を使用して送信する場合、通常、UTF-8 XML MIMEエンティティはquoted-printableまたはbase64のcontent-transfer-encodingを使用する必要があります。 8ビットクリーントランスポート（8BITMIME ESMTPやNNTPなど）、またはバイナリクリーントランスポート（BINARY ESMTPやHTTPなど）の場合、コンテンツ転送エンコーディングは不要です（HTTPの場合は可能です）。
Content-Type: application/xml; charset=utf-16
{BOM}<?xml version="1.0" encoding="utf-16"?>
or
または
{BOM}<?xml version="1.0"?>
For the three application/media types defined above, 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., BINARY ESMTP or HTTP), no content-transfer-encoding is necessary (or even possible, in the case of HTTP).
上記で定義された3つのアプリケーション/メディアタイプについて、7ビットトランスポート（SMTPなど）または8ビットクリーントランスポート（8BITMIME ESMTPまたはNNTPなど）を使用して送信する場合、XML MIMEエンティティはquoted-printableでエンコードする必要があります。またはbase64;バイナリクリーントランスポート（BINARY ESMTPやHTTPなど）の場合、content-transfer-encodingは必要ありません（HTTPの場合は可能です）。
As described in [RFC2781], the UTF-16 family must not be used with media types under the top-level type "text" except over HTTP or HTTPS (see Section A.2 of HTTP [RFC7231] for details). Hence, one of the two text/media types defined above can be used with this example only when the XML MIME entity is transmitted via HTTP or HTTPS, which use a MIME-like mechanism and are binary-clean protocols and hence do not perform CR and LF transformations and allow NUL octets. Since HTTP is binary clean, no content-transfer-encoding is necessary (or even possible).
[RFC2781]で説明されているように、HTTPまたはHTTPSを除いて、最上位のタイプ「テキスト」のメディアタイプではUTF-16ファミリーを使用しないでください（詳細については、HTTP [RFC7231]のセクションA.2を参照）。したがって、上記で定義した2つのテキスト/メディアタイプの1つをこの例で使用できるのは、XML MIMEエンティティがHTTPまたはHTTPSを介して送信され、MIMEのようなメカニズムを使用し、バイナリクリーンプロトコルであるためCRを実行しない場合のみです。 LF変換とNULオクテットを許可します。 HTTPはバイナリクリーンであるため、コンテンツ転送エンコーディングは必要ありません（または可能です）。
Content-Type: application/xml
<?xml version="1.0" encoding="iso-8859-1"?>
Since the charset parameter is not provided in the Content-Type header and there is no overriding BOM, conformant XML processors must treat the "iso-8859-1" encoding as authoritative. Conformant XML-unaware MIME processors should make no assumptions about the character encoding of the XML MIME entity.
charsetパラメータはContent-Typeヘッダーで提供されておらず、オーバーライドするBOMがないため、準拠XMLプロセッサは「iso-8859-1」エンコーディングを信頼できるものとして扱う必要があります。準拠するXML非対応MIMEプロセッサは、XML MIMEエンティティの文字エンコーディングについて仮定を行うべきではありません。
Content-Type: application/xml
{BOM}<?xml version="1.0" encoding="utf-16"?>
or
または
{BOM}<?xml version="1.0"?> This example shows a 16-bit MIME entity with no charset parameter. However, since there is a BOM, conformant processors must treat the entity as UTF-16 encoded.
{BOM} <？xml version = "1.0"？>この例は、文字セットパラメータのない16ビットMIMEエンティティを示しています。ただし、BOMがあるため、準拠プロセッサはエンティティをUTF-16エンコードとして処理する必要があります。
Omitting the charset parameter is not recommended in conjunction with media types under the top-level type "application" when used with transports other than HTTP or HTTPS. Media types under the top-level type "text" should not be used for 16-bit MIME with transports other than HTTP or HTTPS (see discussion above in Section 8.2, Paragraph 7).
HTTPまたはHTTPS以外のトランスポートで使用する場合、charsetパラメータを省略することは、最上位のタイプ「アプリケーション」のメディアタイプと組み合わせて使用することはお勧めしません。トップレベルのタイプ「テキスト」の下のメディアタイプは、HTTPまたはHTTPS以外のトランスポートを使用する16ビットMIMEには使用しないでください（上記のセクション8.2、段落7の説明を参照）。
Content-Type: application/xml
<?xml version='1.0'?>
In this example, the charset parameter has been omitted, there is no internal encoding declaration, and there is no BOM. Since there is no BOM or charset parameter, the XML processor follows the requirements in Section 4.3.3, and optionally applies the mechanism described in Appendix F (which is non-normative) of [XML] to determine an encoding of UTF-8. Although the XML MIME entity does not contain an encoding declaration, provided the encoding actually _is_ UTF-8, this is a conforming XML MIME entity.
この例では、charsetパラメータは省略されており、内部エンコーディング宣言はなく、BOMもありません。 BOMまたは文字セットパラメータがないため、XMLプロセッサはセクション4.3.3の要件に従い、オプションで[XML]の付録F（非規範的）で説明されているメカニズムを適用して、UTF-8のエンコーディングを決定します。 XML MIMEエンティティにはエンコーディング宣言が含まれていませんが、エンコーディングが実際にUTF-8である場合、これは準拠するXML MIMEエンティティです。
A conformant XML-unaware MIME processor should make no assumptions about the character encoding of the XML MIME entity.
準拠するXML非対応MIMEプロセッサは、XML MIMEエンティティの文字エンコーディングについて想定しないでください。
See Section 8.1 for transport-related issues for UTF-8 XML MIME entities.
UTF-8 XML MIMEエンティティのトランスポート関連の問題については、セクション8.1を参照してください。
Content-Type: application/xml; charset=utf-16be
<?xml version='1.0' encoding='utf-16be'?>
Observe that, as required for this encoding, there is no BOM. Since the charset parameter is provided and there is no overriding BOM, conformant MIME and XML processors must treat the enclosed entity as UTF-16BE encoded.
このエンコーディングに必要なBOMがないことを確認してください。 charsetパラメーターが提供され、オーバーライドするBOMがないため、準拠するMIMEおよびXMLプロセッサーは、囲まれたエンティティーをUTF-16BEエンコードとして処理する必要があります。
See also the additional considerations in the UTF-16 example in Section 8.2.
セクション8.2のUTF-16の例にある追加の考慮事項も参照してください。
Content-Type: application/xml; charset=iso-2022-kr
<?xml version="1.0" encoding="iso-2022-kr"?>
This example shows the use of a non-UTF character encoding (in this case Hangul, but this example is intended to cover all non-UTF-family character encodings). Since the charset parameter is provided and there is no overriding BOM, conformant processors must treat the enclosed entity as encoded per RFC 1557.
この例は、UTF以外の文字エンコーディングの使用法を示しています（この場合はハングルですが、この例は、UTFファミリ以外のすべての文字エンコーディングを対象としています）。 charsetパラメータが提供され、オーバーライドするBOMがないため、準拠プロセッサは、囲まれたエンティティをRFC 1557に従ってエンコードされたものとして扱う必要があります。
Since ISO-2022-KR [RFC1557] has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport: for character sets needing 8 or more bits, considerations such as those discussed above (Sections 8.1 and 8.2) would apply.
ISO-2022-KR [RFC1557]は7ビットのデータのみを使用するように定義されているため、どのトランスポートでもコンテンツ転送エンコーディングは必要ありません。8ビット以上が必要な文字セットの場合、上記のような考慮事項（8.1節）および8.2）が適用されます。
8.8. INCONSISTENT EXAMPLE: Conflicting Charset and Internal Encoding Declaration
8.8. 矛盾する例：矛盾する文字セットと内部エンコーディング宣言
Content-Type: application/xml; charset=iso-8859-1
<?xml version="1.0" encoding="utf-8"?>
Although the charset parameter is provided in the Content-Type header and there is no BOM and the charset parameter differs from the XML encoding declaration, conformant MIME and XML processors will interoperate. Since the charset parameter is authoritative in the absence of a BOM, conformant processors will treat the enclosed entity as iso-8859-1 encoded. That is, the "UTF-8" encoding declaration will be ignored.
charsetパラメーターはContent-Typeヘッダーで提供されており、BOMはなく、charsetパラメーターはXMLエンコード宣言とは異なりますが、準拠するMIMEおよびXMLプロセッサーは相互運用します。 charsetパラメータはBOMがない場合に信頼できるため、準拠プロセッサは囲まれたエンティティをiso-8859-1エンコードとして扱います。つまり、「UTF-8」エンコーディング宣言は無視されます。
Conformant processors generating XML MIME entities must not label conflicting character encoding information between the MIME Content-Type and the XML declaration unless they have definitive information about the actual encoding, for example, as a result of systematic transcoding. In particular, the addition by servers of an explicit, site-wide charset parameter default has frequently lead to interoperability problems for XML documents.
XML MIMEエンティティを生成する適合プロセッサは、体系的なトランスコーディングの結果など、実際のエンコーディングに関する明確な情報がない限り、MIME Content-TypeとXML宣言の間で競合する文字エンコーディング情報にラベルを付けないでください。特に、サーバーによる明示的なサイト全体の文字セットパラメータのデフォルトの追加により、XMLドキュメントの相互運用性の問題が頻繁に発生します。
Content-Type: application/xml; charset=iso-8859-1
{BOM}<?xml version="1.0"?> Although the charset parameter is provided in the Content-Type header, there is a BOM, so MIME and XML processors may not interoperate. Since the BOM parameter is authoritative for conformant XML processors, they will treat the enclosed entity as UTF-16 encoded. That is, the "iso-8859-1" charset parameter will be ignored. XML-unaware MIME processors on the other hand may be unaware of the BOM and so treat the entity as encoded in iso-8859-1.
{BOM} <？xml version = "1.0"？> Content-Typeヘッダーでcharsetパラメータが提供されていますが、BOMがあるため、MIMEプロセッサとXMLプロセッサが相互運用できない場合があります。 BOMパラメータは準拠XMLプロセッサに対して信頼できるため、囲まれたエンティティをUTF-16エンコードとして扱います。つまり、「iso-8859-1」の文字セットパラメータは無視されます。一方、XML非対応MIMEプロセッサはBOMを認識しない可能性があるため、エンティティをiso-8859-1でエンコードされているものとして扱います。
Conformant processors generating XML MIME entities must not label conflicting character encoding information between the MIME Content-Type and an entity-initial BOM.
XML MIMEエンティティを生成する適合プロセッサは、MIME Content-Typeとエンティティ初期BOMの間の競合する文字エンコーディング情報にラベルを付けてはなりません。
Type name: application
タイプ名：アプリケーション
Subtype name: xml
サブタイプ名：xml
Required parameters: none
必須パラメーター：なし
Optional parameters: charset
オプションのパラメーター：charset
See Section 3.
セクション3を参照してください。
Encoding considerations: Depending on the character encoding used, XML MIME entities can consist of 7bit, 8bit, or binary data [RFC6838]. For 7-bit transports, 7bit data, for example, US-ASCII-encoded data, does not require content-transfer-encoding, but 8bit or binary data, for example, UTF-8 or UTF-16 data, MUST be content-transfer-encoded in quoted-printable or base64. For 8-bit clean transport (e.g., 8BITMIME ESMTP [RFC6152] or NNTP [RFC3977]), 7bit or 8bit data, for example, US-ASCII or UTF-8 data, does not require content-transfer-encoding, but binary data, for example, data with a UTF-16 encoding, MUST be content-transfer-encoded in base64. For binary clean transports (e.g., BINARY ESMTP [RFC3030] or HTTP [RFC7230]), no content-transfer-encoding is necessary (or even possible, in the case of HTTP) for 7bit, 8bit, or binary data.
エンコードに関する考慮事項：使用する文字エンコードに応じて、XML MIMEエンティティは7ビット、8ビット、またはバイナリデータで構成できます[RFC6838]。 7ビットトランスポートの場合、US-ASCIIでエンコードされたデータなどの7ビットデータはcontent-transfer-encodingを必要としませんが、UTF-8またはUTF-16データなどの8ビットまたはバイナリデータはcontent- quoted-printableまたはbase64で転送エンコードされます。 8ビットのクリーントランスポート（8BITMIME ESMTP [RFC6152]またはNNTP [RFC3977]など）の場合、7ビットまたは8ビットのデータ（US-ASCIIまたはUTF-8データなど）では、コンテンツ転送エンコーディングは必要ありませんが、バイナリデータです。たとえば、UTF-16エンコーディングのデータは、base64でコンテンツ転送エンコードする必要があります。バイナリクリーントランスポート（たとえば、BINARY ESMTP [RFC3030]またはHTTP [RFC7230]）の場合、7ビット、8ビット、またはバイナリデータのコンテンツ転送エンコーディングは必要ありません（HTTPの場合は可能です）。
Security considerations: See Section 10.
セキュリティに関する考慮事項：セクション10を参照してください。
Interoperability considerations: XML has proven to be interoperable across both generic and task-specific applications and for import and export from multiple XML authoring and editing tools. Validating processors provide maximum interoperability, because they have to handle all aspects of XML. Although a non-validating processor may be more efficient, it might not handle all aspects. For further information, see Section 2.9 "Standalone Document Declaration" and Section 5 "Conformance" of [XML] .
相互運用性に関する考慮事項：XMLは、汎用アプリケーションとタスク固有のアプリケーションの両方で相互運用可能であり、複数のXMLオーサリングおよび編集ツールからのインポートとエクスポートが可能であることが証明されています。検証プロセッサはXMLのすべての側面を処理する必要があるため、相互運用性を最大限に高めます。非検証プロセッサーの方が効率的ですが、すべての側面を処理できるわけではありません。詳細については、[XML]のセクション2.9「スタンドアロンドキュメント宣言」およびセクション5「適合性」を参照してください。
In practice, character set issues have proved to be the biggest source of interoperability problems. The use of UTF-8, and careful attention to the guidelines set out in Section 3, are the best ways to avoid such problems.
実際には、文字セットの問題が相互運用性の問題の最大の原因であることが判明しています。 UTF-8の使用、およびセクション3に記載されているガイドラインへの注意深い注意は、そのような問題を回避するための最良の方法です。
Published specification: Extensible Markup Language (XML) 1.0 (Fifth Edition) [XML] or subsequent editions or versions thereof.
公開された仕様：Extensible Markup Language（XML）1.0（Fifth Edition）[XML]またはそれ以降のエディションまたはバージョン。
Applications that use this media type: XML is device, platform, and vendor neutral and is supported by generic and task-specific applications and a wide range of generic XML tools (editors, parsers, Web agents, ...).
このメディアタイプを使用するアプリケーション：XMLはデバイス、プラットフォーム、ベンダーに依存せず、汎用およびタスク固有のアプリケーションと幅広い汎用XMLツール（エディター、パーサー、Webエージェントなど）によってサポートされます。
Additional information:
追加情報：
Magic number(s): None.
マジックナンバー：なし。
Although no byte sequences can be counted on to always be present, XML MIME entities in ASCII-compatible character sets (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 BOM followed by "<?xml"). For more information, see Appendix F of [XML].
常に存在するバイトシーケンスはありませんが、ASCII互換の文字セット（UTF-8を含む）のXML MIMEエンティティは、多くの場合、16進数の3C 3F 78 6D 6C（ "<？xml"）で始まり、UTF- 16は多くの場合、16進数のFE FF 00 3C 00 3F 00 78 00 6D 00 6CまたはFF FE 3C 00 3F 00 78 00 6D 00 6C 00で始まります（BOMの後に「<？xml」が続く）。詳細については、[XML]の付録Fを参照してください。
File extension(s): .xml
ファイル拡張子：.xml
Macintosh File Type Code(s): "TEXT"
Macintoshファイルタイプコード：「TEXT」
Base URI: See Section 6
ベースURI：セクション6を参照
Person and email address for further information: See Authors' Addresses section
詳細については、個人と電子メールアドレス：作成者のアドレスセクションを参照してください。
Intended usage: COMMON
使用目的：COMMON
Author: See Authors' Addresses section
著者：著者のアドレスセクションを参照してください
Change controller: The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over RFC 7303.
変更コントローラ：XML仕様は、World Wide WebコンソーシアムのXMLコアワーキンググループの成果物です。 W3CはRFC 7303を変更管理します。
The registration information for text/xml is in all respects the same as that given for application/xml above (Section 9.1), except that the "Type name" is "text".
text / xmlの登録情報は、「タイプ名」が「text」であることを除いて、上記のapplication / xml（セクション9.1）に提供されたものとすべての点で同じです。
Type name: application
タイプ名：アプリケーション
Subtype name: xml-external-parsed-entity
サブタイプ名：xml-external-parsed-entity
Required parameters: none
必須パラメーター：なし
Optional parameters: charset
オプションのパラメーター：charset
See Section 3.
セクション3を参照してください。
Encoding considerations: Same as for application/xml (Section 9.1).
エンコーディングに関する考慮事項：application / xmlと同じ（セクション9.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 enhances interoperability of both XML documents and XML external parsed entities.
相互運用性の考慮事項：XML外部解析エンティティは、XMLドキュメントと同様に相互運用可能ですが、構造の制約が少ないため、XMLプロセッサによる適切な処理のためにXMLドキュメントで参照する必要があります。同様に、XML文書は、外部の解析済みエンティティとしてスタンドアロンのドキュメント宣言またはDTDを持つことが禁止されているため、外部の解析済みエンティティとして確実に使用することはできません。独自のコンテンツタイプを使用してXML外部解析エンティティを識別すると、XMLドキュメントとXML外部解析エンティティの両方の相互運用性が向上します。
Published specification: Same as for application/xml (Section 9.1).
公開された仕様：application / xmlと同じ（セクション9.1）。
Applications which use this media type: Same as for application/xml (Section 9.1).
このメディアタイプを使用するアプリケーション：application / xmlと同じ（セクション9.1）。
Additional information:
追加情報：
Magic number(s): Same as for application/xml (Section 9.1).
マジックナンバー：application / xmlと同じ（セクション9.1）。
File extension(s): .xml or .ent
ファイル拡張子：.xmlまたは.ent
Macintosh File Type Code(s): "TEXT"
Macintoshファイルタイプコード：「TEXT」
Base URI: See Section 6
ベースURI：セクション6を参照
Person and email address for further information: See Authors' Addresses section.
詳細については、個人と電子メールアドレス：作成者のアドレスセクションを参照してください。
Intended usage: COMMON
使用目的：COMMON
Author: See Authors' Addresses section.
作成者：「作成者のアドレス」セクションを参照してください。
Change controller: The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over RFC 7303.
変更コントローラ：XML仕様は、World Wide WebコンソーシアムのXMLコアワーキンググループの成果物です。 W3CはRFC 7303を変更管理します。
The registration information for text/xml-external-parsed-entity is in all respects the same as that given for application/xml-external-parsed-entity above (Section 9.3), except that the "Type name" is "text".
text / xml-external-parsed-entityの登録情報は、「タイプ名」が「text」である点を除き、すべての点で上記のapplication / xml-external-parsed-entity（セクション9.3）に指定されたものと同じです。
Type name: application
タイプ名：アプリケーション
Subtype name: xml-dtd
サブタイプ名：xml-dtd
Required parameters: none
必須パラメーター：なし
Optional parameters: charset
オプションのパラメーター：charset
See Section 3.
セクション3を参照してください。
Encoding considerations: Same as for application/xml (Section 9.1).
エンコーディングに関する考慮事項：application / xmlと同じ（セクション9.1）。
Security considerations: See Section 10.
セキュリティに関する考慮事項：セクション10を参照してください。
Interoperability considerations: XML DTDs have proven to be interoperable by DTD authoring tools and XML validators, among others.
相互運用性の考慮事項：XML DTDは、DTDオーサリングツールやXMLバリデーターなどによって相互運用可能であることが証明されています。
Published specification: Same as for application/xml (Section 9.1).
公開された仕様：application / xmlと同じ（セクション9.1）。
Applications which use this media type: DTD authoring tools handle external DTD subsets as well as external parameter entities. XML validators may also access external DTD subsets and external parameter entities.
このメディアタイプを使用するアプリケーション：DTDオーサリングツールは、外部DTDサブセットと外部パラメーターエンティティを処理します。 XMLバリデーターは、外部DTDサブセットおよび外部パラメーターエンティティにもアクセスできます。
Additional information:
追加情報：
Magic number(s): Same as for application/xml (Section 9.1).
マジックナンバー：application / xmlと同じ（セクション9.1）。
File extension(s): .dtd or .mod
ファイル拡張子：.dtdまたは.mod
Macintosh File Type Code(s): "TEXT"
Macintoshファイルタイプコード：「TEXT」
Person and email address for further information: See Authors' Addresses section.
詳細については、個人と電子メールアドレス：作成者のアドレスセクションを参照してください。
Intended usage: COMMON
使用目的：COMMON
Author: See Authors' Addresses section.
作成者：「作成者のアドレス」セクションを参照してください。
Change controller: The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over RFC 7303.
変更コントローラ：XML仕様は、World Wide WebコンソーシアムのXMLコアワーキンググループの成果物です。 W3CはRFC 7303を変更管理します。
This section supersedes the earlier registration of the '+xml' suffix [RFC6839].
このセクションは、「+ xml」サフィックス[RFC6839]の以前の登録に優先します。
This specification recommends the use of the '+xml' naming convention for identifying XML-based media types, in line with the recognition in [RFC6838] of structured syntax name suffixes. 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.
この仕様では、[RFC6838]での構造化構文名サフィックスの認識に沿って、XMLベースのメディアタイプを識別するために「+ xml」命名規則を使用することを推奨しています。これにより、メディアタイプの登録に既存のフレームワークを使用して、最小限のコストでさまざまなXMLドキュメントタイプで汎用XMLプロセッサとテクノロジーを使用できます。
See Section 4.2 for guidance on when and how to register a media subtype that is '+xml' based, and Section 4.3 on registering a media subtype for XML but _not_ using '+xml'.
「+ xml」ベースのメディアサブタイプを登録する時期と方法に関するガイダンスについてはセクション4.2を、XMLのメディアサブタイプの登録についてはセクション4.3を参照してください。
Name: Extensible Markup Language (XML)
名前：Extensible Markup Language（XML）
+suffix: +xml
Reference: RFC 7303
リファレンス：RFC 7303
Encoding considerations: Same as Section 9.1.
エンコーディングに関する考慮事項：セクション9.1と同じ。
Fragment identifier considerations: Registrations that use this '+xml' convention MUST also make reference to this document, specifically Section 5, in specifying fragment identifier syntax
フラグメント識別子の考慮事項：この「+ xml」規則を使用する登録では、フラグメント識別子の構文を指定する際に、このドキュメント、特にセクション5を参照する必要があります。
and semantics, and they MAY restrict the syntax to a specified subset of schemes, except that they MUST NOT disallow barenames or 'element' scheme pointers. They MAY further require support for other registered schemes. They also MAY add additional syntax (which MUST NOT overlap with [XPointerFramework] syntax) together with associated semantics, and they MAY add additional semantics for barename XPointers that, as provided for in Section 5, will only apply when this document does not define an interpretation.
とセマンティクス、そしてそれらは構文をスキーマの指定されたサブセットに制限してもよい（MAY）。ただし、ベアネームまたは「要素」スキーマポインターを許可してはならない（MUST NOT）。彼らはさらに他の登録されたスキームのサポートを必要とするかもしれません。また、関連するセマンティクスと一緒に追加の構文（[XPointerFramework]構文と重複してはならない）を追加できます。また、セクション5で規定されているように、このドキュメントで定義されていない場合にのみ適用されるベアネームXPointerの追加のセマンティクスを追加できます解釈。
In practice, these constraints imply that for a fragment identifier addressed to an instance of a specific "xxx/yyy+xml" type, there are three cases:
実際には、これらの制約は、特定の「xxx / yyy + xml」タイプのインスタンスにアドレス指定されたフラグメント識別子の場合、3つのケースがあることを意味します。
For fragment identifiers matching the syntax defined in [XPointerFramework], where the fragment identifier resolves per the rules specified there, then process as specified there;
[XPointerFramework]で定義された構文に一致するフラグメント識別子の場合、フラグメント識別子はそこで指定されたルールに従って解決され、そこで指定されたとおりに処理されます。
For fragment identifiers matching the syntax defined in [XPointerFramework], where the fragment identifier does _not_ resolve per the rules specified there, then process as specified in "xxx/yyy+xml";
[XPointerFramework]で定義された構文に一致するフラグメント識別子の場合、フラグメント識別子はそこで指定されたルールに従って解決せず、「xxx / yyy + xml」で指定されたように処理します。
For fragment identifiers _not_ matching the syntax defined in [XPointerFramework], then process as specified in "xxx/ yyy+xml". A fragment identifier of the form "xywh=160,120,320,240", as defined in [MediaFrags], which might be used in a URI for an XML-encoded image, would fall in this category.
[XPointerFramework]で定義されている構文と一致しないフラグメント識別子の場合は、「xxx / yyy + xml」で指定されているように処理します。 [MediaFrags]で定義されている「xywh = 160,120,320,240」形式のフラグメント識別子は、XMLエンコードされた画像のURIで使用される可能性があるため、このカテゴリに分類されます。
Interoperability considerations: Same as Section 9.1. See above, and also Section 3, for guidelines on the use of the 'charset' parameter.
相互運用性に関する考慮事項：セクション9.1と同じ。 「charset」パラメータの使用に関するガイドラインについては、上記およびセクション3を参照してください。
Security considerations: See Section 10.
セキュリティに関する考慮事項：セクション10を参照してください。
Contact: See Authors' Addresses section.
連絡先：「著者のアドレス」セクションを参照してください。
Author: See Authors' Addresses section.
作成者：「作成者のアドレス」セクションを参照してください。
Change controller: The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over RFC 7303.
変更コントローラ：XML仕様は、World Wide WebコンソーシアムのXMLコアワーキンググループの成果物です。 W3CはRFC 7303を変更管理します。
XML MIME entities contain information that may be parsed and further processed by the recipient. These entities may contain, and recipients may permit, explicit system level commands to be executed while processing the data. To the extent that a recipient application executes arbitrary command strings from within XML MIME entities, they may be at risk.
XML MIMEエンティティには、解析して受信者がさらに処理できる情報が含まれています。これらのエンティティには、データの処理中に実行される明示的なシステムレベルのコマンドが含まれ、受信者が許可する場合があります。受信側アプリケーションがXML MIMEエンティティ内から任意のコマンド文字列を実行する限り、それらは危険にさらされる可能性があります。
In general, any information stored outside of the direct control of the user -- including CSS style sheets, XSL transformations, XML-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変換、XMLエンティティ宣言、DTDなど、ユーザーの直接的な制御の外部に格納されている情報は、明白な手段または微妙な手段のいずれかによって、セキュリティのソースになる可能性があります。たとえば、「マスター」スタイルシートに加えられた小さな「ホワイトアウトアタック」変更は、ユーザードキュメントまたはそれが参照するスタイルシートを直接変更せずに、ユーザードキュメント内の重要な場所にある単語を非表示にする可能性があります。したがって、XMLドキュメントのセキュリティは、そのドキュメントが再帰的に参照するすべてのドキュメントに大きく依存しています。
The XML-entity lists and DTDs for XHTML 1.0 [XHTML], for instance, are likely to be a widely exploited set of resources. They will be used and trusted by many developers, 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 [XHTML]のXMLエンティティリストとDTDは、広く利用されているリソースのセットである可能性があります。それらは、多くの開発者によって使用され、信頼されますが、W3Cのサーバーまたは同様に信頼されたリポジトリーのセキュリティーのレベルについて多くを知っている開発者はほとんどいません。
The simplest attack involves adding declarations that break validation. Adding extraneous declarations to a list of character XML-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 attackers, when external DTD subsets or external parameter entities or other externally specified defaulting is involved, is redefining default values for attributes: for example, if developers have relied on defaulted attributes for security, a relatively small change might expose enormous quantities of information.
最も単純な攻撃は、検証に違反する宣言を追加することです。文字XMLエンティティのリストに無関係な宣言を追加すると、ドキュメントで使用されている「契約に違反する」可能性があります。 DTDで致命的なエラーを生成する小さな変更により、XML処理が大規模に停止する可能性があります。無関係な宣言はかなり明白ですが、属性をオプションから必須に変更するなどのより洗練されたトリックは、追跡するのが難しい場合があります。おそらく、攻撃者が利用できる最も危険なオプションは、外部DTDサブセット、外部パラメーターエンティティ、または他の外部指定のデフォルト設定が関係している場合、属性のデフォルト値を再定義することです。膨大な量の情報を公開します。
Apart from the structural possibilities, another option, "XML-entity spoofing," can be used to insert text into documents, vandalizing and perhaps conveying an unintended message. Because XML permits multiple XML-entity declarations, and the first declaration takes precedence, it is possible to insert malicious content where an XML-entity reference is used, such as by inserting the full text of Winnie the Pooh in place of every occurrence of —.
構造的な可能性とは別に、「XMLエンティティのなりすまし」という別のオプションを使用して、ドキュメントにテキストを挿入し、意図しないメッセージを破壊および伝達することができます。 XMLは複数のXMLエンティティ宣言を許可し、最初の宣言が優先されるため、＆が出現するたびに代わりにWinnie the Poohの全文を挿入するなど、XMLエンティティ参照が使用されている悪意のあるコンテンツを挿入することが可能ですmdash;。
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にはエスケープシーケンスを含めることができます。このエスケープシーケンスは、表示されると、後続の操作に悪影響を与える方法でディスプレイプロセッサ環境を変更する可能性があります。可能性のある影響には、キーボードのロック、表示パラメータの変更による後続の表示テキストの判読不能、または表示パラメータの変更による後続の表示資料の意図的な不明瞭化または変形などが含まれますが、これらに限定されません。ディスプレイプロセッサは、表示されたテキストからそのような素材をフィルタリングするか、特定の表示操作が完了した後にすべての重要な設定をリセットする必要があります。
With some terminal devices, sending particular character sequences to the display processor can change the output of subsequent key presses. 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.
一部の端末デバイスでは、特定の文字シーケンスをディスプレイプロセッサに送信すると、その後のキープレスの出力が変わる可能性があります。これが可能である場合、そのような文字シーケンスを含むテキストオブジェクトの表示は、ユーザーがキーを押し続けたときに、キーを再プログラムして、不法または危険なアクションを実行する可能性があります。キーをプログラムできるだけでなく、リモートでトリガーできる場合もあり、テキスト表示操作で不要なアクションを直接実行できます。したがって、キーをプログラムする機能は、フィルタリングするか、キーを完全にプログラムする機能を無効にすることによってブロックする必要があります（SHOULD）。
Note that it is also possible to construct XML documents that make use of what XML terms "[XML-]entity references" 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. For example, consider the case where XML-entity A consists of 100 copies of XML-entity B, which in turn consists of 100 copies of XML-entity C, and so on.
「[XML-]エンティティ参照」というXML用語を利用してテキストの繰り返し拡張を構築するXMLドキュメントを構築することも可能であることに注意してください。再帰的拡張は[XML]によって禁止されており、それらを検出するにはXMLプロセッサが必要です。ただし、非再帰的な拡張であっても、何度も実行すると、コンピューターの有限のコンピューティングリソースに問題が発生する可能性があります。たとえば、XMLエンティティAがXMLエンティティBの100コピーで構成され、さらにXMLエンティティBがXMLエンティティCの100コピーで構成される場合を考えます。
[IANA-CHARSETS] IANA, "Character Sets Registry", 2013, <http://www.iana.org/assignments/character-sets/>.
[IANA-CHARSETS] IANA、「Character Sets Registry」、2013、<http://www.iana.org/assignments/character-sets/>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781] Hoffman、P。およびF. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978] Freed、N。およびJ. Postel、「IANA Charset Registration Procedures」、BCP 19、RFC 2978、2000年10月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] Duerst、M。およびM. Suignard、「Internationalized Resource Identifiers（IRIs）」、RFC 3987、2005年1月。
[RFC6657] Melnikov, A. and J. Reschke, "Update to MIME regarding "charset" Parameter Handling in Textual Media Types", RFC 6657, July 2012.
[RFC6657] Melnikov、A。およびJ. Reschke、「テキストメディアタイプの「charset」パラメータ処理に関するMIMEの更新」、RFC 6657、2012年7月。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、2013年1月。
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, January 2013.
[RFC6839] Hansen、T。およびA. Melnikov、「Additional Media Type Structured Syntax Suffixes」、RFC 6839、2013年1月。
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230] Fielding、R。およびJ. Reschke、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、2014年6月。
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231] Fielding、R。およびJ. Reschke、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、2014年6月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 7.0.0", (Mountain View, CA: The Unicode Consortium, 2014 ISBN 978-1-936213-09-2), <http://www.unicode.org/versions/Unicode7.0.0/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard、Version 7.0.0 "、（Mountain View、CA：The Unicode Consortium、2014 ISBN 978-1-936213-09-2）、<http：//www.unicode。 org / versions / Unicode7.0.0 />。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126/>.
[XML] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、W3C勧告REC-xml、 2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126/>。
Latest version available at <http://www.w3.org/TR/xml>.
<http://www.w3.org/TR/xml>で入手可能な最新バージョン。
[XML1.1] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Recommendation REC-xml, September 2006, <http://www.w3.org/TR/2006/REC-xml11-20060816/>.
[XML1.1] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E.、Yergeau、F.、J。Cowan、「Extensible Markup Language（XML）1.1（Second Edition）」 、W3C勧告REC-xml、2006年9月、<http://www.w3.org/TR/2006/REC-xml11-20060816/>。
Latest version available at <http://www.w3.org/TR/xml11>.
<http://www.w3.org/TR/xml11>で入手可能な最新バージョン。
[XMLBase] Marsh, J. and R. Tobin, "XML Base (Second Edition)", W3C Recommendation REC-xmlbase-20090128, January 2009, <http://www.w3.org/TR/2009/REC-xmlbase-20090128/>.
[XMLBase] Marsh、J.およびR. Tobin、「XML Base（Second Edition）」、W3C勧告REC-xmlbase-20090128、2009年1月、<http://www.w3.org/TR/2009/REC-xmlbase -20090128 />。
Latest version available at <http://www.w3.org/TR/xmlbase>.
<http://www.w3.org/TR/xmlbase>で入手可能な最新バージョン。
[XPointerElement] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer element() Scheme", W3C Recommendation REC-XPointer-Element, March 2003, <http://www.w3.org/TR/2003/REC-xptr-element-20030325/>.
[XPointerElement] Grosso、P.、Maler、E.、Marsh、J。、およびN. Walsh、「XPointer element()スキーム」、W3C勧告REC-XPointer-Element、2003年3月、<http：//www.w3 .org / TR / 2003 / REC-xptr-element-20030325 />。
Latest version available at <http://www.w3.org/TR/xptr-element>.
<http://www.w3.org/TR/xptr-element>で入手可能な最新バージョン。
[XPointerFramework] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer Framework", W3C Recommendation REC-XPointer-Framework, March 2003, <http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>.
[XPointerFramework] Grosso、P.、Maler、E.、Marsh、J。、およびN. Walsh、「XPointer Framework」、W3C勧告REC-XPointer-Framework、2003年3月、<http://www.w3.org/ TR / 2003 / REC-xptr-framework-20030325 />。
Latest version available at <http://www.w3.org/TR/xptr-framework>.
<http://www.w3.org/TR/xptr-framework>で入手可能な最新バージョン。
[XPtrReg] Hazael-Massieux, D., "XPointer Registry", 2005, <http://www.w3.org/2005/04/xpointer-schemes/>.
[XPtrReg] Hazael-Massieux、D。、「XPointer Registry」、2005、<http://www.w3.org/2005/04/xpointer-schemes/>。
[XPtrRegPolicy] Hazael-Massieux, D., "XPointer Scheme Name Registry Policy", 2005, <http://www.w3.org/2005/04/xpointer-policy.html>.
[XPtrRegPolicy] Hazael-Massieux、D。、「XPointer Scheme Name Registry Policy」、2005、<http://www.w3.org/2005/04/xpointer-policy.html>。
[ASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[ASCII] American National Standards Institute、「Coded Character Set-7-bit American Standard Code for Information Interchange」、ANSI X3.4、1986。
[AWWW] Jacobs, I. and N. Walsh, "Architecture of the World Wide Web, Volume One", W3C Recommendation REC-webarch-20041215, December 2004, <http://www.w3.org/TR/2004/REC-webarch-20041215/>.
[AWWW] Jacobs、I.およびN. Walsh、「Architecture of the World Wide Web、Volume One」、W3C勧告REC-webarch-20041215、2004年12月、<http://www.w3.org/TR/2004/ REC-webarch-20041215 />。
Latest version available at <http://www.w3.org/TR/webarch>.
<http://www.w3.org/TR/webarch>で入手可能な最新バージョン。
[FYN] Mendelsohn, N., "The Self-Describing Web", W3C TAG Finding selfDescribingDocuments-2009-02-07, February 2009, <http://www.w3.org/2001/tag/doc/ selfDescribingDocuments-2009-02-07.html>.
[年度] Mendelsohn、N。、「The Self-Describing Web」、W3C TAG Finding selfDescribingDocuments-2009-02-07、2009年2月、<http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2009 -02-07.html>。
Latest version available at
<http://www.w3.org/2001/tag/doc/
selfDescribingDocuments.html>
[Infoset] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C Recommendation REC-xml-infoset-20040204, Febuary 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>.
[Infoset] Cowan、J。およびR. Tobin、「XML Information Set（Second Edition）」、W3C勧告REC-xml-infoset-20040204、2004年2月、<http://www.w3.org/TR/2004/ REC-xml-infoset-20040204 />。
Latest version available at <http://www.w3.org/TR/xml-infoset/>.
<http://www.w3.org/TR/xml-infoset/>で入手可能な最新バージョン。
[MediaFrags] Troncy, R., Mannens, E., Pfeiffer, S., and D. Van Deursen, "Media Fragments URI 1.0 (basic)", W3C Recommendation media-frags, September 2012, <http://www.w3.org/TR/2012/REC-media-frags-20120925/>.
[MediaFrags] Troncy、R.、Mannens、E.、Pfeiffer、S。、およびD. Van Deursen、「Media Fragments URI 1.0（basic）」、W3C Recommendation media-frags、2012年9月、<http：// www。 w3.org/TR/2012/REC-media-frags-20120925/>。
Latest version available at <http://www.w3.org/TR/media-frags>.
<http://www.w3.org/TR/media-frags>で入手可能な最新バージョン。
[RFC1557] Choi, U., Chon, K., and H. Park, "Korean Character Encoding for Internet Messages", RFC 1557, December 1993.
[RFC1557] Choi、U.、Chon、K。、およびH. Park、「インターネットメッセージの韓国語文字エンコーディング」、RFC 1557、1993年12月。
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.
[RFC2376]ホワイトヘッド、E。およびM.ムラタ、「XMLメディアタイプ」、RFC 2376、1998年7月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[RFC3030] Vaudreuil、G。、「大規模なバイナリMIMEメッセージの送信用のSMTPサービス拡張」、RFC 3030、2000年12月。
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[RFC3977] Feather、C。、「Network News Transfer Protocol（NNTP）」、RFC 3977、2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.
[RFC6152]クレンシン、J。、フリード、N。、ローズ、M。、およびD.クロッカー、「8ビットMIMEトランスポート用のSMTPサービス拡張」、STD 71、RFC 6152、2011年3月。
[Sivonen] Sivonen, H. and others, "Mozilla bug: Remove support for UTF-32 per HTML5 spec", October 2011, <https://bugzilla.mozilla.org/show_bug.cgi?id=604317#c6>.
[Sivonen] Sivonen、H。、他、「Mozillaバグ：HTML5仕様に従ってUTF-32のサポートを削除」、2011年10月、<https://bugzilla.mozilla.org/show_bug.cgi?id=604317#c6>。
[TAGMIME] Bray, T., Ed., "Internet Media Type registration, consistency of use", April 2004, <http://www.w3.org/2001/tag/2004/0430-mime>.
[TAGMIME]ブレイ、T。、編、「インターネットメディアタイプの登録、使用の一貫性」、2004年4月、<http://www.w3.org/2001/tag/2004/0430-mime>。
[XHTML] Pemberton, S. and et al, "XHTML 1.0: The Extensible HyperText Markup Language", W3C Recommendation xhtml1, December 1999, <http://www.w3.org/TR/2000/REC-xhtml1-20000126/>.
[XHTML] Pemberton、S.ほか、「XHTML 1.0：The Extensible HyperText Markup Language」、W3C勧告xhtml1、1999年12月、<http://www.w3.org/TR/2000/REC-xhtml1-20000126/ >。
Latest version available at <http://www.w3.org/TR/xhtml1>.
<http://www.w3.org/TR/xhtml1>で入手可能な最新バージョン。
[XMLModel] Grosso, P. and J. Kosek, "Associating Schemas with XML documents 1.0 (Third Edition)", W3C Working Group Note NOTE-xml-model-20121009, October 2012, <http://www.w3.org/TR/2012/NOTE-xml-model-20121009/>.
[XMLModel] Grosso、P。およびJ. Kosek、「スキーマとXMLドキュメント1.0（第3版）の関連付け」、W3CワーキンググループノートNOTE-xml-model-20121009、2012年10月、<http://www.w3.org / TR / 2012 / NOTE-xml-model-20121009 />。
Latest version available at <http://www.w3.org/TR/xml-model>.
<http://www.w3.org/TR/xml-model>で入手可能な最新バージョン。
[XMLNS10] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208/>.
[XMLNS10] Bray、T.、Hollander、D.、Layman、A.、Tobin、R。、およびH. Thompson、「Namespaces in XML 1.0（Third Edition）」、W3C勧告REC-xml-names-20091208、12月2009、<http://www.w3.org/TR/2009/REC-xml-names-20091208/>。
Latest version available at <http://www.w3.org/TR/xml-names>.
<http://www.w3.org/TR/xml-names>で入手可能な最新バージョン。
[XMLNS11] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.1 (Second Edition)", W3C Recommendation REC-xml-names11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-names11-20060816/>.
[XMLNS11] Bray、T.、Hollander、D.、Layman、A。、およびR. Tobin、「Namespaces in XML 1.1（Second Edition）」、W3C勧告REC-xml-names11-20060816、2006年8月、<http： //www.w3.org/TR/2006/REC-xml-names11-20060816/>。
Latest version available at <http://www.w3.org/TR/xml-names11>.
<http://www.w3.org/TR/xml-names11>で入手可能な最新バージョン。
[XMLSS] Clark, J., Pieters, S., and H. Thompson, "Associating Style Sheets with XML documents 1.0 (Second Edition)", W3C Recommendation REC-xml-stylesheet-20101028, October 2010, <http://www.w3.org/TR/2010/REC-xml-stylesheet-20101028/>.
[XMLSS] Clark、J.、Pieters、S。、およびH. Thompson、「スタイルシートとXMLドキュメント1.0（第2版）の関連付け」、W3C勧告REC-xml-stylesheet-20101028、2010年10月、<http：// www.w3.org/TR/2010/REC-xml-stylesheet-20101028/>。
Latest version available at <http://www.w3.org/TR/xml-stylesheet>.
<http://www.w3.org/TR/xml-stylesheet>で入手可能な最新バージョン。
[XMLid] Marsh, J., Veillard, D., and N. Walsh, "xml:id Version 1.0", W3C Recommendation REC-xml-id-20050909, September 2005, <http://www.w3.org/TR/2005/REC-xml-id-20050909/>.
[XMLid] Marsh、J.、Veillard、D。、およびN. Walsh、「xml：idバージョン1.0」、W3C勧告REC-xml-id-20050909、2005年9月、<http://www.w3.org/ TR / 2005 / REC-xml-id-20050909 />。
Latest version available at <http://www.w3.org/TR/xml-id>.
<http://www.w3.org/TR/xml-id>で入手可能な最新バージョン。
Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types?
付録A. XMLベースのMIMEタイプに「+ xml」サフィックスを使用する理由
[RFC3023] contains a detailed discussion of the (at the time) novel use of a suffix, a practice that has since become widespread. Those interested in a historical perspective on this topic are referred to [RFC3023], Appendix A.
[RFC3023]には、サフィックスの（当時の）斬新な使用法の詳細な説明が含まれています。このトピックの歴史的視点に関心のある人は、[RFC3023]、付録Aを参照してください。
The registration process for new '+xml' media types is described in [RFC6838].
新しい「+ xml」メディアタイプの登録プロセスは、[RFC6838]で説明されています。
The following specifications each articulate key aspects of XML document semantics:
次の仕様はそれぞれ、XMLドキュメントのセマンティクスの主要な側面を明確に示しています。
Namespaces in XML 1.0 [XMLNS10]/Namespaces in XML 1.1 [XMLNS11]
XML 1.0の名前空間[XMLNS10] / XML 1.1の名前空間[XMLNS11]
XML Information Set [Infoset]
XML情報セット[情報セット]
xml:id [XMLid]
xml：id [XMLid]
XML Base [XMLBase]
XMLベース[XMLBase]
Associating Style Sheets with XML documents [XMLSS]
スタイルシートとXMLドキュメントの関連付け[XMLSS]
Associating Schemas with XML documents [XMLModel]
スキーマとXMLドキュメントの関連付け[XMLModel]
The W3C Technical Architecture group has produced two documents that are also relevant:
W3Cテクニカルアーキテクチャグループは、関連する2つのドキュメントを作成しました。
The Self-Describing Web [FYN] discusses the overall principles of how document semantics are determined on the Web.
自己記述型Web [FYN]では、Web上でドキュメントのセマンティクスを決定する方法の全体的な原則について説明しています。
Architecture of the World Wide Web, Volume One [AWWW], Section 4.5.4, discusses the specific role of XML Namespace documents in this process.
World Wide Webのアーキテクチャ、第1巻[AWWW]、セクション4.5.4では、このプロセスにおけるXML名前空間ドキュメントの特定の役割について説明しています。
This section provides an informal summary of the major operational considerations that arise when exchanging XML MIME entities over a network.
このセクションでは、ネットワークを介してXML MIMEエンティティを交換するときに発生する主な運用上の考慮事項の非公式の概要を示します。
The existence of both XML-aware and XML-unaware agents handling XML MIME entities can compromise introperability. Generic transcoding proxies pose a particular risk in this regard. Detailed advice about the handling of BOMs when transcoding can be found in Section 3.3.
XML MIMEエンティティを処理するXML対応エージェントとXML非対応エージェントの両方が存在すると、侵入可能性が損なわれる可能性があります。一般的なトランスコーディングプロキシは、この点で特定のリスクをもたらします。トランスコーディング時のBOMの処理に関する詳細なアドバイスは、セクション3.3にあります。
This specification requires XML consumers to treat BOMs as authoritative: this is in principle a backwards-incompatibility. In practice, serious interoperability issues already exist when BOMs are used. Making BOMs authoritative, in conjunction with the deprecation of the UTF-32 encoding form and the requirement to include an XML encoding declaration in certain cases (Section 3.1), is intended to improve in-practice interoperability as much as possible over time.
この仕様では、XMLコンシューマーがBOMを信頼できるものとして扱う必要があります。これは、原則として下位互換性がありません。実際には、BOMを使用する場合、深刻な相互運用性の問題がすでに存在しています。 BOMを信頼できるものにすることは、UTF-32エンコーディング形式の廃止と、特定の場合にXMLエンコーディング宣言を含める必要があること（セクション3.1）と併せて、実際の相互運用性を可能な限り改善することを目的としています。
This specification establishes Section 5 as the basis for interpreting URIs for XML MIME entities that include fragment identifiers, mandates support only for shorthand ("simple name") and 'element'-scheme fragments and deprecates support for unregistered XPointer schemes by XML MIME entity processors. Accordingly, URIs will interoperate best if they use only simple names and 'element'- scheme fragment identifiers, with registered schemes varying widely in the degree of support to be found in generic tools. XPointer scheme authors can only expect generic tool support if they register their schemes.
この仕様は、フラグメント識別子を含むXML MIMEエンティティのURIを解釈するための基礎としてセクション5を確立し、省略形（「単純名」）と「要素」スキームのフラグメントのみのサポートを要求し、XML MIMEエンティティプロセッサによる未登録のXPointerスキームのサポートを廃止します。 。したがって、URIは、単純な名前と「要素」スキームフラグメント識別子のみを使用する場合に最も相互運用できます。登録済みスキームは、汎用ツールで見つかるサポートの程度が大きく異なります。 XPointerスキームの作成者は、スキームを登録した場合にのみ、汎用ツールのサポートを期待できます。
Interoperability for all XML MIME entities is maximized by the use of UTF-8, without a BOM. When UTF-8 is _not_ used, a charset parameter and/or a BOM improve interoperability, particularly when XML-unaware consumers may be involved.
すべてのXML MIMEエンティティの相互運用性は、BOMなしでUTF-8を使用することにより最大化されます。 UTF-8が使用されない場合、特にXMLを認識しないコンシューマが関与する可能性がある場合、文字セットパラメータやBOMは相互運用性を向上させます。
In the very rare case where the substantive content of a non-UNICODE XML external parsed entity begins with the hexadecimal octet sequences 0xFE 0xFF, 0xFF 0xFE or 0xEF 0xBB 0xBF, including an XML text declaration will forestall the mistaken detection of a BOM.
非ユニコードXML外部解析エンティティの実質的なコンテンツが16進数のオクテットシーケンス0xFE 0xFF、0xFF 0xFEまたは0xEF 0xBB 0xBFで始まる非常にまれなケースでは、XMLテキスト宣言を含めて、BOMの誤検出を未然に防ぎます。
The use of UTF-32 for XML MIME entities puts interoperability at very high risk.
XML MIMEエンティティにUTF-32を使用すると、相互運用性のリスクが非常に高くなります。
Web-server configurations that supply default charset parameters risk misrepresenting XML MIME entities. Allowing users to control the value of charset parameters improves interoperability.
デフォルトの文字セットパラメータを提供するWebサーバー構成は、XML MIMEエンティティを誤って表すリスクがあります。ユーザーが文字セットパラメータの値を制御できるようにすることで、相互運用性が向上します。
Supplying a mistaken charset parameter is worse than supplying none at all. In particular, generic processors such as transcoders, when processing based on a mistaken charset parameter, if they do not fail altogether are likely to produce arbitrarily bogus results from which the original is not recoverable.
誤った文字セットパラメータを指定することは、何も指定しないよりも悪いことです。特に、トランスコーダなどの汎用プロセッサは、誤った文字セットパラメータに基づいて処理する場合、完全に失敗しないと、元の状態を回復できない任意の偽の結果を生成する可能性があります。
Consumers of XML MIME entities can maximize interoperability by
XML MIMEエンティティのコンシューマは、相互運用性を最大化できます。
1. Taking a BOM as authoritative if it is present in an XML MIME entity;
1. BOMがXML MIMEエンティティに存在する場合、BOMを信頼できるものと見なします。
2. In the absence of a BOM, taking a charset parameter as authoritative if it is present.
2. BOMがない場合、charsetパラメータが存在する場合はそれを信頼できるものとして受け取ります。
Assuming a default character encoding in the absence of a charset parameter harms interoperability.
charsetパラメータがない場合のデフォルトの文字エンコーディングを想定すると、相互運用性が損なわれます。
Although support for UTF-32 is not required by [XML] itself, and this specification deprecates its use, consumers that check for UTF-32 BOMs can thereby avoid mistakenly processing UTF-32 entities as (invalid) UTF-16 entities.
[XML]自体ではUTF-32のサポートは必要ありませんが、この仕様はその使用を廃止しますが、UTF-32 BOMをチェックするコンシューマーは、UTF-32エンティティを（無効な）UTF-16エンティティとして誤って処理することを回避できます。
There are numerous and significant differences between this specification and [RFC3023], which it obsoletes. This appendix summarizes the major differences only.
この仕様と廃止された[RFC3023]との間には、数多くの重要な違いがあります。この付録では、主な違いのみを要約しています。
XPointer ([XPointerFramework] and [XPointerElement]) has been added as fragment identifier syntax for all the XML media types, and the XPointer Registry ([XPtrReg]) mentioned
XPointer（[XPointerFramework]および[XPointerElement]）がすべてのXMLメディアタイプのフラグメント識別子構文として追加され、XPointerレジストリ（[XPtrReg]）が言及されました
[XMLBase] has been added as a mechanism for specifying base URIs
[XMLBase]は、ベースURIを指定するメカニズムとして追加されました
The language regarding character sets was updated to correspond to the W3C TAG finding Internet Media Type registration, consistency of use [TAGMIME]
文字セットに関する言語は、インターネットメディアタイプの登録、使用の一貫性を見つけるW3C TAGに対応するように更新されました[TAGMIME]
Priority is now given to a BOM if present
存在する場合、BOMが優先されます。
Many references are updated, and the existence of XML 1.1 and relevance of this specification to it acknowledged
多くの参照が更新され、XML 1.1の存在とこの仕様との関連性が認められました
A number of justifications and contextualizations that were appropriate when XML was new have been removed, including the whole of the original Appendix A
元の付録A全体を含め、XMLが新しいときに適切であった正当化とコンテキスト化の多くが削除されました
MURATA Makoto (FAMILY Given) and Alexey Melnikov made early and important contributions to the effort to revise [RFC3023].
村田誠（FAMILYギブン）とアレクセイメルニコフは、[RFC3023]の改訂に早期かつ重要な貢献をした。
This specification reflects the input of numerous participants to the ietf-xml-mime@imc.org, xml-mime@ietf.org, and apps-discuss@ietf.org mailing lists, though any errors are the responsibility of the authors. Special thanks to:
この仕様は、ietf-xml-mime @ imc.org、xml-mime @ ietf.org、apps-discuss @ ietf.orgメーリングリストへの多数の参加者の入力を反映していますが、エラーは作者の責任です。特別な感謝：
Mark Baker, James Clark, Dan Connolly, Martin Duerst, Ned Freed, Yaron Goland, Bjoern Hoehrmann, Rick Jelliffe, Murray S. Kucherawy, Larry Masinter, David Megginson, S. Moonesamy, Keith Moore, Chris Newman, Gavin Nicol, Julian Reschke, Marshall Rose, Jim Whitehead, Erik Wilde, and participants of the XML activity and the TAG at the W3C.
マークベイカー、ジェームズクラーク、ダンコノリー、マーティンデュエルスト、ネッドフリード、ヤロンゴランド、ビョルンホールマン、リックジェリフ、マレーS.クチェラウィ、ラリーマジンター、デビッドメギンソン、S。ムーネサミー、キースムーア、クリスニューマン、ギャビンニコル、ジュリアンレシュケ、マーシャルローズ、ジムホワイトヘッド、エリックワイルド、XMLアクティビティの参加者、W3CのTAG。
Jim Whitehead and Simon St. Laurent were editors of [RFC2376] and [RFC3023], respectively.
Jim WhiteheadとSimon St. Laurentはそれぞれ[RFC2376]と[RFC3023]の編集者でした。
Authors' Addresses
著者のアドレス
Henry S. Thompson University of Edinburgh
ヘンリーS.トンプソンエジンバラ大学
EMail: ht@inf.ed.ac.uk
URI: http://www.ltg.ed.ac.uk/~ht/
Chris Lilley World Wide Web Consortium 2004, Route des Lucioles - B.P. 93 06902 Sophia Antipolis Cedex France
Chris Lilley World Wide Web Consortium 2004、Route des Lucioles-B.P. 93 06902 Sophia Antipolis Cedex France
EMail: chris@w3.org
URI: http://www.w3.org/People/chris/