[要約] RFC 3023は、XMLデータのメディアタイプを定義するための仕様です。その目的は、XMLデータの正確な識別と処理を可能にすることです。
Network Working Group M. Murata
Request for Comments: 3023 IBM Tokyo Research Laboratory
Obsoletes: 2376 S. St.Laurent
Updates: 2048 simonstl.com
Category: Standards Track D. Kohn
Skymoon Ventures
January 2001
XML Media Types
XMLメディアタイプ
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains.
このドキュメントは、ネットワークの交換に使用するために、テキスト/XML、アプリケーション/XML、テキスト/XML-External-Parsed-Entity、Application/XML-External-Parsed-Parsed-entity、Application/XML-DTDの5つの新しいメディアタイプを標準化しています。拡張可能なマークアップ言語（XML）に関連するエンティティ。また、このドキュメントは、これらのメディアタイプがXML MIME（多目的インターネットメールエクステンション）エンティティを表す場合、これら5つのタイプ以外のメディアタイプを命名するためのコンベンション（接尾辞「XML 'を使用）を標準化しています。XML MIMEエンティティは現在、World Wide WebのHyperText Transfer Protocolを介して交換されており、リモートWebオーサリング用のWebDavプロトコルの不可欠な部分であり、多くのドメインで有用性があると予想されています。
Major differences from RFC 2376 are (1) the addition of text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of "utf-16le" and "utf-16be".
RFC 2376との主な違いは、（1）テキスト/XML-External-Parsed-Entity、Application/XML-External-Parsed-Entity、およびApplication/XML-DTDの追加です。また、RFC 2048登録プロセスを更新します）、および（3）「UTF-16LE」および「UTF-16BE」の議論。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. XML Media Types . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Text/xml Registration . . . . . . . . . . . . . . . . . . . 7
3.2 Application/xml Registration . . . . . . . . . . . . . . . . 9
3.3 Text/xml-external-parsed-entity Registration . . . . . . . . 11
3.4 Application/xml-external-parsed-entity Registration . . . . 12
3.5 Application/xml-dtd Registration . . . . . . . . . . . . . . 13
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. The Byte Order Mark (BOM) and Conversions to/from the UTF-16
Charset . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 15
6. The Base URI . . . . . . . . . . . . . . . . . . . . . . . . 15
7. A Naming Convention for XML-Based Media Types . . . . . . . 16
7.1 Referencing . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1 Text/xml with UTF-8 Charset . . . . . . . . . . . . . . . . 19
8.2 Text/xml with UTF-16 Charset . . . . . . . . . . . . . . . . 19
8.3 Text/xml with UTF-16BE Charset . . . . . . . . . . . . . . . 19
8.4 Text/xml with ISO-2022-KR Charset . . . . . . . . . . . . . 20
8.5 Text/xml with Omitted Charset . . . . . . . . . . . . . . . 20
8.6 Application/xml with UTF-16 Charset . . . . . . . . . . . . 20
8.7 Application/xml with UTF-16BE Charset . . . . . . . . . . . 21
8.8 Application/xml with ISO-2022-KR Charset . . . . . . . . . . 21
8.9 Application/xml with Omitted Charset and UTF-16 XML MIME
Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.10 Application/xml with Omitted Charset and UTF-8 Entity . . . 22
8.11 Application/xml with Omitted Charset and Internal Encoding
Declaration . . . . . . . . . . . . . . . . . . . . . . . . 22
8.12 Text/xml-external-parsed-entity with UTF-8 Charset . . . . . 22
8.13 Application/xml-external-parsed-entity with UTF-16 Charset . 23
8.14 Application/xml-external-parsed-entity with UTF-16BE Charset 23
8.15 Application/xml-dtd . . . . . . . . . . . . . . . . . . . . 23
8.16 Application/mathml+xml . . . . . . . . . . . . . . . . . . . 24
8.17 Application/xslt+xml . . . . . . . . . . . . . . . . . . . . 24
8.18 Application/rdf+xml . . . . . . . . . . . . . . . . . . . . 24
8.19 Image/svg+xml . . . . . . . . . . . . . . . . . . . . . . . 24
8.20 INCONSISTENT EXAMPLE: Text/xml with UTF-8 Charset . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . 25
References . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
A. Why Use the '+xml' Suffix for XML-Based MIME Types? . . . . 32
A.1 Why not just use text/xml or application/xml and let the XML
processor dispatch to the correct application based on the
referenced DTD? . . . . . . . . . . . . . . . . . . . . . . 32
A.2 Why not create a new subtree (e.g., image/xml.svg) to
represent XML MIME types? . . . . . . . . . . . . . . . . . 32
A.3 Why not create a new top-level MIME type for XML-based media
types? . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.4 Why not just have the MIME processor 'sniff' the content to
determine whether it is XML? . . . . . . . . . . . . . . . . 33
A.5 Why not use a MIME parameter to specify that a media type
uses XML syntax? . . . . . . . . . . . . . . . . . . . . . . 33
A.6 How about labeling with parameters in the other direction
(e.g., application/xml; Content-Feature=iotp)? . . . . . . . 34
A.7 How about a new superclass MIME parameter that is defined to
apply to all MIME types (e.g., Content-Type:
application/iotp; $superclass=xml)? . . . . . . . . . . . . 34
A.8 What about adding a new parameter to the Content-Disposition
header or creating a new Content-Structure header to
indicate XML syntax? . . . . . . . . . . . . . . . . . . . . 35
A.9 How about a new Alternative-Content-Type header? . . . . . . 35
A.10 How about using a conneg tag instead (e.g., accept-features:
(syntax=xml))? . . . . . . . . . . . . . . . . . . . . . . . 35
A.11 How about a third-level content-type, such as text/xml/rdf? 35
A.12 Why use the plus ('+') character for the suffix '+xml'? . . 36
A.13 What is the semantic difference between application/foo and
application/foo+xml? . . . . . . . . . . . . . . . . . . . . 36
A.14 What happens when an even better markup language (e.g.,
EBML) is defined, or a new category of data? . . . . . . . . 36
A.15 Why must I use the '+xml' suffix for my new XML-based media
type? . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
B. Changes from RFC 2376 . . . . . . . . . . . . . . . . . . . 37
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . 39
The World Wide Web Consortium has issued Extensible Markup Language (XML) 1.0 (Second Edition)[XML]. To enable the exchange of XML network entities, this document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd -- as well as a naming convention for identifying XML-based MIME media types.
World Wide Webコンソーシアムは、拡張可能なマークアップ言語（XML）1.0（第2版）[XML]を発行しました。XMLネットワークエンティティの交換を有効にするために、このドキュメントは、テキスト/XML、アプリケーション/XML、テキスト/XML-External-Parsed-Entity、Application/XML-External-Parsed-Parsed-Entity、Application/XMLの5つの新しいメディアタイプを標準化しています。-DTD- XMLベースのMIMEメディアタイプを特定するための命名規則。
XML entities are currently exchanged on the World Wide Web, and XML is also used for property values and parameter marshalling by the WebDAV[RFC2518] protocol for remote web authoring. Thus, there is a need for a media type to properly label the exchange of XML network entities.
XMLエンティティは現在、World Wide Webで交換されており、XMLはリモートWebオーサリング用のWebDav [RFC2518]プロトコルによるプロパティ値とパラメーターマーシャリングにも使用されています。したがって、XMLネットワークエンティティの交換に適切にラベルを付けるためにメディアタイプが必要です。
Although XML is a subset of the Standard Generalized Markup Language (SGML) ISO 8879[SGML], which has been assigned the media types text/sgml and application/sgml, there are several reasons why use of text/sgml or application/sgml to label XML is inappropriate. First, there exist many applications that can process XML, but that cannot process SGML, due to SGML's larger feature set. Second, SGML applications cannot always process XML entities, because XML uses features of recent technical corrigenda to SGML. Third, the definition of text/sgml and application/sgml in [RFC1874] includes parameters for SGML bit combination transformation format (SGML-bctf), and SGML boot attribute (SGML-boot). Since XML does not use these parameters, it would be ambiguous if such parameters were given for an XML MIME entity. For these reasons, the best approach for labeling XML network entities is to provide new media types for XML.
XMLは、メディアタイプテキスト/SGMLおよびアプリケーション/SGMLが割り当てられている標準一般化マークアップ言語（SGML）ISO 8879 [SGML]のサブセットですが、テキスト/SGMLまたはアプリケーション/SGMLを使用する理由がいくつかあります。ラベルXMLは不適切です。まず、XMLを処理できる多くのアプリケーションが存在しますが、SGMLのより大きな機能セットのため、SGMLを処理することはできません。第二に、XMLは最近の技術Corrigendaの機能をSGMLに使用するため、SGMLアプリケーションは常にXMLエンティティを処理することはできません。第三に、[RFC1874]のテキスト/SGMLおよびアプリケーション/SGMLの定義には、SGMLビット併用変換形式（SGML-BCTF）およびSGMLブート属性（SGML-BOOT）のパラメーターが含まれます。XMLはこれらのパラメーターを使用していないため、XML MIMEエンティティにそのようなパラメーターが与えられた場合、曖昧になります。これらの理由から、XMLネットワークエンティティにラベルを付けるための最良のアプローチは、XMLに新しいメディアタイプを提供することです。
Since XML is an integral part of the WebDAV Distributed Authoring Protocol, and since World Wide Web Consortium Recommendations have conventionally been assigned IETF tree media types, and since similar media types (HTML, SGML) have been assigned IETF tree media types, the XML media types also belong in the IETF media types tree.
XMLはWebDAV分散オーサリングプロトコルの不可欠な部分であり、World Wide Webコンソーシアムの推奨事項は従来、IETFツリーメディアタイプが割り当てられているため、同様のメディアタイプ（HTML、SGML）がIETFツリーメディアタイプに割り当てられているため、XMLメディアはXMLメディアに割り当てられています。タイプは、IETFメディアタイプツリーにも属します。
Similarly, XML will be used as a foundation for other media types, including types in every branch of the IETF media types tree. To facilitate the processing of such types, media types based on XML, but that are not identified using text/xml or application/xml, SHOULD be named using a suffix of '+xml' as described in Section 7. This will allow XML-based tools -- browsers, editors, search engines, and other processors -- to work with all XML-based media types.
同様に、XMLは、IETFメディアタイプツリーのすべてのブランチのタイプを含む、他のメディアタイプの基礎として使用されます。このようなタイプの処理を容易にするには、XMLに基づいてメディアタイプがテキスト/XMLまたはApplication/XMLを使用して識別されないことは、セクション7で説明されている「XML」の接尾辞を使用して名前を付けておく必要があります。ツール - ブラウザー、エディター、検索エンジン、その他のプロセッサなど、すべてのXMLベースのメディアタイプと連携します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
As defined in [RFC2781], the three charsets "utf-16", "utf-16le", and "utf-16be" are used to label UTF-16 text. In this document, "the UTF-16 family" refers to those three charsets. By contrast, the phrases "utf-16" or UTF-16 in this document refer specifically to the single charset "utf-16".
[rfc2781]で定義されているように、3つのcharセット「UTF-16」、「UTF-16LE」、および「UTF-16BE」を使用してUTF-16テキストにラベルを付けます。このドキュメントでは、「UTF-16ファミリー」とは、これらの3つの充電器を指します。対照的に、このドキュメントの「UTF-16」またはUTF-16のフレーズは、特に単一のcharset「UTF-16」を指します。
As sometimes happens between two communities, both MIME and XML have defined the term entity, with different meanings. Section 2.4 of [RFC2045] says:
2つのコミュニティ間で時々起こるように、MIMEとXMLの両方が異なる意味でエンティティという用語を定義しています。[RFC2045]のセクション2.4は次のように述べています。
"The term 'entity' refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity."
「「エンティティ」という用語とは、MIME定義のヘッダーフィールドと、メッセージまたはマルチパートエンティティの本体内の部分の1つの内容を特に指します。」
Section 4 of [XML] says:
[XML]のセクション4は次のように述べています。
"An XML document may consist of one or many storage units" called entities that "have content" and are normally "identified by name".
「XMLドキュメントは、「コンテンツ」を持ち、通常「名前で識別される」エンティティと呼ばれるエンティティと呼ばれる1つまたは多数のストレージユニットで構成されている場合があります。
In this document, "XML MIME entity" is defined as the latter (an XML entity) encapsulated in the former (a MIME entity).
このドキュメントでは、「XML MIMEエンティティ」は、前者（MIMEエンティティ）にカプセル化された後者（XMLエンティティ）として定義されています。
This document standardizes five media types related to XML MIME entities: text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd. Registration information for these media types is described in the sections below.
このドキュメントは、XML MIMEエンティティに関連する5つのメディアタイプを標準化します：Text/XML、Application/XML、Text/XML-External-Parsed-Entity、Application/XML-External-Parsed-Parsed-Entity、およびApplication/XML-DTD。これらのメディアタイプの登録情報については、以下のセクションで説明します。
Within the XML specification, XML MIME entities can be classified into four types. In the XML terminology, they are called "document entities", "external DTD subsets", "external parsed entities", and "external parameter entities". The media types text/xml and application/xml MAY be used for "document entities", while text/xml-external-parsed-entity or application/xml-external-parsed-entity SHOULD be used for "external parsed entities". The media type application/xml-dtd SHOULD be used for "external DTD subsets" or "external parameter entities". application/xml and text/xml MUST NOT be used for "external parameter entities" or "external DTD subsets", and MUST NOT be used for "external parsed entities" unless they are also well-formed "document entities" and are referenced as such. Note that [RFC2376] (which this document obsoletes) allowed such usage, although in practice it is likely to have been rare.
XML仕様内では、XML MIMEエンティティを4つのタイプに分類できます。XML用語では、「ドキュメントエンティティ」、「外部DTDサブセット」、「外部解析エンティティ」、および「外部パラメーターエンティティ」と呼ばれます。メディアタイプのテキスト/XMLおよびアプリケーション/XMLは「ドキュメントエンティティ」に使用できますが、テキスト/XML-External-Parsed-Parsed-entityまたはApplication/XML-External-Parsed-entityは「外部解析エンティティ」に使用する必要があります。メディアタイプアプリケーション/XML-DTDは、「外部DTDサブセット」または「外部パラメーターエンティティ」に使用する必要があります。Application/XMLおよびTEXT/XMLは、「外部パラメーターエンティティ」または「外部DTDサブセット」に使用してはなりません。また、「外部解析エンティティ」にも使用されてはなりません。そのような。[RFC2376]（この文書は廃止された）がそのような使用を許可したことに注意してくださいが、実際にはまれである可能性が高いです。
Neither external DTD subsets nor external parameter entities parse as XML documents, and while some XML document entities may be used as external parsed entities and vice versa, there are many cases where the two are not interchangeable. XML also has unparsed entities, internal parsed entities, and internal parameter entities, but they are not XML MIME entities.
外部DTDサブセットも外部パラメーターエンティティもXMLドキュメントとして解析せず、一部のXMLドキュメントエンティティは外部解析エンティティとして使用され、その逆も同様ですが、2つが交換できない場合がたくさんあります。XMLには、未装飾のエンティティ、内部解析エンティティ、および内部パラメーターエンティティもありますが、XML MIMEエンティティではありません。
If an XML document -- that is, the unprocessed, source XML document -- is readable by casual users, text/xml is preferable to application/xml. MIME user agents (and web user agents) that do not have explicit support for text/xml will treat it as text/plain, for example, by displaying the XML MIME entity as plain text. Application/xml is preferable when the XML MIME entity is unreadable by casual users. Similarly, text/xml-external-parsed-entity is preferable when an external parsed entity is readable by casual users, but application/xml-external-parsed-entity is preferable when a plain text display is inappropriate.
XMLドキュメント、つまり、処理されていないソースXMLドキュメントがカジュアルユーザーが読み取ることができる場合、Text/XMLはApplication/XMLよりも望ましいです。テキスト/XMLの明示的なサポートがないMIMEユーザーエージェント（およびWebユーザーエージェント）は、たとえばXML MIMEエンティティをプレーンテキストとして表示することにより、テキスト/プレーンとして扱います。XML MIMEエンティティがカジュアルユーザーが読み取れない場合、アプリケーション/XMLが望ましいです。同様に、外部解析エンティティがカジュアルなユーザーが読み取ることができる場合、テキスト/XML-External-Parsed-entityは好ましいが、アプリケーション/XML-External-Parsed-Entityは、プレーンテキストディスプレイが不適切な場合に好ましい。
NOTE: Users are in general not used to text containing tags such as <price>, and often find such tags quite disorienting or annoying. If one is not sure, the conservative principle would suggest using application/* instead of text/* so as not to put information in front of users that they will quite likely not understand.
注：ユーザーは一般に、<Price>などのタグを含むテキストに使用されず、多くの場合、そのようなタグは非常に見当識障害や迷惑です。確信が持てない場合、保守的な原則は、テキスト/*の代わりに/*を使用することを提案します。
The top-level media type "text" has some restrictions on MIME entities and they are described in [RFC2045] and [RFC2046]. In particular, the UTF-16 family, UCS-4, and UTF-32 are not allowed (except over HTTP[RFC2616], which uses a MIME-like mechanism). Thus, if an XML document or external parsed entity is encoded in such character encoding schemes, it cannot be labeled as text/xml or text/xml-external-parsed-entity (except for HTTP).
トップレベルのメディアタイプ「テキスト」には、MIMEエンティティにいくつかの制限があり、[RFC2045]および[RFC2046]で説明されています。特に、UTF-16ファミリー、UCS-4、およびUTF-32は許可されていません（MIMEのようなメカニズムを使用するHTTP [RFC2616]を除く）。したがって、XMLドキュメントまたは外部解析されたエンティティがこのような文字エンコードスキームでエンコードされている場合、Text/XMLまたはText/XML-External-Parsed-Entity（HTTPを除く）としてラベル付けすることはできません。
Text/xml and application/xml behave differently when the charset parameter is not explicitly specified. If the default charset (i.e., US-ASCII) for text/xml is inconvenient for some reason (e.g., bad web servers), application/xml provides an alternative (see "Optional parameters" of application/xml registration in Section 3.2). The same rules apply to the distinction between text/xml-external-parsed-entity and application/xml-external-parsed-entity.
Text/XMLおよびApplication/XMLは、CharSetパラメーターが明示的に指定されていない場合、異なる動作を異なります。テキスト/XMLのデフォルトのcharset（つまり、us-ascii）が何らかの理由で不便である場合（たとえば、悪いWebサーバー）、アプリケーション/XMLは代替を提供します（セクション3.2のアプリケーション/XML登録の「オプションパラメーター」を参照）。同じルールは、テキスト/XML-External-Parsed-EntityとApplication/XML-External-Parsed-Persed-Entityの区別に適用されます。
XML provides a general framework for defining sequences of structured data. In some cases, it may be desirable to define new media types that use XML but define a specific application of XML, perhaps due to domain-specific security considerations or runtime information. Furthermore, such media types may allow UTF-8 or UTF-16 only and prohibit other charsets. This document does not prohibit such media types and in fact expects them to proliferate. However, developers of such media types are STRONGLY RECOMMENDED to use this document as a basis for their registration. In particular, the charset parameter SHOULD be used in the same manner, as described in Section 7.1, in order to enhance interoperability.
XMLは、構造化されたデータのシーケンスを定義するための一般的なフレームワークを提供します。場合によっては、XMLを使用するが、おそらくドメイン固有のセキュリティに関する考慮事項またはランタイム情報のために、XMLの特定のアプリケーションを定義する新しいメディアタイプを定義することが望ましい場合があります。さらに、このようなメディアタイプは、UTF-8またはUTF-16のみを許可し、他の充電器を禁止する場合があります。このドキュメントは、そのようなメディアタイプを禁止するものではなく、実際にそれらが増殖することを期待しています。ただし、このようなメディアタイプの開発者は、このドキュメントを登録の基礎として使用することを強くお勧めします。特に、相互運用性を高めるために、セクション7.1で説明したように、charsetパラメーターを同じ方法で使用する必要があります。
An XML document labeled as text/xml or application/xml might contain namespace declarations, stylesheet-linking processing instructions (PIs), schema information, or other declarations that might be used to suggest how the document is to be processed. For example, a document might have the XHTML namespace and a reference to a CSS stylesheet. Such a document might be handled by applications that would use this information to dispatch the document for appropriate processing.
テキスト/XMLまたはアプリケーション/XMLとラベル付けされたXMLドキュメントには、名前空間宣言、スタイルシートリンク処理手順（PI）、スキーマ情報、またはドキュメントの処理方法を示唆するために使用される可能性のあるその他の宣言が含まれる場合があります。たとえば、ドキュメントにはXHTMLネームスペースとCSSスタイルシートへの参照がある場合があります。このようなドキュメントは、この情報を使用して適切な処理のためにドキュメントを派遣するアプリケーションによって処理される場合があります。
MIME media type name: text
MIMEメディアタイプ名：テキスト
MIME subtype name: xml
MIMEサブタイプ名：XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: charset
オプションのパラメーター：charset
Although listed as an optional parameter, the use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the character encoding of the XML MIME entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP. "utf-8" [RFC2279] is the recommended value, representing the UTF-8 charset. UTF-8 is supported by all conforming processors of [XML].
オプションのパラメーターとしてリストされていますが、この情報はXMLプロセッサがXML MIMEエンティティのキャラクターエンコードを信頼できることを決定するために使用できるため、charsetパラメーターの使用を強くお勧めします。charsetパラメーターは、httpでのcharsetベースのコンテンツネゴシエーションなど、プロトコル固有の操作を提供するためにも使用できます。「UTF-8」[RFC2279]が推奨される値であり、UTF-8チャーセットを表します。UTF-8は、[XML]のすべての適合プロセッサによってサポートされています。
If the XML MIME entity is transmitted via HTTP, which uses a MIME-like mechanism that is exempt from the restrictions on the text top-level type (see section 19.4.1 of [RFC2616]), "utf-16" [RFC2781]) is also recommended. UTF-16 is supported by all conforming processors of [XML]. Since the handling of CR, LF and NUL for text types in most MIME applications would cause undesired transformations of individual octets in UTF-16 multi-octet characters, gateways from HTTP to these MIME applications MUST transform the XML MIME entity from text/xml; charset="utf-16" to application/xml; charset="utf-16".
XML MIMEエンティティがHTTPを介して送信されます。HTTPは、テキストトップレベルタイプの制限から免除されるMIMEのようなメカニズムを使用している場合（[RFC2616]セクション19.4.1]、 "UTF-16" [RFC2781]を参照してください。）もお勧めします。UTF-16は、[XML]のすべての適合プロセッサによってサポートされています。ほとんどのMIMEアプリケーションでのテキストタイプのCR、LF、およびNULの処理は、UTF-16マルチオクテット文字の個々のオクテットの望ましくない変換を引き起こすため、HTTPからこれらのMIMEアプリケーションへのゲートウェイは、XML MIMEエンティティをテキスト/XMLから変換する必要があります。charset = "utf-16" to application/xml;charset = "utf-16"。
Conformant with [RFC2046], if a text/xml entity is received with the charset parameter omitted, MIME processors and XML processors MUST use the default charset value of "us-ascii"[ASCII]. In cases where the XML MIME entity is transmitted via HTTP, the default charset value is still "us-ascii". (Note: There is an inconsistency between this specification and HTTP/1.1, which uses ISO-8859-1[ISO8859] as the default for a historical reason. Since XML is a new format, a new default should be chosen for better I18N. US-ASCII was chosen, since it is the intersection of UTF-8 and ISO-8859-1 and since it is already used by MIME.)
[RFC2046]に適合している場合、Charsetパラメーターが省略されたテキスト/XMLエンティティが受信された場合、MIMEプロセッサとXMLプロセッサは、「US-ASCII」[ASCII]のデフォルトのcharSet値を使用する必要があります。XML MIMEエンティティがHTTPを介して送信されている場合、デフォルトのチャーセット値は依然として「US-ASCII」です。（注：この仕様とHTTP/1.1の間には矛盾があります。これは、歴史的な理由でISO-8859-1 [ISO8859]をデフォルトとして使用します。XMLは新しい形式であるため、新しいデフォルトをより良いI18Nのために選択する必要があります。UTF-8とISO-8859-1の交差点であり、すでにMIMEで使用されているため、US-ASCIIが選択されました。）
There are several reasons that the charset parameter is authoritative. First, some MIME processing engines do transcoding of MIME bodies of the top-level media type "text" without reference to any of the internal content. Thus, it is possible that some agent might change text/xml; charset="iso-2022-jp" to text/xml; charset="utf-8" without modifying the encoding declaration of an XML document. Second, text/xml must be compatible with text/plain, since MIME agents that do not understand text/xml will fallback to handling it as text/plain. If the charset parameter for text/xml were not authoritative, such fallback would cause data corruption. Third, recent web servers have been improved so that users can specify the charset parameter. Fourth, [RFC2130] specifies that the recommended specification scheme is the "charset" parameter.
Charsetパラメーターが信頼できる理由はいくつかあります。まず、一部のMIME処理エンジンは、内部コンテンツを参照することなく、トップレベルのメディアタイプ「テキスト」のMIMEボディをトランスコーディングします。したがって、一部のエージェントがテキスト/XMLを変更する可能性があります。charset = "iso-2022-jp" to text/xml;charset = "utf-8" XMLドキュメントのエンコーディング宣言を変更せずに。第二に、テキスト/XMLがテキスト/XMLを理解していないMIMEエージェントは、テキスト/プレーンとして処理することにフォールバックするため、テキスト/XMLはテキスト/プレーンと互換性がなければなりません。テキスト/XMLのcharsetパラメーターが権威がなかった場合、そのようなフォールバックはデータの破損を引き起こします。第三に、ユーザーがcharsetパラメーターを指定できるように、最近のWebサーバーが改善されました。第4に、[RFC2130]は、推奨される仕様スキームが「charset」パラメーターであることを指定します。
Since the charset parameter is authoritative, the charset is not always declared within an XML encoding declaration. Thus, special care is needed when the recipient strips the MIME header and provides persistent storage of the received XML MIME entity (e.g., in a file system). Unless the charset is UTF-8 or UTF-16, the recipient SHOULD also persistently store information about the charset, perhaps by embedding a correct XML encoding declaration within the XML MIME entity.
charsetパラメーターは権威あるため、charsetはXMLエンコーディング宣言内で常に宣言されるとは限りません。したがって、受信者がMIMEヘッダーをストリップし、受信したXML MIMEエンティティ（ファイルシステムで）の永続的なストレージを提供する場合、特別な注意が必要です。charsetがUTF-8またはUTF-16でない限り、受信者は、おそらくXML MIMEエンティティ内に正しいXMLエンコード宣言を埋め込むことにより、チャーセットに関する情報を永続的に保存する必要があります。
Encoding considerations: This media type MAY be encoded as appropriate for the charset and the capabilities of the underlying MIME transport. For 7-bit transports, data in UTF-8 MUST be encoded in quoted-printable or base64. For 8-bit clean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP[RFC0977]), UTF-8 does not need to be encoded. Over HTTP[RFC2616], no content-transfer-encoding is necessary and UTF-16 may also be used.
考慮事項のエンコーディング：このメディアタイプは、基礎となるMIMEトランスポートの焦点と機能に適しているようにエンコードされる場合があります。7ビットトランスポートの場合、UTF-8のデータは、引用プリントまたはBase64でエンコードする必要があります。8ビットのクリーントランスポート（例：8bitmime [RFC1652] ESMTPまたはNNTP [RFC0977]）の場合、UTF-8をエンコードする必要はありません。HTTP [RFC2616]では、コンテンツ転移エンコードは必要ありません。UTF-16も使用できます。
Security considerations: See Section 10.
セキュリティ上の考慮事項：セクション10を参照してください。
Interoperability considerations: XML has proven to be interoperable across WebDAV clients and servers, and for import and export from multiple XML authoring tools. For maximum interoperability, validating processors are recommended. Although non-validating processors may be more efficient, they are not required to handle all features of XML. For further information, see sub-section 2.9 "Standalone Document Declaration" and section 5 "Conformance" of [XML].
相互運用性の考慮事項：XMLは、WebDAVクライアントとサーバー全体で相互運用可能であることが証明されており、複数のXMLオーサリングツールからのインポートおよびエクスポートのために。相互運用性を最大限にするには、プロセッサの検証をお勧めします。非検証プロセッサはより効率的かもしれませんが、XMLのすべての機能を処理する必要はありません。詳細については、[XML]のサブセクション2.9「スタンドアロン文書宣言」とセクション5「適合」を参照してください。
Published specification: Extensible Markup Language (XML) 1.0 (Second Edition)[XML].
公開された仕様：拡張可能なマークアップ言語（XML）1.0（第2版）[XML]。
Applications which use this media type: XML is device-, platform-, and vendor-neutral and is supported by a wide range of Web user agents, WebDAV[RFC2518] clients and servers, as well as XML authoring tools.
このメディアタイプを使用するアプリケーション：XMLはデバイス、プラットフォーム、およびベンダー中立であり、幅広いWebユーザーエージェント、WebDav [RFC2518]クライアント、サーバー、およびXMLオーサリングツールによってサポートされています。
Additional information:
追加情報：
Magic number(s): None.
マジックナンバー：なし。
Although no byte sequences can be counted on to always be present, XML MIME entities in ASCII-compatible charsets (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D 00 6C or FF FE 3C 00 3F 00 78 00 6D 00 6C 00 (the Byte Order Mark (BOM) followed by "<?xml"). For more information, see Appendix F of [XML].
バイトシーケンスは常に存在することはありませんが、ASCII互換充電（UTF-8を含む）のXML MIMEエンティティは、多くの場合16進3C 3F 78 6D 6C（ "<？xml"）から始まり、UTF-16のエンティティから始まります。多くの場合、16進数Ff 00 3c 00 3f 00 78 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ファイルタイプコード：「テキスト」
Person and email address for further information:
詳細については、個人とメールアドレス：
MURATA Makoto (FAMILY Given) <mmurata@trl.ibm.co.jp>
Simon St.Laurent <simonstl@simonstl.com>
Daniel Kohn <dan@dankohn.com>
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The XML specification is a work product of the World Wide Web Consortium's XML Working Group, and was edited by:
著者/変更コントローラー：XML仕様は、World Wide Web ConsortiumのXMLワーキンググループの作業製品であり、以下によって編集されました。
Tim Bray <tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
Eve Maler <eve.maler@east.sun.com>
The W3C, and the W3C XML Core Working Group, have change control over the XML specification.
W3CとW3C XMLコアワーキンググループは、XML仕様を制御することを変更します。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: xml
MIMEサブタイプ名：XML
Mandatory parameters: none Optional parameters: charset
必須パラメーター：なしオプションのパラメーター：charset
Although listed as an optional parameter, the use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the charset of the XML MIME entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP.
オプションのパラメーターとしてリストされていますが、この情報はXML MIMEエンティティのcharsetを信頼できるように決定するためにこの情報を使用できるため、charsetパラメーターの使用を強くお勧めします。charsetパラメーターは、httpでのcharsetベースのコンテンツネゴシエーションなど、プロトコル固有の操作を提供するためにも使用できます。
"utf-8" [RFC2279] and "utf-16" [RFC2781] are the recommended values, representing the UTF-8 and UTF-16 charsets, respectively. These charsets are preferred since they are supported by all conforming processors of [XML].
「UTF-8」[RFC2279]および「UTF-16」[RFC2781]は、それぞれUTF-8およびUTF-16 charセットを表す推奨値です。これらの充電器は、[XML]のすべての適合プロセッサによってサポートされているため、好まれます。
If an application/xml entity is received where the charset parameter is omitted, no information is being provided about the charset by the MIME Content-Type header. Conforming XML processors MUST follow the requirements in section 4.3.3 of [XML] that directly address this contingency. However, MIME processors that are not XML processors SHOULD NOT assume a default charset if the charset parameter is omitted from an application/xml entity.
charsetパラメーターが省略されているアプリケーション/XMLエンティティが受信された場合、MIMEコンテンツタイプのヘッダーによるcharSetに関する情報は提供されていません。XMLプロセッサの適合は、この不測事態に直接対処する[XML]のセクション4.3.3の要件に従う必要があります。ただし、XMLプロセッサではないMIMEプロセッサは、アプリケーション/XMLエンティティからCharSetパラメーターが省略されている場合、デフォルトのcharsetを想定してはなりません。
There are several reasons that the charset parameter is authoritative. First, recent web servers have been improved so that users can specify the charset parameter. Second, [RFC2130] specifies that the recommended specification scheme is the "charset" parameter.
Charsetパラメーターが信頼できる理由はいくつかあります。まず、ユーザーがcharsetパラメーターを指定できるように、最近のWebサーバーが改善されました。第二に、[RFC2130]は、推奨される仕様スキームが「charset」パラメーターであることを指定します。
On the other hand, it has been argued that the charset parameter should be omitted and the mechanism described in Appendix F of [XML] (which is non-normative) should be solely relied on. This approach would allow users to avoid configuration of the charset parameter; an XML document stored in a file is likely to contain a correct encoding declaration or BOM (if necessary), since the operating system does not typically provide charset information for files. If users would like to rely on the encoding declaration or BOM and to hide charset information from protocols, they may determine not to use the parameter.
一方、charsetパラメーターは省略する必要があり、[xml]（非規範的）の付録Fに記載されているメカニズムは、単に信頼されるべきであると主張されています。このアプローチにより、ユーザーはcharsetパラメーターの構成を回避できます。ファイルに保存されているXMLドキュメントには、オペレーティングシステムが通常ファイルのcharSet情報を提供しないため、正しいエンコード宣言またはBOM（必要に応じてBOMが含まれている可能性があります。ユーザーがエンコーディング宣言またはBOMに依存し、プロトコルからcharset情報を非表示にしたい場合、パラメーターを使用しないと判断する場合があります。
Since the charset parameter is authoritative, the charset is not always declared within an XML encoding declaration. Thus, special care is needed when the recipient strips the MIME header and provides persistent storage of the received XML MIME entity (e.g., in a file system). Unless the charset is UTF-8 or UTF-16, the recipient SHOULD also persistently store information about the charset, perhaps by embedding a correct XML encoding declaration within the XML MIME entity.
charsetパラメーターは権威あるため、charsetはXMLエンコーディング宣言内で常に宣言されるとは限りません。したがって、受信者がMIMEヘッダーをストリップし、受信したXML MIMEエンティティ（ファイルシステムで）の永続的なストレージを提供する場合、特別な注意が必要です。charsetがUTF-8またはUTF-16でない限り、受信者は、おそらくXML MIMEエンティティ内に正しいXMLエンコード宣言を埋め込むことにより、チャーセットに関する情報を永続的に保存する必要があります。
Encoding considerations: This media type MAY be encoded as appropriate for the charset and the capabilities of the underlying MIME transport. For 7-bit transports, data in either UTF-8 or UTF-16 MUST be encoded in quoted-printable or base64. For 8-bit clean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP[RFC0977]), UTF-8 is not encoded, but the UTF-16 family MUST be encoded in base64. For binary clean transports (e.g., HTTP[RFC2616]), no content-transfer-encoding is necessary.
考慮事項のエンコーディング：このメディアタイプは、基礎となるMIMEトランスポートの焦点と機能に適しているようにエンコードされる場合があります。7ビットトランスポートの場合、UTF-8またはUTF-16のいずれかのデータを引用プリント可能またはBase64でエンコードする必要があります。8ビットのクリーントランスポート（例：8bitmime [RFC1652] ESMTPまたはNNTP [RFC0977]）の場合、UTF-8はエンコードされていませんが、UTF-16ファミリーはbase64でエンコードする必要があります。バイナリクリーントランスポート（例：HTTP [RFC2616]）の場合、コンテンツ転送エンコードは必要ありません。
Security considerations: See Section 10.
セキュリティ上の考慮事項：セクション10を参照してください。
Interoperability considerations: Same as Section 3.1.
相互運用性の考慮事項：セクション3.1と同じ。
Published specification: Same as Section 3.1.
公開された仕様：セクション3.1と同じ。
Applications which use this media type: Same as Section 3.1.
このメディアタイプを使用するアプリケーション：セクション3.1と同じ。
Additional information: Same as Section 3.1.
追加情報：セクション3.1と同じ。
Person and email address for further information: Same as Section 3.1.
詳細については、個人および電子メールアドレス：セクション3.1と同じ。
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Same as Section 3.1.
著者/変更コントローラー：セクション3.1と同じ。
MIME media type name: text
MIMEメディアタイプ名：テキスト
MIME subtype name: xml-external-parsed-entity
MIMEサブタイプ名：XML-External-Parsed-Entity
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: charset
オプションのパラメーター：charset
The charset parameter of text/xml-external-parsed-entity is handled the same as that of text/xml as described in Section 3.1.
テキスト/XML-External-Parsed-EntityのCharSetパラメーターは、セクション3.1で説明されているように、テキスト/XMLのパラメーターと同じように処理されます。
Encoding considerations: Same as Section 3.1.
考慮事項のエンコード：セクション3.1と同じ。
Security considerations: See Section 10.
セキュリティ上の考慮事項：セクション10を参照してください。
Interoperability considerations: XML external parsed entities are as interoperable as XML documents, though they have a less tightly constrained structure and therefore need to be referenced by XML documents for proper handling by XML processors. Similarly, XML documents cannot be reliably used as external parsed entities because external parsed entities are prohibited from having standalone document declarations or DTDs. Identifying XML external parsed entities with their own content type should enhance interoperability of both XML documents and XML external parsed entities.
相互運用性の考慮事項：XML外部解析されたエンティティはXMLドキュメントと同じくらい相互運用可能ですが、XMLプロセッサによって適切に処理するためにXMLドキュメントでは密着していない構造があります。同様に、外部解析されたエンティティにはスタンドアロンのドキュメント宣言またはDTDがないことが禁止されているため、XMLドキュメントを外部解析エンティティとして確実に使用することはできません。独自のコンテンツタイプを持つXML外部解析エンティティを識別すると、XMLドキュメントとXML外部解析エンティティの両方の相互運用性が向上するはずです。
Published specification: Same as Section 3.1.
公開された仕様：セクション3.1と同じ。
Applications which use this media type: Same as Section 3.1.
このメディアタイプを使用するアプリケーション：セクション3.1と同じ。
Additional information:
追加情報：
Magic number(s): Same as Section 3.1.
マジック番号：セクション3.1と同じ。
File extension(s): .xml or .ent
ファイル拡張子：.xmlまたは.ent
Macintosh File Type Code(s): "TEXT"
Macintoshファイルタイプコード：「テキスト」
Person and email address for further information: Same as Section 3.1.
詳細については、個人および電子メールアドレス：セクション3.1と同じ。
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Same as Section 3.1.
著者/変更コントローラー：セクション3.1と同じ。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: xml-external-parsed-entity
MIMEサブタイプ名：XML-External-Parsed-Entity
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: charset
オプションのパラメーター：charset
The charset parameter of application/xml-external-parsed-entity is handled the same as that of application/xml as described in Section 3.2.
アプリケーション/XML-External-Parsed-EntityのCharsetパラメーターは、セクション3.2で説明されているように、アプリケーション/XMLのパラメーターと同じように処理されます。
Encoding considerations: Same as Section 3.2.
考慮事項のエンコード：セクション3.2と同じ。
Security considerations: See Section 10.
セキュリティ上の考慮事項：セクション10を参照してください。
Interoperability considerations: Same as those for text/xml-external-parsed-entity as described in Section 3.3.
相互運用性の考慮事項：セクション3.3で説明されているように、テキスト/XML-External-Parsed-Entityと同じ。
Published specification: Same as text/xml as described in Section 3.1.
公開された仕様：セクション3.1で説明されているように、テキスト/XMLと同じ。
Applications which use this media type: Same as Section 3.1.
このメディアタイプを使用するアプリケーション：セクション3.1と同じ。
Additional information:
追加情報：
Magic number(s): Same as Section 3.1.
マジック番号：セクション3.1と同じ。
File extension(s): .xml or .ent
ファイル拡張子：.xmlまたは.ent
Macintosh File Type Code(s): "TEXT"
Macintoshファイルタイプコード：「テキスト」
Person and email address for further information: Same as Section 3.1.
詳細については、個人および電子メールアドレス：セクション3.1と同じ。
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Same as Section 3.1.
著者/変更コントローラー：セクション3.1と同じ。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: xml-dtd
MIMEサブタイプ名：XML-DTD
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: charset
オプションのパラメーター：charset
The charset parameter of application/xml-dtd is handled the same as that of application/xml as described in Section 3.2.
Application/XML-DTDのCharSetパラメーターは、セクション3.2で説明されているように、アプリケーション/XMLの炭合わせパラメーターと同じように処理されます。
Encoding considerations: Same as Section 3.2.
考慮事項のエンコード：セクション3.2と同じ。
Security considerations: See Section 10.
セキュリティ上の考慮事項：セクション10を参照してください。
Interoperability considerations: XML DTDs have proven to be interoperable by DTD authoring tools and XML browsers, among others.
相互運用性の考慮事項：XML DTDは、とりわけDTDオーサリングツールやXMLブラウザーなどによって相互運用可能であることが証明されています。
Published specification: Same as text/xml as described in Section 3.1.
公開された仕様：セクション3.1で説明されているように、テキスト/XMLと同じ。
Applications which use this media type: DTD authoring tools handle external DTD subsets as well as external parameter entities. XML browsers may also access external DTD subsets and external parameter entities.
このメディアタイプを使用するアプリケーション：DTDオーサリングツールは、外部DTDサブセットと外部パラメーターエンティティを処理します。XMLブラウザは、外部DTDサブセットおよび外部パラメーターエンティティにアクセスすることもできます。
Additional information:
追加情報：
Magic number(s): Same as Section 3.1.
マジック番号：セクション3.1と同じ。
File extension(s): .dtd or .mod
ファイル拡張子：.dtdまたは.mod
Macintosh File Type Code(s): "TEXT"
Macintoshファイルタイプコード：「テキスト」
Person and email address for further information: Same as Section 3.1.
詳細については、個人および電子メールアドレス：セクション3.1と同じ。
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: Same as Section 3.1.
著者/変更コントローラー：セクション3.1と同じ。
The following list applies to text/xml, text/xml-external-parsed-entity, and XML-based media types under the top-level type "text" that define the charset parameter according to this specification:
次のリストは、テキスト/XML、テキスト/XML-External-Parsed-Entity、およびXMLベースのメディアタイプに適用されます。
o Charset parameter is strongly recommended.
o charsetパラメーターを強くお勧めします。
o If the charset parameter is not specified, the default is "us-ascii". The default of "iso-8859-1" in HTTP is explicitly overridden.
o Charsetパラメーターが指定されていない場合、デフォルトは「US-ASCII」です。HTTPの「ISO-8859-1」のデフォルトは明示的にオーバーライドされています。
o No error handling provisions.
o エラー処理条項はありません。
o An encoding declaration, if present, is irrelevant, but when saving a received resource as a file, the correct encoding declaration SHOULD be inserted.
o 存在する場合は、エンコード宣言は無関係ですが、受信リソースをファイルとして保存する場合、正しいエンコーディング宣言を挿入する必要があります。
The next list applies to application/xml, application/xml-external-parsed-entity, application/xml-dtd, and XML-based media types under top-level types other than "text" that define the charset parameter according to this specification:
次のリストは、アプリケーション/XML、Application/XML-External-Parsed-Entity、Application/XML-DTD、およびXMLベースのメディアタイプに適用されます。：
o Charset parameter is strongly recommended, and if present, it takes precedence.
o charsetパラメーターを強くお勧めします。存在する場合は、優先されます。
o If the charset parameter is omitted, conforming XML processors MUST follow the requirements in section 4.3.3 of [XML].
o charsetパラメーターが省略されている場合、XMLプロセッサの適合は、[XML]のセクション4.3.3の要件に従う必要があります。
Section 4.3.3 of [XML] specifies that XML MIME entities in the charset "utf-16" MUST begin with a byte order mark (BOM), which is a hexadecimal octet sequence 0xFE 0xFF (or 0xFF 0xFE, depending on endian). The XML Recommendation further states that the BOM is an encoding signature, and is not part of either the markup or the character data of the XML document.
[XML]のセクション4.3.3は、CharSet "UTF-16"のXML MIMEエンティティがバイトオーダーマーク（BOM）で開始する必要があることを指定しています。XMLの推奨は、BOMがエンコード署名であり、XMLドキュメントのマークアップデータまたは文字データの一部ではないことをさらに述べています。
Due to the presence of the BOM, applications that convert XML from "utf-16" to a non-Unicode encoding MUST strip the BOM before conversion. Similarly, when converting from another encoding into "utf-16", the BOM MUST be added after conversion is complete.
BOMが存在するため、XMLを「UTF-16」から非ユニコードエンコードに変換するアプリケーションは、変換前にBOMを剥奪する必要があります。同様に、別のエンコードから「UTF-16」に変換する場合、変換が完了した後にBOMを追加する必要があります。
In addition to the charset "utf-16", [RFC2781] introduces "utf-16le" (little endian) and "utf-16be" (big endian) as well. The BOM is prohibited for these charsets. When an XML MIME entity is encoded in "utf-16le" or "utf-16be", it MUST NOT begin with the BOM but SHOULD contain an encoding declaration. Conversion from "utf-16" to "utf-16be" or "utf-16le" and conversion in the other direction MUST strip or add the BOM, respectively.
charset "utf-16"に加えて、[RFC2781]は「UTF-16LE」（リトルエンディアン）および「UTF-16BE」（ビッグエンディアン）も導入します。BOMは、これらの充電器では禁止されています。XML MIMEエンティティが「UTF-16LE」または「UTF-16BE」でエンコードされている場合、BOMから始めてはなりませんが、エンコーディング宣言を含める必要があります。「UTF-16」から「UTF-16BE」または「UTF-16LE」への変換と他の方向への変換は、それぞれBOMをストリップまたは追加する必要があります。
Section 4.1 of [RFC2396] notes that the semantics of a fragment identifier (the part of a URI after a "#") is a property of the data resulting from a retrieval action, and that the format and interpretation of fragment identifiers is dependent on the media type of the retrieval result.
[RFC2396]のセクション4.1は、フラグメント識別子のセマンティクス（「＃」の後のURIの一部）は、検索アクションから生じるデータのプロパティであり、フラグメント識別子の形式と解釈は依存していることを指摘しています。検索結果のメディアタイプ。
As of today, no established specifications define identifiers for XML media types. However, a working draft published by W3C, namely "XML Pointer Language (XPointer)", attempts to define fragment identifiers for text/xml and application/xml. The current specification for XPointer is available at http://www.w3.org/TR/xptr.
今日の時点で、XMLメディアタイプの識別子を定義する確立された仕様はありません。ただし、W3Cが公開した作業ドラフト、つまり「XML Pointer言語（XPOINTER）」は、テキスト/XMLおよびApplication/XMLのフラグメント識別子を定義しようとします。Xpointerの現在の仕様は、http：//www.w3.org/tr/xptrで入手できます。
Section 5.1 of [RFC2396] specifies that the semantics of a relative URI reference embedded in a MIME entity is dependent on the base URI. The base URI is either (1) the base URI embedded in the MIME entity, (2) the base URI of the encapsulating MIME entity, (3) the URI used to retrieve the MIME entity, or (4) the application-dependent default base URI, where (1) has the highest precedence. [RFC2396] further specifies that the mechanism for embedding the base URI is dependent on the media type.
[RFC2396]のセクション5.1は、MIMEエンティティに埋め込まれた相対URI参照のセマンティクスがベースURIに依存していることを指定しています。ベースURIは（1）MIMEエンティティに埋め込まれたベースURI、（2）カプセル化MIMEエンティティのベースURI、（3）MIMEエンティティの取得に使用されるURI、または（4）アプリケーション依存のデフォルトベースURI、（1）の優先順位が最も高い。[RFC2396]は、ベースURIを埋め込むメカニズムがメディアタイプに依存していることをさらに指定します。
As of today, no established specifications define mechanisms for embedding the base URI in XML MIME entities. However, a Proposed Recommendation published by W3C, namely "XML Base", attempts to define such a mechanism for text/xml, application/xml, text/xml-external-parsed-entity, and application/xml-external-parsed-entity. The current specification for XML Base is available at http://www.w3.org/TR/xmlbase.
今日の時点で、XML MIMEエンティティにベースURIを埋め込むためのメカニズムを定義する確立された仕様はありません。ただし、W3Cが公開した提案された推奨、すなわち「XMLベース」は、テキスト/XML、アプリケーション/XML、テキスト/XML-External-Parsed-Entity、およびApplication/XML-External-Parsed-Parsed-Parsed-Parsed-Parsed-Parsed-Parsed-Parsed-Entityのこのようなメカニズムを定義しようとします。。XMLベースの現在の仕様は、http：//www.w3.org/tr/xmlbaseで入手できます。
This document recommends the use of a naming convention (a suffix of '+xml') for identifying XML-based MIME media types, whatever their particular content may represent. This allows the use of generic XML processors and technologies on a wide variety of different XML document types at a minimum cost, using existing frameworks for media type registration.
このドキュメントでは、特定のコンテンツが表すことが何であれ、XMLベースのMIMEメディアタイプを識別するために、ネーミング条約（「XML」の接尾辞）を使用することを推奨しています。これにより、メディアタイプの登録に既存のフレームワークを使用して、多種多様な異なるXMLドキュメントタイプで一般的なXMLプロセッサとテクノロジーを最小コストで使用できます。
Although the use of a suffix was not considered as part of the original MIME architecture, this choice is considered to provide the most functionality with the least potential for interoperability problems or lack of future extensibility. The alternatives to the ' +xml' suffix and the reason for its selection are described in Appendix A.
接尾辞の使用は元のMimeアーキテクチャの一部とは見なされませんでしたが、この選択は、相互運用性の問題や将来の拡張性の欠如の可能性が最も少ない最も機能性を提供すると考えられています。「XML」の接尾辞の代替案とその選択の理由は、付録Aで説明されています。
As XML development continues, new XML document types are appearing rapidly. Many of these XML document types would benefit from the identification possibilities of a more specific MIME media type than text/xml or application/xml can provide, and it is likely that many new media types for XML-based document types will be registered in the near and ongoing future.
XML開発が続くと、新しいXMLドキュメントタイプが急速に表示されています。これらのXMLドキュメントタイプの多くは、Text/XMLまたはApplication/XMLよりも具体的なMIMEメディアタイプの識別可能性の恩恵を受けることができます。また、XMLベースのドキュメントタイプの多くの新しいメディアタイプが登録される可能性があります。近くおよび進行中の未来。
While the benefits of specific MIME types for particular types of XML documents are significant, all XML documents share common structures and syntax that make possible common processing.
特定のタイプのXMLドキュメントの特定のMIMEタイプの利点は重要ですが、すべてのXMLドキュメントは、一般的な処理を可能にする共通の構造と構文を共有しています。
Some areas where 'generic' processing is useful include:
「ジェネリック」処理が役立ついくつかの領域には次のものがあります。
o Browsing - An XML browser can display any XML document with a provided [CSS] or [XSLT] style sheet, whatever the vocabulary of that document.
o ブラウジング-XMLブラウザは、そのドキュメントの語彙が何であれ、提供された[CSS]または[XSLT]スタイルシートを備えたXMLドキュメントを表示できます。
o Editing - Any XML editor can read, modify, and save any XML document.
o 編集 - XMLエディターは、XMLドキュメントを読み取り、変更、保存できます。
o Fragment identification - XPointers (work in progress) can work with any XML document, whatever vocabulary it uses and whether or not it uses XPointer for its own fragment identification.
o フラグメント識別-XPointers（進行中の作業）は、XMLドキュメントを使用する任意のXMLドキュメントで動作します。使用する語彙と、独自のフラグメント識別にXPointerを使用するかどうか。
o Hypertext linking - XLink (work in progress) hypertext linking is designed to connect any XML documents, regardless of vocabulary.
o ハイパーテキストリンク-Xlink（作業中）ハイパーテキストリンクは、語彙に関係なく、XMLドキュメントを接続するように設計されています。
o Searching - XML-oriented search engines, web crawlers, agents, and query tools should be able to read XML documents and extract the names and content of elements and attributes even if the tools are ignorant of the particular vocabulary used for elements and attributes.
o 検索-XML指向の検索エンジン、Webクローラー、エージェント、クエリツールは、XMLドキュメントを読み取り、要素と属性の名前とコンテンツを抽出できるはずです。
o Storage - XML-oriented storage systems, which keep XML documents internally in a parsed form, should similarly be able to process, store, and recreate any XML document.
o ストレージ-XML指向のストレージシステムは、XMLドキュメントをサングルされた形式で内部に保持するため、同様にXMLドキュメントを処理、保存、再作成できるはずです。
o Well-formedness and validity checking - An XML processor can confirm that any XML document is well-formed and that it is valid (i.e., conforms to its declared DTD or Schema).
o 整形式と有効性チェック - XMLプロセッサは、XMLドキュメントがよく形成されており、有効であることを確認できます（つまり、宣言されたDTDまたはスキーマに準拠しています）。
When a new media type is introduced for an XML-based format, the name of the media type SHOULD end with '+xml'. This convention will allow applications that can process XML generically to detect that the MIME entity is supposed to be an XML document, verify this assumption by invoking some XML processor, and then process the XML document accordingly. Applications may match for types that represent XML MIME entities by comparing the subtype to the pattern '*/*+xml'. (Of course, 4 of the 5 media types defined in this document -- text/xml, application/xml, text/xml-external-parsed-entity, and application/xml-external-parsed-entity -- also represent XML MIME entities while not conforming to the '*/*+xml' pattern.)
XMLベースの形式用に新しいメディアタイプが導入されると、メディアタイプの名前は「XML」で終了するはずです。この規則により、XMLを一般的に処理してMIMEエンティティがXMLドキュメントであることを検出し、XMLプロセッサを呼び出してこの仮定を検証し、それに応じてXMLドキュメントを処理できるアプリケーションを可能にします。アプリケーションは、サブタイプをパターン「*/* XML」と比較することにより、XML MIMEエンティティを表すタイプと一致する場合があります。（もちろん、このドキュメントで定義されている5つのメディアタイプのうち4つ - テキスト/XML、アプリケーション/XML、テキスト/XML-External-Parsed-Entity、およびApplication/XML-External-Parsed-Parsed-EntityはXML Mimeを表します「*/* xml」パターンに準拠していないエンティティ。）
NOTE: Section 14.1 of HTTP[RFC2616] does not support Accept headers of the form "Accept: */*+xml" and so this header MUST NOT be used in this way. Instead, content negotiation[RFC2703] could potentially be used if an XML-based MIME type were needed.
注：HTTP [RFC2616]のセクション14.1は、フォーム「Accept： */ * XML」のヘッダーを受け入れることをサポートしていないため、このヘッダーはこの方法で使用してはなりません。代わりに、XMLベースのMIMEタイプが必要な場合、コンテンツネゴシエーション[RFC2703]を使用する可能性があります。
XML generic processing is not always appropriate for XML-based media types. For example, authors of some such media types may wish that the types remain entirely opaque except to applications that are specifically designed to deal with that media type. By NOT following the naming convention '+xml', such media types can avoid XML-generic processing. Since generic processing will be useful in many cases, however -- including in some situations that are difficult to predict ahead of time -- those registering media types SHOULD use the '+xml' convention unless they have a particularly compelling reason not to.
XMLジェネリック処理は、XMLベースのメディアタイプに必ずしも適切ではありません。たとえば、そのようなメディアタイプの著者は、そのメディアタイプを扱うように特別に設計されたアプリケーションを除き、タイプが完全に不透明なままであることを望む場合があります。命名規則「XML」に従わないことにより、このようなメディアタイプはXML-Generic処理を回避できます。ただし、多くの場合、一般的な処理は有用であるため、事前に予測するのが難しい状況を含めますが、登録メディアタイプは、特に説得力のある理由がない限り、「XML」規則を使用する必要があります。
The registration process for these media types is described in [RFC2048]. The registrar for the IETF tree will encourage new XML-based media type registrations in the IETF tree to follow this guideline. Registrars for other trees SHOULD follow this convention in order to ensure maximum interoperability of their XML-based documents. Similarly, media subtypes that do not represent XML MIME entities MUST NOT be allowed to register with a '+xml' suffix.
これらのメディアタイプの登録プロセスは[RFC2048]で説明されています。IETFツリーのレジストラは、IETFツリーの新しいXMLベースのメディアタイプの登録を奨励し、このガイドラインに従います。他のツリーのレジストラは、XMLベースのドキュメントの最大の相互運用性を確保するために、この条約に従う必要があります。同様に、XML MIMEエンティティを表していないメディアサブタイプを「XML」サフィックスに登録することを許可してはなりません。
Registrations for new XML-based media types under the top-level type "text" SHOULD, in specifying the charset parameter and encoding considerations, define them as: "Same as [charset parameter / encoding considerations] of text/xml as specified in RFC 3023."
トップレベルタイプの「テキスト」の下の新しいXMLベースのメディアタイプの登録は、charsetパラメーターとエンコーディングの考慮事項を指定して、「charsetパラメーター /エンコード考慮事項」 / xmlのRFCで指定されているテキスト / XMLと定義する必要があります。3023. "
Registrations for new XML-based media types under top-level types other than "text" SHOULD, in specifying the charset parameter and encoding considerations, define them as: "Same as [charset parameter / encoding considerations] of application/xml as specified in RFC 3023."
「テキスト」以外のトップレベルタイプの下の新しいXMLベースのメディアタイプの登録は、charsetパラメーターとエンコーディングの考慮事項を指定して、「[charsetパラメーター /エンコード考慮事項] / xmlの指定 / xml」と定義する必要があります。RFC3023。 "
The use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the charset of the XML MIME entity.
この情報はXML MIMEエンティティのcharsetを信頼できるように決定するためにこの情報を使用できるため、charsetパラメーターの使用を強くお勧めします。
These registrations SHOULD specify that the XML-based media type being registered has all of the security considerations described in RFC 3023 plus any additional considerations specific to that media type.
これらの登録では、登録されているXMLベースのメディアタイプには、RFC 3023に記載されているすべてのセキュリティに関する考慮事項と、そのメディアタイプに固有の追加の考慮事項があることを指定する必要があります。
These registrations SHOULD also make reference to RFC 3023 in specifying magic numbers, fragment identifiers, base URIs, and use of the BOM.
これらの登録は、魔法の数字、フラグメント識別子、ベースURI、およびBOMの使用を指定する際にRFC 3023を参照する必要があります。
These registrations MAY reference the text/xml registration in RFC 3023 in specifying interoperability considerations, if these considerations are not overridden by issues specific to that media type.
これらの登録は、これらの考慮事項がそのメディアタイプに固有の問題によって無効にされない場合、相互運用性の考慮事項を指定する際にRFC 3023のテキスト/XML登録を参照する場合があります。
The examples below give the value of the MIME Content-type header and the XML declaration (which includes the encoding declaration) inside the XML MIME entity. For UTF-16 examples, the Byte Order Mark character is denoted as "{BOM}", and the XML declaration is assumed to come at the beginning of the XML MIME entity, immediately following the BOM. Note that other MIME headers may be present, and the XML MIME entity may contain other data in addition to the XML declaration; the examples focus on the Content-type header and the encoding declaration for clarity.
以下の例は、XML MIMEエンティティ内のMIMEコンテンツタイプのヘッダーとXML宣言（エンコーディング宣言を含む）の値を示しています。UTF-16の例では、バイトオーダーマーク文字は「{bom}」として示され、XML宣言はBOMの直後にXML MIMEエンティティの開始時に来ると想定されています。他のMIMEヘッダーが存在する可能性があり、XML MIMEエンティティにはXML宣言に加えて他のデータが含まれる場合があることに注意してください。例は、コンテンツタイプのヘッダーと、明確にするためのエンコーディング宣言に焦点を当てています。
Content-type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
This is the recommended charset value for use with text/xml. Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as UTF-8 encoded.
これは、テキスト/XMLで使用するために推奨される炭化値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-8エンコードとして扱う必要があります。
If sent using a 7-bit transport (e.g., SMTP[RFC0821]), the XML MIME entity MUST use a content-transfer-encoding of either quoted-printable or base64. For an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP), or a binary clean transport (e.g., HTTP), no content-transfer-encoding is necessary.
7ビットトランスポート（例：SMTP [RFC0821]）を使用して送信される場合、XML MIMEエンティティは、引用されたプリント可能またはBase64のコンテンツ転移エンコードを使用する必要があります。8ビットのクリーントランスポート（8ビットマイムESMTPまたはNNTPなど）、またはバイナリクリーントランスポート（HTTPなど）の場合、コンテンツトランスファーエンコードは必要ありません。
Content-type: text/xml; charset="utf-16"
{BOM}<?xml version='1.0' encoding='utf-16'?>
or
または又はそれとも若しくは乃至或るいは
{BOM}<?xml version='1.0'?>
This is possible only when the XML MIME entity is transmitted via HTTP, which uses a MIME-like mechanism and is a binary-clean protocol, hence does not perform CR and LF transformations and allows NUL octets. As described in [RFC2781], the UTF-16 family MUST NOT be used with media types under the top-level type "text" except over HTTP (see section 19.4.1 of [RFC2616] for details).
これは、XML MIMEエンティティがMIMEのようなメカニズムを使用し、バイナリクリーンプロトコルであるHTTPを介して送信される場合にのみ可能です。[RFC2781]で説明されているように、UTF-16ファミリーは、HTTPを除く除き、トップレベルのタイプ「テキスト」の下のメディアタイプで使用してはなりません（詳細については、[RFC2616]のセクション19.4.1を参照）。
Since HTTP is binary clean, no content-transfer-encoding is necessary.
HTTPはバイナリクリーンであるため、コンテンツ移動エンコードは必要ありません。
Content-type: text/xml; charset="utf-16be"
<?xml version='1.0' encoding='utf-16be'?>
Observe that the BOM does not exist. This is again possible only when the XML MIME entity is transmitted via HTTP.
BOMが存在しないことを観察してください。これは、XML MIMEエンティティがHTTPを介して送信される場合にのみ可能です。
Content-type: text/xml; charset="iso-2022-kr"
<?xml version="1.0" encoding='iso-2022-kr'?>
This example shows text/xml with a Korean charset (e.g., Hangul) encoded following the specification in [RFC1557]. Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as encoded per RFC 1557.
この例は、[RFC1557]の仕様に続いてエンコードされた韓国のチャーセット（ハングルなど）を使用したテキスト/XMLを示しています。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、密閉されたエンティティをRFC 1557ごとにエンコードしたものとして扱う必要があります。
Since ISO-2022-KR has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport.
ISO-2022-KRは7ビットのデータしか使用しないように定義されているため、輸送にはコンテンツ転送エンコードは必要ありません。
Content-type: text/xml
コンテンツタイプ：テキスト/XML
{BOM}<?xml version="1.0" encoding="utf-16"?>
or
または又はそれとも若しくは乃至或るいは
{BOM}<?xml version="1.0"?>
This example shows text/xml with the charset parameter omitted. In this case, MIME and XML processors MUST assume the charset is "us-ascii", the default charset value for text media types specified in [RFC2046]. The default of "us-ascii" holds even if the text/xml entity is transported using HTTP.
この例は、CharSetパラメーターを省略したテキスト/XMLを示しています。この場合、MIMEおよびXMLプロセッサは、[RFC2046]で指定されたテキストメディアタイプのデフォルトのチャーセット値である「US-ASCII」であると仮定する必要があります。テキスト/XMLエンティティがHTTPを使用して輸送されている場合でも、「US-ASCII」のデフォルトは保持されます。
Omitting the charset parameter is NOT RECOMMENDED for text/xml. For example, even if the contents of the XML MIME entity are UTF-16 or UTF-8, or the XML MIME entity has an explicit encoding declaration, XML and MIME processors MUST assume the charset is "us-ascii".
charsetパラメーターを省略することは、テキスト/xmlには推奨されません。たとえば、XML MIMEエンティティの内容がUTF-16またはUTF-8である場合でも、XML MIMEエンティティに明示的なエンコーディング宣言がある場合でも、XMLおよびMIMEプロセッサは、チャーセットが「US-ASSII」であると仮定する必要があります。
Content-type: application/xml; charset="utf-16"
{BOM}<?xml version="1.0" encoding="utf-16"?>
or
または又はそれとも若しくは乃至或るいは
{BOM}<?xml version="1.0"?>
This is a recommended charset value for use with application/xml. Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as UTF-16 encoded.
これは、アプリケーション/XMLで使用するための推奨されるcharSet値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-16エンコードとして扱う必要があります。
If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be encoded in quoted-printable or base64. For a binary clean transport (e.g., HTTP), no content-transfer-encoding is necessary.
7ビットトランスポート（SMTPなど）または8ビットクリーントランスポート（8ビットマイムESMTPまたはNNTPなど）を使用して送信する場合、XML MIMEエンティティは引用プリントまたはBase64でエンコードする必要があります。バイナリクリーントランスポート（HTTPなど）の場合、コンテンツトランスファーエンコードは必要ありません。
Content-type: application/xml; charset="utf-16be"
<?xml version='1.0' encoding='utf-16be'?>
Observe that the BOM does not exist. Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as UTF-16BE encoded.
BOMが存在しないことを観察してください。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、密閉されたエンティティをUTF-16BEエンコードとして扱う必要があります。
Content-type: application/xml; charset="iso-2022-kr"
<?xml version="1.0" encoding="iso-2022-kr"?>
This example shows application/xml with a Korean charset (e.g., Hangul) encoded following the specification in [RFC1557]. Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as encoded per RFC 1557, independent of whether the XML MIME entity has an internal encoding declaration (this example does show such a declaration, which agrees with the charset parameter).
この例は、[RFC1557]の仕様に続いてエンコードされた韓国のチャーセット（ハングルなど）を使用したアプリケーション/XMLを示しています。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、XML MIMEエンティティが内部エンコーディング宣言を持っているかどうかとは無関係に、囲まれたエンティティをRFC 1557ごとにエンコードするものとして扱う必要があります（この例は、charsetパラメーターと一致する宣言を示します）。
Since ISO-2022-KR has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport.
ISO-2022-KRは7ビットのデータしか使用しないように定義されているため、輸送にはコンテンツ転送エンコードは必要ありません。
Content-type: application/xml
コンテンツタイプ：アプリケーション/XML
{BOM}<?xml version='1.0' encoding="utf-16"?>
or
または又はそれとも若しくは乃至或るいは
{BOM}<?xml version='1.0'?>
For this example, the XML MIME entity begins with a BOM. Since the charset has been omitted, a conforming XML processor follows the requirements of [XML], section 4.3.3. Specifically, the XML processor reads the BOM, and thus knows deterministically that the charset is UTF-16.
この例では、XML MIMEエンティティはBOMで始まります。charsetが省略されているため、適合XMLプロセッサは[XML]の要件に従います。セクション4.3.3。具体的には、XMLプロセッサはBOMを読み取るため、チャーセットがUTF-16であることを決定論的に知っています。
An XML-unaware MIME processor SHOULD make no assumptions about the charset of the XML MIME entity.
XML-Unaware Mimeプロセッサは、XML Mimeエンティティの炭化について仮定しないでください。
Content-type: application/xml
コンテンツタイプ：アプリケーション/XML
<?xml version='1.0'?>
In this example, the charset parameter has been omitted, and there is no BOM. Since there is no BOM, the XML processor follows the requirements in section 4.3.3 of [XML], and optionally applies the mechanism described in Appendix F (which is non-normative) of [XML] to determine the charset encoding of UTF-8. The XML MIME entity does not contain an encoding declaration, but since the encoding is UTF-8, this is still a conforming XML MIME entity.
この例では、charsetパラメーターは省略されており、BOMはありません。BOMがないため、XMLプロセッサは[XML]のセクション4.3.3の要件に従い、[XML]の付録F（非規範的）に記載されているメカニズムをオプションで適用して、UTF-のチャーセットエンコーディングを決定します。8。XML MIMEエンティティにはエンコーディング宣言は含まれていませんが、エンコーディングはUTF-8であるため、これは依然としてXML MIMEエンティティです。
An XML-unaware MIME processor SHOULD make no assumptions about the charset of the XML MIME entity.
XML-Unaware Mimeプロセッサは、XML Mimeエンティティの炭化について仮定しないでください。
Content-type: application/xml
コンテンツタイプ：アプリケーション/XML
<?xml version='1.0' encoding="iso-10646-ucs-4"?>
In this example, the charset parameter has been omitted, and there is no BOM. However, the XML MIME entity does have an encoding declaration inside the XML MIME entity that specifies the entity's charset. Following the requirements in section 4.3.3 of [XML], and optionally applying the mechanism described in Appendix F (non-normative) of [XML], the XML processor determines the charset of the XML MIME entity (in this example, UCS-4).
この例では、charsetパラメーターは省略されており、BOMはありません。ただし、XML MIMEエンティティには、XML MIMEエンティティ内にエンティティのチャーセットを指定するエンコード宣言があります。[XML]のセクション4.3.3の要件に従って、[XML]の付録F（非規範的）に記載されているメカニズムをオプションで適用して、XMLプロセッサはXML MIMEエンティティの請求セットを決定します（この例では、UCS-4）。
An XML-unaware MIME processor SHOULD make no assumptions about the charset of the XML MIME entity.
XML-Unaware Mimeプロセッサは、XML Mimeエンティティの炭化について仮定しないでください。
Content-type: text/xml-external-parsed-entity; charset="utf-8"
<?xml encoding="utf-8"?>
This is the recommended charset value for use with text/xml-external-parsed-entity. Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as UTF-8 encoded.
これは、テキスト/XML-External-Parsed-Entityで使用するための推奨されるcharSet値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-8エンコードとして扱う必要があります。
If sent using a 7-bit transport (e.g., SMTP), the XML MIME entity MUST use a content-transfer-encoding of either quoted-printable or base64. For an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP), or a binary clean transport (e.g., HTTP) no content-transfer-encoding is necessary.
7ビットトランスポート（SMTPなど）を使用して送信される場合、XML MIMEエンティティは、引用プリント可能またはbase64のコンテンツ移動エンコードを使用する必要があります。8ビットのクリーントランスポート（8ビットマイムESMTPまたはNNTPなど）、またはバイナリクリーントランスポート（HTTPなど）の場合、コンテンツトランスファーエンコードは必要ありません。
Content-type: application/xml-external-parsed-entity;
charset="utf-16"
{BOM}<?xml encoding="utf-16"?>
or
または又はそれとも若しくは乃至或るいは
{BOM}<?xml?>
This is a recommended charset value for use with application/xml-external-parsed-entity. Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as UTF-16 encoded.
これは、アプリケーション/XML-External-Parsed-Entityで使用するための推奨されるcharSet値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-16エンコードとして扱う必要があります。
If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be encoded in quoted-printable or base64. For a binary clean transport (e.g., HTTP), no content-transfer-encoding is necessary.
7ビットトランスポート（SMTPなど）または8ビットクリーントランスポート（8ビットマイムESMTPまたはNNTPなど）を使用して送信する場合、XML MIMEエンティティは引用プリントまたはBase64でエンコードする必要があります。バイナリクリーントランスポート（HTTPなど）の場合、コンテンツトランスファーエンコードは必要ありません。
Content-type: application/xml-external-parsed-entity;
charset="utf-16be"
<?xml encoding="utf-16be"?>
Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as UTF-16BE encoded.
charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、密閉されたエンティティをUTF-16BEエンコードとして扱う必要があります。
Content-type: application/xml-dtd; charset="utf-8"
<?xml encoding="utf-8"?>
Charset "utf-8" is a recommended charset value for use with application/xml-dtd. Since the charset parameter is provided, MIME and XML processors MUST treat the enclosed entity as UTF-8 encoded.
charset "utf-8"は、アプリケーション/xml-dtdで使用するための推奨されるcharset値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-8エンコードとして扱う必要があります。
Content-type: application/mathml+xml
<?xml version="1.0" ?>
MathML documents are XML documents whose content describes mathematical information, as defined by [MathML]. As a format based on XML, MathML documents SHOULD use the '+xml' suffix convention in their MIME content-type identifier. However, no content type has yet been registered for MathML and so this media type should not be used until such registration has been completed.
MATHMLドキュメントは、[MATHML]で定義されているように、数学情報を説明するコンテンツのXMLドキュメントです。XMLに基づく形式として、MATHMLドキュメントは、MIMEコンテンツタイプの識別子で「XML」サフィックスコンベンションを使用する必要があります。ただし、MATHMLにはまだコンテンツタイプが登録されていないため、このような登録が完了するまでこのメディアタイプを使用しないでください。
Content-type: application/xslt+xml
<?xml version="1.0" ?>
Extensible Stylesheet Language (XSLT) documents are XML documents whose content describes stylesheets for other XML documents, as defined by [XSLT]. As a format based on XML, XSLT documents SHOULD use the '+xml' suffix convention in their MIME content-type identifier. However, no content type has yet been registered for XSLT and so this media type should not be used until such registration has been completed.
拡張可能なStyleSheet Language（XSLT）ドキュメントは、[XSLT]で定義されているように、他のXMLドキュメントのスタイルシートを説明するコンテンツのXMLドキュメントです。XMLに基づく形式として、XSLTドキュメントは、MIMEコンテンツタイプの識別子で「XML」サフィックス条約を使用する必要があります。ただし、XSLTにはまだコンテンツタイプが登録されていないため、このような登録が完了するまでこのメディアタイプを使用しないでください。
Content-type: application/rdf+xml
<?xml version="1.0" ?>
RDF documents identified using this MIME type are XML documents whose content describes metadata, as defined by [RDF]. As a format based on XML, RDF documents SHOULD use the '+xml' suffix convention in their MIME content-type identifier. However, no content type has yet been registered for RDF and so this media type should not be used until such registration has been completed.
このMIMEタイプを使用して特定されたRDFドキュメントは、[RDF]で定義されているように、メタデータを記述するコンテンツのXMLドキュメントです。XMLに基づく形式として、RDFドキュメントは、MIMEコンテンツタイプの識別子で「XML」サフィックス条約を使用する必要があります。ただし、RDFにはまだコンテンツタイプが登録されていないため、このような登録が完了するまでこのメディアタイプを使用しないでください。
Content-type: image/svg+xml
コンテンツタイプ：Image/SVG XML
<?xml version="1.0" ?> Scalable Vector Graphics (SVG) documents are XML documents whose content describes graphical information, as defined by [SVG]. As a format based on XML, SVG documents SHOULD use the '+xml' suffix convention in their MIME content-type identifier. However, no content type has yet been registered for SVG and so this media type should not be used until such registration has been completed.
<？xmlバージョン= "1.0"？>スケーラブルベクトルグラフィックス（SVG）ドキュメントは、[SVG]で定義されているように、グラフィック情報を説明するコンテンツのXMLドキュメントです。XMLに基づく形式として、SVGドキュメントは、MIMEコンテンツタイプの識別子で「XML」サフィックス条約を使用する必要があります。ただし、SVGにはまだコンテンツタイプが登録されていないため、このような登録が完了するまでこのメディアタイプを使用しないでください。
Content-type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="iso-8859-1"?>
Since the charset parameter is provided in the Content-Type header, MIME and XML processors MUST treat the enclosed entity as UTF-8 encoded. That is, the "iso-8859-1" encoding MUST be ignored.
Charsetパラメーターはコンテンツタイプのヘッダーで提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-8エンコードとして扱う必要があります。つまり、「ISO-8859-1」エンコーディングは無視する必要があります。
Processors generating XML MIME entities MUST NOT label conflicting charset information between the MIME Content-Type and the XML declaration.
XML MIMEエンティティを生成するプロセッサは、MIMEコンテンツタイプとXML宣言の間に競合する炭化情報にラベルを付けてはなりません。
As described in Section 7, this document updates the [RFC2048] registration process for XML-based MIME types.
セクション7で説明されているように、このドキュメントはXMLベースのMIMEタイプの[RFC2048]登録プロセスを更新します。
XML, as a subset of SGML, has all of the same security considerations as specified in [RFC1874], and likely more, due to its expected ubiquitous deployment.
XMLは、SGMLのサブセットとして、[RFC1874]で指定されたものと同じセキュリティ上の考慮事項をすべて持っています。
To paraphrase section 3 of RFC 1874, XML MIME entities contain information to be parsed and processed by the recipient's XML system. These entities may contain and such systems may permit explicit system level commands to be executed while processing the data. To the extent that an XML system will execute arbitrary command strings, recipients of XML MIME entities may be a risk. In general, it may be possible to specify commands that perform unauthorized file operations or make changes to the display processor's environment that affect subsequent operations.
RFC 1874のセクション3を言い換えるために、XML MIMEエンティティには、受信者のXMLシステムによって解析および処理される情報が含まれています。これらのエンティティには含まれる場合があり、そのようなシステムは、データの処理中に明示的なシステムレベルコマンドを実行することを許可する場合があります。XMLシステムが任意のコマンド文字列を実行する限り、XML MIMEエンティティの受信者がリスクになる可能性があります。一般に、不正なファイル操作を実行するコマンドを指定したり、後続の操作に影響を与えるディスプレイプロセッサの環境に変更を加えることができる場合があります。
In general, any information stored outside of the direct control of the user -- including CSS style sheets, XSL transformations, entity declarations, and DTDs -- can be a source of insecurity, by either obvious or subtle means. For example, a tiny "whiteout attack" modification made to a "master" style sheet could make words in critical locations disappear in user documents, without directly modifying the user document or the stylesheet it references. Thus, the security of any XML document is vitally dependent on all of the documents recursively referenced by that document.
一般に、CSSスタイルのシート、XSL変換、エンティティ宣言、DTDを含むユーザーの直接制御の外に保存されている情報は、明白または微妙な手段のいずれかによって不安の原因となります。たとえば、「マスター」スタイルのシートに作られた小さな「ホワイトアウト攻撃」の変更により、ユーザードキュメントやスタイルシートIT参照を直接変更せずに、ユーザードキュメントで重要な場所にある単語が消える可能性があります。したがって、XMLドキュメントのセキュリティは、そのドキュメントによって再帰的に参照されるすべてのドキュメントに極めて依存しています。
The entity lists and DTDs for XHTML 1.0[XHTML], for instance, are likely to be a commonly used set of information. Many developers will use and trust them, few of whom will know much about the level of security on the W3C's servers, or on any similarly trusted repository.
たとえば、XHTML 1.0 [XHTML]のエンティティリストとDTDは、一般的に使用される情報セットである可能性があります。多くの開発者はそれらを使用して信頼します。そのうちのほとんどは、W3Cのサーバー、または同様に信頼できるリポジトリのセキュリティレベルについて多くを知っています。
The simplest attack involves adding declarations that break validation. Adding extraneous declarations to a list of character entities can effectively "break the contract" used by documents. A tiny change that produces a fatal error in a DTD could halt XML processing on a large scale. Extraneous declarations are fairly obvious, but more sophisticated tricks, like changing attributes from being optional to required, can be difficult to track down. Perhaps the most dangerous option available to crackers is redefining default values for attributes: e.g., if developers have relied on defaulted attributes for security, a relatively small change might expose enormous quantities of information.
最も単純な攻撃には、検証を破る宣言を追加することが含まれます。キャラクターエンティティのリストに外的宣言を追加すると、ドキュメントで使用される「契約を破る」ことができます。DTDで致命的なエラーを生成する小さな変更は、大規模なXML処理を停止する可能性があります。無関係な宣言はかなり明白ですが、属性をオプションから必要に応じて変更するなど、より洗練されたトリックを追跡するのは難しい場合があります。おそらく、クラッカーが利用できる最も危険なオプションは、属性のデフォルト値を再定義することです。たとえば、開発者がセキュリティのデフォルトの属性に依存している場合、比較的小さな変更は膨大な量の情報を公開する可能性があります。
Apart from the structural possibilities, another option, "entity spoofing," can be used to insert text into documents, vandalizing and perhaps conveying an unintended message. Because XML 1.0 permits multiple entity declarations, and the first declaration takes precedence, it's possible to insert malicious content where an entity is used, such as by inserting the full text of Winnie the Pooh in every occurrence of —.
構造的可能性とは別に、別のオプション「エンティティスプーフィング」を使用して、テキストをドキュメントに挿入し、意図しないメッセージを破壊し、おそらく伝えることができます。XML 1.0は複数のエンティティ宣言を許可し、最初の宣言が優先されるため、＆mdash;
Use of the digital signatures work currently underway by the xmldsig working group may eventually ameliorate the dangers of referencing external documents not under one's own control.
XMLDSIGワーキンググループが現在進行中のデジタル署名の使用は、最終的に自分の管理下にない外部文書を参照する危険性を改善する可能性があります。
Use of XML is expected to be varied, and widespread. XML is under scrutiny by a wide range of communities for use as a common syntax for community-specific metadata. For example, the Dublin Core[RFC2413] group is using XML for document metadata, and a new effort has begun that is considering use of XML for medical information. Other groups view XML as a mechanism for marshalling parameters for remote procedure calls. More uses of XML will undoubtedly arise.
XMLの使用はさまざまであり、広範囲に及ぶと予想されます。XMLは、コミュニティ固有のメタデータの一般的な構文として使用するために、幅広いコミュニティによって精査されています。たとえば、ダブリンコア[RFC2413]グループは、ドキュメントメタデータにXMLを使用しており、医療情報にXMLの使用を検討している新しい取り組みが始まっています。他のグループは、XMLをリモートプロシージャコールのマーシャリングパラメーターのメカニズムと見なしています。XMLのより多くの用途は間違いなく発生します。
Security considerations will vary by domain of use. For example, XML medical records will have much more stringent privacy and security considerations than XML library metadata. Similarly, use of XML as a parameter marshalling syntax necessitates a case by case security review.
セキュリティ上の考慮事項は、使用ドメインによって異なります。たとえば、XMLの医療記録には、XMLライブラリメタデータよりもはるかに厳しいプライバシーとセキュリティの考慮事項があります。同様に、XMLをパラメーターマーシャリング構文として使用するには、ケースのセキュリティレビューによるケースが必要です。
XML may also have some of the same security concerns as plain text. Like plain text, XML can contain escape sequences that, when displayed, have the potential to change the display processor environment in ways that adversely affect subsequent operations. Possible effects include, but are not limited to, locking the keyboard, changing display parameters so subsequent displayed text is unreadable, or even changing display parameters to deliberately obscure or distort subsequent displayed material so that its meaning is lost or altered. Display processors SHOULD either filter such material from displayed text or else make sure to reset all important settings after a given display operation is complete.
XMLは、プレーンテキストと同じセキュリティ上の懸念の一部を持っている場合があります。プレーンテキストと同様に、XMLには、表示されると、後続の操作に悪影響を与える方法でディスプレイプロセッサ環境を変更する可能性があるエスケープシーケンスを含めることができます。可能な効果には、キーボードのロック、表示パラメーターの変更、その後の表示されたテキストが読み取れないか、表示された材料を意図的に不明瞭または歪めて、その意味が失われたり変更されたりするように、ディスプレイパラメーターを変更することも含まれますが、これらに限定されません。ディスプレイプロセッサは、表示されたテキストからそのような素材をフィルタリングするか、特定のディスプレイ操作が完了した後にすべての重要な設定をリセットするようにしてください。
Some terminal devices have keys whose output, when pressed, can be changed by sending the display processor a character sequence. If this is possible the display of a text object containing such character sequences could reprogram keys to perform some illicit or dangerous action when the key is subsequently pressed by the user. In some cases not only can keys be programmed, they can be triggered remotely, making it possible for a text display operation to directly perform some unwanted action. As such, the ability to program keys SHOULD be blocked either by filtering or by disabling the ability to program keys entirely.
一部の端子デバイスには、ディスプレイプロセッサに文字シーケンスを送信することで、出力を押すと変更できるキーがあります。これが可能な場合、そのような文字シーケンスを含むテキストオブジェクトの表示は、キーがその後ユーザーによって押されたときに、違法または危険なアクションを実行するためにキーを再プログラムすることができます。場合によっては、キーをプログラムできるだけでなく、リモートでトリガーでき、テキスト表示操作が不要なアクションを直接実行できるようにすることができます。そのため、キーをプログラムする機能は、フィルタリングまたはキーを完全にプログラムする機能を無効にすることでブロックする必要があります。
Note that it is also possible to construct XML documents that make use of what XML terms "entity references" (using the XML meaning of the term "entity" as described in Section 2), to construct repeated expansions of text. Recursive expansions are prohibited by [XML] and XML processors are required to detect them. However, even non-recursive expansions may cause problems with the finite computing resources of computers, if they are performed many times.
XML用語「エンティティ参照」（セクション2で説明されている「エンティティ」のXML意味を使用）を使用して、テキストの繰り返し拡張を構築するものを使用するXMLドキュメントを作成することも可能であることに注意してください。再帰的な拡張は[XML]によって禁止されており、それらを検出するにはXMLプロセッサが必要です。ただし、非再帰的拡張でさえ、コンピューターが何度も実行された場合、コンピューターの有限コンピューティングリソースに問題を引き起こす可能性があります。
References
参考文献
[ASCII] "US-ASCII. Coded Character Set -- 7-Bit American Standard Code for Information Interchange", ANSI X3.4-1986, 1986.
[ASCII]「US-ASCII。コード化された文字セット - インターチェンジのための7ビットアメリカ標準コード」、ANSI X3.4-1986、1986。
[CSS] Bos, B., Lie, H.W., Lilley, C. and I. Jacobs, "Cascading Style Sheets, level 2 (CSS2) Specification", World Wide Web Consortium Recommendation REC-CSS2, May 1998, <http://www.w3.org/TR/REC-CSS2/>.
[CSS] Bos、B.、Lie、H.W.、Lilley、C。and I. Jacobs、「Cascading Style Sheets、レベル2（CSS2）仕様」、World Wide Webコンソーシアム推奨REC-CSS2、<http：//www.w3.org/tr/rec-css2/>。
[ISO8859] "ISO-8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987", 1987.
[ISO8859] "ISO-8859。国際標準 - 情報処理 - 8ビットシングルバイトコード化されたグラフィック文字セット - パート1：ラテンアルファベットNo. 1、ISO-8859-1：1987"、1987。
[MathML] Ion, P. and R. Miner, "Mathematical Markup Language (MathML) 1.01", World Wide Web Consortium Recommendation REC-MathML, July 1999, <http://www.w3.org/TR/REC-MathML/>.
[Mathml] Ion、P。and R. Miner、「Mathematical Markup Language（Mathml）1.01」、World Wide Web Consortiumの推奨Rec-Mathml、1999年7月、<http://www.w3.org/tr/rec-mathml/>。
[PNG] Boutell, T., "PNG (Portable Network Graphics) Specification", World Wide Web Consortium Recommendation REC-png, October 1996, <http://www.w3.org/TR/REC-png>.
[PNG] Boutell、T。、「PNG（ポータブルネットワークグラフィックス）仕様」、World Wide Web Consortiumの推奨REC-PNG、1996年10月、<http://www.w3.org/tr/rec-png>。
[RDF] Lassila, O. and R.R. Swick, "Resource Description Framework (RDF) Model and Syntax Specification", World Wide Web Consortium Recommendation REC-rdf-syntax, February 1999, <http://www.w3.org/TR/REC-rdf-syntax/>.
[RDF] Lassila、O。およびR.R. Swick、「リソース説明フレームワーク（RDF）モデルと構文仕様」、World Wide Web Consortiumの推奨Recrdf-Syntax、1999年2月、<http://www.w3.org/tr/rec-rdf-syntax/>。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[RFC0977] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[RFC0977] Kantor、B。およびP. Lapsley、「Network News Transfer Protocol」、RFC 977、1986年2月。
[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月。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[RFC1874]レビンソン、E。、「SGMLメディアタイプ」、RFC 1874、1995年12月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、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、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[RFC2048] Freed、N.、Klensin、J。およびJ. Postel、「多目的インターネットメールエクステンション（MIME）パート4：登録手順」、RFC 2048、1996年11月。
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC2060] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 2060、1996年12月。
[RFC2077] Nelson, S., Parks, C. and Mitra, "The Model Primary Content Type for Multipurpose Internet Mail Extensions", RFC 2077, January 1997.
[RFC2077] Nelson、S.、Parks、C。and Mitra、「多目的インターネットメールエクステンションのモデルプライマリコンテンツタイプ」、RFC 2077、1997年1月。
[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月。
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M. and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997.
[RFC2130] Weider、C.、Preston、C.、Simonsen、K.、Alvestrand、H.、Atkinson、R.、Crispin、M。、およびP. Svanberg、」1996年3月1日」、RFC 2130、1997年4月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.
[RFC2376]ホワイトヘッド、E。およびM.ムラタ、「XMLメディアタイプ」、RFC 2376、1998年7月。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax.", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、RFC 2396、1998年8月。
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin Core Metadata for Resource Discovery", RFC 2413, September 1998.
[RFC2413] Weibel、S.、Kunze、J.、Lagoze、C。、およびM. Wolf、「リソース発見のためのダブリンコアメタデータ」、RFC 2413、1998年9月。
[RFC2445] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[RFC2445] Dawson、F。およびD. Stenerson、「インターネットカレンダーとスケジューリングコアオブジェクト仕様（ICALENDAR）」、RFC 2445、1998年11月。
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[RFC2518] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。、およびD. Jensen、「分散オーサリングのHTTP拡張 - WebDav」、RFC 2518、1999年2月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "Hypertext Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年6月。
[RFC2703] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[RFC2703] Klyne、G。、「プロトコルに依存しないコンテンツネゴシエーションフレームワーク」、RFC 2703、1999年9月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, Februrary 2000.
[RFC2781] Hoffman、P。およびF. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、Februrary 2000。
[RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
[RFC2801] Burdett、D。、「インターネットオープントレーディングプロトコル-IOTPバージョン1.0」、RFC 2801、2000年4月。
[SGML] International Standard Organization, "Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML)", ISO 8879, October 1986.
[SGML]国際標準組織、「情報処理 - テキストおよびオフィスシステム - 標準的な一般化マークアップ言語（SGML）」、ISO 8879、1986年10月。
[SVG] Ferraiolo, J., "Scalable Vector Graphics (SVG)", World Wide Web Consortium Candidate Recommendation SVG, November 2000, <http://www.w3.org/TR/SVG>.
[SVG] Ferraiolo、J。、「Scalable Vector Graphics（SVG）」、World Wide Web Consortium候補の推奨SVG、2000年11月、<http://www.w3.org/tr/svg>。
[XHTML] Pemberton, S. and et al, "XHTML 1.0: The Extensible HyperText Markup Language", World Wide Web Consortium Recommendation xhtml1, January 2000, <http://www.w3.org/TR/xhtml1>.
[Xhtml] Pemberton、S。and et al、「Xhtml 1.0：拡張可能なハイパーテキストマークアップ言語」、World Wide Webコンソーシアムの推奨XHTML1、2000年1月、<http://www.w3.org/tr/xhtml1>。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[XML] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C.M。E. Maler、「Extensible Markup Language（XML）1.0（第2版）」、World Wide Web Consortiumの推奨REC-XML、2000年10月、<http://www.w3.org/tr/rec-xml>。
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation xslt, November 1999, <http://www.w3.org/TR/xslt>.
[XSLT] Clark、J。、「XSL Transformations（XSLT）バージョン1.0」、World Wide Webコンソーシアムの推奨XSLT、1999年11月、<http://www.w3.org/tr/xslt>。
Authors' Addresses
著者のアドレス
MURATA Makoto (FAMILY Given) IBM Tokyo Research Laboratory 1623-14, Shimotsuruma Yamato-shi, Kanagawa-ken 242-8502 Japan
Murata Makoto（家族与えられた家族）IBM東京研究研究所1623-14、Shimotsuruma Yamato-shi、Kanagawa-Ken 242-8502 Japan
Phone: +81-46-215-4678
EMail: mmurata@trl.ibm.co.jp
Simon St.Laurent simonstl.com 1259 Dryden Road Ithaca, New York 14850 USA
Simon St.Laurent Simonstl.com 1259 Dryden Road Ithaca、New York 14850 USA
EMail: simonstl@simonstl.com
URI: http://www.simonstl.com/
Dan Kohn Skymoon Ventures 3045 Park Boulevard Palo Alto, California 94306 USA
Dan Kohn Skymoon Ventures 3045 Park Boulevard Palo Alto、California 94306 USA
Phone: +1-650-327-2600
EMail: dan@dankohn.com
URI: http://www.dankohn.com/
Appendix A. Why Use the '+xml' Suffix for XML-Based MIME Types?
付録A. XMLベースのMIMEタイプに「XML」サフィックスを使用するのはなぜですか？
Although the use of a suffix was not considered as part of the original MIME architecture, this choice is considered to provide the most functionality with the least potential for interoperability problems or lack of future extensibility. The alternatives to the '+xml' suffix and the reason for its selection are described below.
接尾辞の使用は元のMimeアーキテクチャの一部とは見なされませんでしたが、この選択は、相互運用性の問題や将来の拡張性の欠如の可能性が最も少ない最も機能性を提供すると考えられています。「XML」接尾辞の代替案とその選択の理由を以下に説明します。
A.1 Why not just use text/xml or application/xml and let the XML processor dispatch to the correct application based on the referenced DTD?
A.1 Text/XMLまたはApplication/XMLを使用して、参照されたDTDに基づいてXMLプロセッサを正しいアプリケーションにディスパッチさせてみませんか？
text/xml and application/xml remain useful in many situations, especially for document-oriented applications that involve combining XML with a stylesheet in order to present the data. However, XML is also used to define entirely new data types, and an XML-based format such as image/svg+xml fits the definition of a MIME media type exactly as well as image/png[PNG] does. (Note that image/svg+xml is not yet registered.) Although extra functionality is available for MIME processors that are also XML processors, XML-based media types -- even when treated as opaque, non-XML media types -- are just as useful as any other media type and should be treated as such.
テキスト/XMLおよびアプリケーション/XMLは、特にデータを提示するためにXMLとStyleSheetを組み合わせることを含むドキュメント指向のアプリケーションでは、多くの状況で有用なままです。ただし、XMLはまったく新しいデータ型を定義するためにも使用され、Image/SVG XMLなどのXMLベースの形式は、MIMEメディアタイプの定義とImage/PNG [PNG]が正確に適合します。（Image/SVG XMLはまだ登録されていないことに注意してください。）XMLプロセッサでもあるMIMEプロセッサでは追加機能がありますが、XMLベースのメディアタイプは、不透明な非XMLメディアタイプとして扱われても - 他のメディアタイプと同様に便利であり、そのように扱う必要があります。
Since MIME dispatchers work off of the MIME type, use of text/xml or application/xml to label discrete media types will hinder correct dispatching and general interoperability. Finally, many XML documents use neither DTDs nor namespaces, yet are perfectly legal XML.
MIMEディスパッチャはMIMEタイプで作業するため、テキスト/XMLまたはアプリケーション/XMLを使用して個別のメディアタイプにラベルを付けると、正しい派遣と一般的な相互運用性が妨げられます。最後に、多くのXMLドキュメントはDTDも名前空間も使用していませんが、完全に合法的なXMLです。
The subtree under which a media type is registered -- IETF, vendor (*/vnd.*), or personal (*/prs.*); see [RFC2048] for details -- is completely orthogonal from whether the media type uses XML syntax or not. The suffix approach allows XML document types to be identified within any subtree. The vendor subtree, for example, is likely to include a large number of XML-based document types. By using a suffix, rather than setting up a separate subtree, those types may remain in the same location in the tree of MIME types that they would have occupied had they not been based on XML.
メディアタイプが登録されているサブツリー-IETF、ベンダー（*/vnd。*）、または個人（*/prs。*）;詳細については、[RFC2048]を参照してください - メディアタイプがXML構文を使用するかどうかは完全に直交しています。サフィックスアプローチにより、XMLドキュメントタイプを任意のサブツリー内で識別できます。たとえば、ベンダーサブツリーには、多数のXMLベースのドキュメントタイプが含まれる可能性があります。別のサブツリーをセットアップするのではなく、接尾辞を使用することにより、これらのタイプは、XMLに基づいていなければ、それらが占有していたであろうMimeタイプの木の同じ場所に残ることができます。
The top-level MIME type (e.g., model/*[RFC2077]) determines what kind of content the type is, not what syntax it uses. For example, agents using image/* to signal acceptance of any image format should certainly be given access to media type image/svg+xml, which is in all respects a standard image subtype. It just happens to use XML to describe its syntax. The two aspects of the media type are completely orthogonal.
トップレベルのMIMEタイプ（例：Model/*[RFC2077]）は、使用する構文ではなく、タイプのコンテンツの種類を決定します。たとえば、画像/*を使用するエージェントは、任意の画像形式の受け入れを信号するためにメディアタイプの画像/SVG XMLへのアクセスを確実に与えられる必要があります。これは、標準画像サブタイプです。XMLを使用して構文を記述するだけです。メディアタイプの2つの側面は完全に直交しています。
XML-based data types will most likely be registered in ALL top-level categories. Potential, though currently unregistered, examples could include application/mathml+xml[MathML] and image/svg+xml[SVG].
XMLベースのデータ型は、おそらくすべてのトップレベルカテゴリに登録されます。現在、登録されていない可能性がありますが、例にはApplication/MathML XML [MATHML]およびImage/SVG XML [SVG]が含まれます。
Rather than explicitly labeling XML-based media types, the processor could look inside each type and see whether or not it is XML. The processor could also cache a list of XML-based media types.
XMLベースのメディアタイプに明示的にラベルを付けるのではなく、プロセッサは各タイプ内を調べて、XMLであるかどうかを確認できます。プロセッサは、XMLベースのメディアタイプのリストをキャッシュすることもできます。
Although this method might work acceptably for some mail applications, it would fail completely in many other uses of MIME. For instance, an XML-based web crawler would have no way of determining whether a file is XML except to fetch it and check. The same issue applies in some IMAP4[RFC2060] mail applications, where the client first fetches the MIME type as part of the message structure and then decides whether to fetch the MIME entity. Requiring these fetches just to determine whether the MIME type is XML could have significant bandwidth and latency disadvantages in many situations.
この方法では、一部のメールアプリケーションでは許容できる場合がありますが、他の多くのMIMEでは完全に失敗します。たとえば、XMLベースのWeb Crawlerには、ファイルがXMLであるかどうかを決定して確認する方法がありません。同じ問題は、一部のIMAP4 [RFC2060]メールアプリケーションで適用されます。クライアントは、最初にメッセージ構造の一部としてMIMEタイプを取得し、次にMIMEエンティティを取得するかどうかを決定します。MIMEタイプがXMLであるかどうかを判断するためだけに、これらのフェッチを要求することで、多くの状況で重要な帯域幅と遅延の欠点がある可能性があります。
Sniffing XML also isn't as simple as it might seem. DOCTYPE declarations aren't required, and they can appear fairly deep into a document under certain unpreventable circumstances. (E.g., the XML declaration, comments, and processing instructions can occupy space before the DOCTYPE declaration.) Even sniffing the DOCTYPE isn't completely reliable, thanks to a variety of issues involving default values for namespaces within external DTDs and overrides inside the internal DTD. Finally, the variety in potential character encodings (something XML provides tools to deal with), also makes reliable sniffing less likely.
XMLのスニッフィングも、見た目ほど単純ではありません。Doctype宣言は必要ありません。また、特定の冒険不可能な状況下では、文書にかなり深く表示される可能性があります。（例えば、XML宣言、コメント、および処理手順は、Doctype宣言の前にスペースを占める可能性があります。）Doctypeを嗅ぐことでさえ、外部DTD内の名前空間のデフォルト値と内部内のオーバーライドのデフォルト値を含むさまざまな問題のおかげで、完全に信頼できません。DTD。最後に、潜在的なキャラクターエンコーディングの多様性（XMLが対処するためのツールを提供するもの）は、信頼性のあるスニッフィングの可能性も低くなります。
For example, one could use "Content-Type: application/iotp; alternate-type=text/xml" or "Content-Type: application/iotp; syntax=xml".
たとえば、「content-type：application/iotp; alternate-type = text/xml」または「content-type：application/iotp; syntax = xml」を使用できます。
Section 5 of [RFC2045] says that "Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content". However, all XML-based media types are by their nature always XML. Parameters, as they have been defined in the MIME architecture, are never invariant across all instantiations of a media type.
[RFC2045]のセクション5は、「パラメーターはメディアサブタイプの修飾子であり、そのため、コンテンツの性質に根本的に影響しない」と述べています。ただし、すべてのXMLベースのメディアタイプは、その性質による常にXMLです。パラメーターは、MIMEアーキテクチャで定義されているように、メディアタイプのすべてのインスタンス化にわたって不変ではありません。
More practically, very few if any MIME dispatchers and other MIME agents support dispatching off of a parameter. While MIME agents on the receiving side will need to be updated in either case to support (or fall back to) generic XML processing, it has been suggested that it is easier to implement this functionality when acting off of the media type rather than a parameter. More important, sending agents require no update to properly tag an image as "image/svg+xml", but few if any sending agents currently support always tagging certain content types with a parameter.
より実際には、MIMEディスパッチャーや他のMIMEエージェントがパラメーターからの派遣をサポートしている場合、ほとんどはほとんどありません。受信側のMIMEエージェントは、一般的なXML処理をサポート（またはフォールバック）するためにどちらの場合も更新する必要がありますが、パラメーターではなくメディアタイプで作用するときにこの機能を実装する方が簡単であることが示唆されています。。さらに重要なことは、エージェントを送信するには、イメージを「画像/SVG XML」として適切にタグ付けするために更新する必要はありませんが、現在パラメーターで特定のコンテンツタイプをタグ付けすることをサポートする送信エージェントが現在サポートしている場合はほとんどありません。
This proposal fails under the simplest case, of a user with neither knowledge of XML nor an XML-capable MIME dispatcher. In that case, the user's MIME dispatcher is likely to dispatch the content to an XML processing application when the correct default behavior should be to dispatch the content to the application responsible for the content type (e.g., an ecommerce engine for application/iotp+xml[RFC2801], once this media type is registered).
この提案は、XMLの知識もXML利用可能なMIMEディスパッチャーもないユーザーの最も単純なケースの下で失敗します。その場合、ユーザーのMIMEディスパッチャーは、正しいデフォルトの動作がコンテンツタイプを担当するアプリケーションにコンテンツをディスパッチする必要がある場合に、コンテンツをXML処理アプリケーションにディスパッチする可能性があります（たとえば、アプリケーション/IOTP XMLのeコマースエンジン[RFC2801]、このメディアタイプが登録されたら）。
Note that even if the user had already installed the appropriate application (e.g., the ecommerce engine), and that installation had updated the MIME registry, many operating system level MIME registries such as .mailcap in Unix and HKEY_CLASSES_ROOT in Windows do not currently support dispatching off a parameter, and cannot easily be upgraded to do so. And, even if the operating system were upgraded to support this, each MIME dispatcher would also separately need to be upgraded.
ユーザーがすでに適切なアプリケーション（eコマースエンジンなど）を既にインストールしていて、そのインストールがMIMEレジストリを更新していたとしても、UNIXの.mailcapやhkey_classes_rootなどの多くのオペレーティングシステムレベルMIMEレジストリがWindowsの派遣をサポートしていないことに注意してください。パラメーターから外れて、簡単にアップグレードすることができません。また、これをサポートするためにオペレーティングシステムがアップグレードされたとしても、各MIMEディスパッチャーも個別にアップグレードする必要があります。
A.7 How about a new superclass MIME parameter that is defined to apply to all MIME types (e.g., Content-Type: application/iotp; $superclass=xml)?
A.7すべてのMIMEタイプに適用されるように定義されている新しいスーパークラスMIMEパラメーター（コンテンツタイプ：Application/IOTP; $ superclass = xml）はどうですか？
This combines the problems of Appendix A.5 and Appendix A.6.
これは、付録A.5と付録A.6の問題を組み合わせています。
If the sender attaches an image/svg+xml file to a message and includes the instructions "Please copy the French text on the road sign", someone with an XML-aware MIME client and an XML browser but no support for SVG can still probably open the file and copy the text. By contrast, with superclasses, the sender must add superclass support to her existing mailer AND the receiver must add superclass support to his before this transaction can work correctly.
送信者が画像/SVG XMLファイルをメッセージに添付し、「ロードサインにフランス語のテキストをコピーしてください」を含めている場合、XMLに認識されたMIMEクライアントとXMLブラウザを持っている人は、SVGのサポートはまだ開くことができませんファイルとテキストをコピーします。対照的に、スーパークラスとは、送信者は既存のメーラーにスーパークラスサポートを追加する必要があり、受信者はこの取引が正しく機能する前に彼のスーパークラスサポートを追加する必要があります。
If the receiver comes to rely on the superclass tag being present and applications are deployed relying on that tag (as always seems to happen), then only upgraded senders will be able to interoperate with those receiving applications.
レシーバーが存在するスーパークラスタグに依存し、アプリケーションがそのタグに依存して展開される場合（いつものように）、アップグレードされた送信者のみが、受信アプリケーションと相互運用することができます。
This has nearly identical problems to Appendix A.7, in that it requires both senders and receivers to be upgraded, and few if any operating systems and MIME dispatchers support working off of anything other than the MIME type.
これには、付録A.7とほぼ同じ問題があります。これは、送信者と受信機の両方をアップグレードする必要があり、MIMEタイプ以外の作業をサポートするオペレーティングシステムとMIMEディスパッチャがほとんどいない場合はほとんどありません。
This is better than Appendix A.8, in that no extra functionality needs to be added to a MIME registry to support dispatching of information other than standard content types. However, it still requires both sender and receiver to be upgraded, and it will also fail in many cases (e.g., web hosting to an outsourced server), where the user can set MIME types (often through implicit mapping to file extensions), but has no way of adding arbitrary HTTP headers.
これは付録A.8よりも優れています。なぜなら、標準のコンテンツタイプ以外の情報の発送をサポートするために、MIMEレジストリに追加の機能を追加する必要はないからです。ただし、送信者とレシーバーの両方をアップグレードする必要があり、多くの場合（例：アウトソーシングサーバーのWebホスティング）、ユーザーがMIMEタイプを設定できる（多くの場合、拡張機能をファイルするために暗黙的なマッピングを介して）失敗しますが、任意のHTTPヘッダーを追加する方法はありません。
When the conneg protocol is fully defined, this may potentially be a reasonable thing to do. But given the limited current state of conneg[RFC2703] development, it is not a credible replacement for a MIME-based solution.
Connegプロトコルが完全に定義されている場合、これは潜在的に合理的なことになる可能性があります。しかし、Conneg [RFC2703]開発の現在の現状を考えると、MIMEベースのソリューションの信頼できる代替品ではありません。
MIME explicitly defines two levels of content type, the top-level for the kind of content and the second-level for the specific media type. [RFC2048] extends this in an interoperable way by using prefixes to specify separate trees for IETF, vendor, and personal registrations. This specification also extends the two-level type by using the ' +xml' suffix. In both cases, processors that are unaware of these later specifications treat them as opaque and continue to interoperate. By contrast, adding a third-level type would break the current MIME architecture and cause numerous interoperability failures.
MIMEは、コンテンツの種類のトップレベルと特定のメディアタイプの2番目のレベルの2つのレベルのコンテンツタイプを明示的に定義します。[RFC2048]は、プレフィックスを使用してIETF、ベンダー、および個人登録の個別のツリーを指定することにより、相互運用可能な方法でこれを拡張します。この仕様は、「XML」サフィックスを使用して2レベルのタイプを拡張します。どちらの場合も、これらの後の仕様に気付いていないプロセッサは、それらを不透明として扱い、相互運用を継続します。対照的に、第3レベルのタイプを追加すると、現在のMIMEアーキテクチャが破損し、多数の相互運用性の障害が発生します。
As specified in Section 5.1 of [RFC2045], a tspecial can't be used:
[RFC2045]のセクション5.1で指定されているように、Tspecialは使用できません。
tspecials :=
"(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
It was thought that "." would not be a good choice since it is already used as an additional hierarchy delimiter. Also, "*" has a common wildcard meaning, and "-" and "_" are common word separators and easily confused. The characters %'`#& are frequently used for quoting or comments and so are not ideal.
「」と考えられていました。追加のヒエラルキーデリミッターとしてすでに使用されているため、良い選択ではありません。また、「*」には一般的なワイルドカードの意味があり、「 - 」と「_」は一般的なワードセパレーターであり、簡単に混乱します。文字％ '`＃＆は、引用やコメントに頻繁に使用されるため、理想的ではありません。
That leaves: ~!$^+{}|
Note that "-" is used heavily in the current registry. "$" and "_" are used once each. The others are currently unused.
「 - 」は現在のレジストリで大きく使用されていることに注意してください。「$」と「_」はそれぞれ1回使用されます。その他は現在未使用です。
It was thought that '+' expressed the semantics that a MIME type can be treated (for example) as both scalable vector graphics AND ALSO as XML; it is both simultaneously.
「MIMEタイプは（たとえば）スケーラブルなベクトルグラフィックスとXMLとしても扱うことができるというセマンティクスを表現したと考えられていました。どちらも同時にです。
MIME processors that are unaware of XML will treat the '+xml' suffix as completely opaque, so it is essential that no extra semantics be assigned to its presence. Therefore, application/foo and application/foo+xml SHOULD be treated as completely independent media types. Although, for example, text/calendar+xml could be an XML version of text/calendar[RFC2445], it is possible that this (hypothetical) new media type would include new semantics as well as new syntax, and in any case, there would be many applications that support text/calendar but had not yet been upgraded to support text/calendar+xml.
XMLを知らないMIMEプロセッサは、「XML」の接尾辞を完全に不透明として扱うため、その存在に追加のセマンティクスを割り当てないことが不可欠です。したがって、アプリケーション/FOOおよびアプリケーション/FOO XMLは、完全に独立したメディアタイプとして扱う必要があります。たとえば、テキスト/カレンダーXMLはテキスト/カレンダー[RFC2445]のXMLバージョンである可能性がありますが、この（仮説的な）新しいメディアタイプには新しいセマンティクスと新しい構文が含まれる可能性があります。テキスト/カレンダーをサポートするが、テキスト/カレンダーXMLをサポートするためにまだアップグレードされていない多くのアプリケーションになります。
In the ten years that MIME has existed, XML is the first generic data format that has seemed to justify special treatment, so it is hoped that no further suffixes will be necessary. However, if some are later defined, and these documents were also XML, they would need to specify that the '+xml' suffix is always the outermost suffix (e.g., application/foo+ebml+xml not application/foo+xml+ebml). If they were not XML, then they would use a regular suffix (e.g., application/foo+ebml).
MIMEが存在した10年で、XMLは特別な治療を正当化するように思われる最初の汎用データ形式であるため、それ以上の接尾辞が必要ないことが期待されています。ただし、後で定義されたものがあり、これらのドキュメントもXMLである場合、「XML」の接尾辞が常に最も外側の接尾辞であることを指定する必要があります（たとえば、アプリケーション/foo ebml xmlではなく、アプリケーション/foo xml ebml）。XMLでない場合は、通常の接尾辞（アプリケーション/FOO EBMLなど）を使用します。
You don't have to, but unless you have a good reason to explicitly disallow generic XML processing, you should use the suffix so as not to curtail the options of future users and developers.
必要はありませんが、一般的なXML処理を明示的に禁止する正当な理由がない限り、将来のユーザーと開発者のオプションを削減しないようにサフィックスを使用する必要があります。
Whether the inventors of a media type, today, design it for dispatch to generic XML processing machinery (and most won't) is not the critical issue. The core notion is that the knowledge that some media type happens to use XML syntax opens the door to unanticipated kinds of processing beyond those envisioned by its inventors, and on this basis identifying such encoding is a good and useful thing.
メディアタイプの発明者が今日、ジェネリックXML処理機械への派遣のために設計するかどうか（およびほとんどのことではない）かどうかは、重要な問題ではありません。コアの概念は、一部のメディアタイプがXML構文を使用しているという知識は、発明者が想定しているものを超えて予期せぬ種類の処理への扉を開くということです。
Developers of new media types are often tightly focused on a particular type of processing that meets current needs. But there is no need to rule out generic processing as well, which could make your media type more valuable over time. It is believed that registering with the '+xml' suffix will cause no interoperability problems whatsoever, while it may enable significant new functionality and interoperability now and in the future. So, the conservative approach is to include the '+xml' suffix.
新しいメディアタイプの開発者は、多くの場合、現在のニーズを満たす特定のタイプの処理に激しく焦点を当てています。しかし、一般的な処理も除外する必要はありません。これにより、メディアタイプが時間の経過とともにより価値のあるものになる可能性があります。「XML」の接尾辞に登録すると、相互運用性の問題はまったくありませんが、現在および将来的に重要な新しい機能と相互運用性を可能にする可能性があると考えられています。したがって、保守的なアプローチは、「XML」の接尾辞を含めることです。
There are numerous and significant differences between this specification and [RFC2376], which it obsoletes. This appendix summarizes the major differences only.
この仕様と[RFC2376]の間には多くの有意差があり、それは廃止されています。この付録は、大きな違いのみを要約しています。
First, text/xml-external-parsed-entity and application/xml-external-parsed-entity are added as media types for external parsed entities, and text/xml and application/xml are now prohibited.
まず、テキスト/XML-External-Parsed-entityとApplication/XML-External-Parsed-Entityが外部解析エンティティのメディアタイプとして追加され、Text/XMLおよびApplication/XMLが禁止されています。
Second, application/xml-dtd is added as a media type for external DTD subsets and external parameter entities, and text/xml and application/xml are now prohibited.
第二に、アプリケーション/XML-DTDは、外部DTDサブセットおよび外部パラメーターエンティティのメディアタイプとして追加され、テキスト/XMLおよびアプリケーション/XMLが禁止されています。
Third, "utf-16le" and "utf-16be" are added. RFC 2781 has introduced these BOM-less variations of the UTF-16 family.
第三に、「UTF-16LE」と「UTF-16BE」が追加されます。RFC 2781は、UTF-16ファミリーのこれらのBOMのないバリエーションを導入しました。
Fourth, a naming convention ('+xml') for XML-based media types has been added, which also updates [RFC2048] as described in Section 7. By following this convention, an XML-based media type can be easily recognized as such.
第4に、XMLベースのメディアタイプの命名規則（ 'XML'）が追加されました。これは、セクション7で説明されているように[RFC2048]を更新します。この規則に従って、XMLベースのメディアタイプは簡単に認識できます。
This document reflects the input of numerous participants to the ietf-xml-mime@imc.org mailing list, though any errors are the responsibility of the authors. Special thanks to:
このドキュメントは、IETF-XML-mime@imc.orgメーリングリストへの多数の参加者の入力を反映していますが、エラーは著者の責任です。特別な感謝：
Mark Baker, James Clark, Dan Connolly, Martin Duerst, Ned Freed, Yaron Goland, Rick Jelliffe, Larry Masinter, David Megginson, Keith Moore, Chris Newman, Gavin Nicol, Marshall Rose, Jim Whitehead and participants of the XML activity at the W3C.
マーク・ベイカー、ジェームズ・クラーク、ダン・コノリー、マーティン・デュエルスト、ネッド・フリード、ヤロン・ゴーランド、リック・ジェリフ、ラリー・マシン・、デビッド・メギンソン、キース・ムーア、クリス・ニューマン、ギャビン・ニコル、マーシャル・ローズ、ジム・ホワイトヘッド、W3CでのXML活動の参加者。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。