[要約] RFC 3023は、XML（Extensible Markup Language）エンティティのためのメディアタイプ、いわゆるMIMEタイプ（text/xml, application/xmlなど）を定義しています。エンコーディングの処理ルール、および接尾辞（+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.
この文書は、Extensible Markup Language（XML）に関連するネットワークエンティティの交換に使用するための5つの新しいメディアタイプ、すなわちtext/xml、application/xml、text/xml-external-parsed-entity、application/xml-external-parsed-entity、およびapplication/xml-dtdを標準化します。また、この文書は、これら5つのタイプ以外のメディアタイプがXML MIME（Multipurpose Internet Mail Extensions）エンティティを表す場合に、それらのメディアタイプに名前を付けるための規約（接尾辞「+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）text/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 Consortiumは、Extensible Markup Language（XML）1.0（Second Edition）[XML]を発行しました。XMLネットワークエンティティの交換を可能にするため、この文書は5つの新しいメディアタイプ、すなわちtext/xml、application/xml、text/xml-external-parsed-entity、application/xml-external-parsed-entity、およびapplication/xml-dtdと、XMLベースのMIMEメディアタイプを識別するための命名規約を標準化します。
XML entities are currently exchanged on the World Wide Web, and XML is also used for property values and parameter marshalling by the WebDAV[RFC2518] protocol for remote web authoring. Thus, there is a need for a media type to properly label the exchange of XML network entities.
XMLエンティティは現在、World Wide Webで交換されており、XMLはリモートWebオーサリング用のWebDAV [RFC2518]プロトコルによるプロパティ値とパラメーターマーシャリングにも使用されています。したがって、XMLネットワークエンティティの交換に適切にラベルを付けるためにメディアタイプが必要です。
Although XML is a subset of the Standard Generalized Markup Language (SGML) ISO 8879[SGML], which has been assigned the media types text/sgml and application/sgml, there are several reasons why use of text/sgml or application/sgml to label XML is inappropriate. First, there exist many applications that can process XML, but that cannot process SGML, due to SGML's larger feature set. Second, SGML applications cannot always process XML entities, because XML uses features of recent technical corrigenda to SGML. Third, the definition of text/sgml and application/sgml in [RFC1874] includes parameters for SGML bit combination transformation format (SGML-bctf), and SGML boot attribute (SGML-boot). Since XML does not use these parameters, it would be ambiguous if such parameters were given for an XML MIME entity. For these reasons, the best approach for labeling XML network entities is to provide new media types for XML.
XMLは、メディアタイプtext/sgmlとapplication/sgmlが割り当てられているStandard Generalized Markup Language（SGML）ISO 8879 [SGML]のサブセットですが、XMLのラベル付けにtext/sgmlやapplication/sgmlを使用することが不適切である理由がいくつかあります。第一に、SGMLの機能セットの方が大きいため、XMLは処理できてもSGMLは処理できないアプリケーションが数多く存在します。第二に、XMLはSGMLに対する最近の技術正誤表の機能を使用しているため、SGMLアプリケーションが常にXMLエンティティを処理できるとは限りません。第三に、[RFC1874]におけるtext/sgmlとapplication/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に基づいてメディアタイプがtext/xmlまたはapplication/xmlを使用して識別されないことは、セクション7で説明されている「XML」の接尾辞を使用して名前を付けておくべきです (SHOULD)。ツール - ブラウザー、エディター、検索エンジン、その他のプロセッサなど、すべてのXMLベースのメディアタイプと連携します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているように解釈されるものとします。
As defined in [RFC2781], the three charsets "utf-16", "utf-16le", and "utf-16be" are used to label UTF-16 text. In this document, "the UTF-16 family" refers to those three charsets. By contrast, the phrases "utf-16" or UTF-16 in this document refer specifically to the single charset "utf-16".
[rfc2781]で定義されているように、3つの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-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サブセット」、「外部解析対象エンティティ」、「外部パラメーターエンティティ」と呼ばれます。メディアタイプtext/xmlとapplication/xmlは「文書エンティティ」に使用してもよく (MAY)、「外部解析対象エンティティ」にはtext/xml-external-parsed-entityまたはapplication/xml-external-parsed-entityを使用すべきです (SHOULD)。「外部DTDサブセット」または「外部パラメーターエンティティ」には、メディアタイプapplication/xml-dtdを使用すべきです (SHOULD)。application/xmlとtext/xmlは、「外部パラメーターエンティティ」や「外部DTDサブセット」に使用してはならず (MUST NOT)、整形式の「文書エンティティ」でもあり、かつそのように参照される場合を除き、「外部解析対象エンティティ」に使用してはなりません (MUST NOT)。[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文書が一般のユーザーにとって読みやすい場合は、application/xmlよりもtext/xmlの方が望ましいです。text/xmlを明示的にサポートしていないMIMEユーザーエージェント（およびWebユーザーエージェント）は、たとえばXML MIMEエンティティをプレーンテキストとして表示するなど、それをtext/plainとして扱います。XML MIMEエンティティが一般のユーザーにとって読みにくい場合は、application/xmlの方が望ましいです。同様に、外部解析対象エンティティが一般のユーザーにとって読みやすい場合はtext/xml-external-parsed-entityの方が望ましいですが、プレーンテキストとしての表示が不適切な場合はapplication/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).
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パラメーターが明示的に指定されていない場合に異なる動作をします。text/xmlのデフォルトのcharset（すなわちUS-ASCII）が何らかの理由（たとえば不適切なWebサーバー）で不都合な場合、application/xmlが代替手段を提供します（セクション3.2のapplication/xml登録の「Optional parameters」を参照）。同じ規則が、text/xml-external-parsed-entityとapplication/xml-external-parsed-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のみを許可し、他のcharsetを禁止する場合もあります。この文書はそのようなメディアタイプを禁止せず、むしろそれらが増えることを想定しています。ただし、そのようなメディアタイプの開発者は、この文書を登録の基礎として使用することが強く推奨されます (RECOMMENDED)。特に、相互運用性を高めるため、charsetパラメーターは、セクション7.1で説明されているのと同じ方法で使用すべきです (SHOULD)。
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パラメーターの使用が強く推奨されます (RECOMMENDED)。charsetパラメーターは、HTTPにおけるcharsetに基づくコンテンツネゴシエーションなど、プロトコル固有の操作を提供するためにも使用できます。推奨値は、UTF-8のcharsetを表す「utf-8」[RFC2279]です。UTF-8は、[XML]に準拠するすべてのプロセッサでサポートされています。
If the XML MIME entity is transmitted via HTTP, which uses a MIME-like mechanism that is exempt from the restrictions on the text top-level type (see section 19.4.1 of [RFC2616]), "utf-16" [RFC2781]) is also recommended. UTF-16 is supported by all conforming processors of [XML]. Since the handling of CR, LF and NUL for text types in most MIME applications would cause undesired transformations of individual octets in UTF-16 multi-octet characters, gateways from HTTP to these MIME applications MUST transform the XML MIME entity from text/xml; charset="utf-16" to application/xml; charset="utf-16".
XML MIMEエンティティが、テキストトップレベルタイプの制限を免除されたMIMEに似たメカニズムを使用するHTTP（[RFC2616]のセクション19.4.1を参照）を介して送信される場合は、"utf-16" [RFC2781]も推奨されます。UTF-16は、[XML]のすべての適合プロセッサによってサポートされています。ほとんどのMIMEアプリケーションでのテキストタイプのCR、LF、およびNULの処理は、UTF-16マルチオクテット文字の個々のオクテットの望ましくない変換を引き起こすため、HTTPからこれらのMIMEアプリケーションへのゲートウェイは、XML MIMEエンティティをtext/xml; charset="utf-16" からapplication/xml; charset="utf-16" に変換しなければなりません (MUST)。
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パラメーターが省略されたtext/xmlエンティティが受信された場合、MIMEプロセッサとXMLプロセッサは、デフォルトのcharset値「us-ascii」[ASCII]を使用しなければなりません (MUST)。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処理エンジンは、内部の内容を一切参照せずに、トップレベルのメディアタイプ「text」のMIMEボディのトランスコーディングを行います。したがって、何らかのエージェントが、XML文書のエンコーディング宣言を変更せずに、text/xml; charset="iso-2022-jp"をtext/xml; charset="utf-8"に変更する可能性があります。第二に、text/xmlを理解しないMIMEエージェントはそれをtext/plainとして扱うことにフォールバックするため、text/xmlはtext/plainと互換性がなければなりません。text/xmlのcharsetパラメーターが権威を持たないとしたら、そのようなフォールバックによってデータが破損します。第三に、最近のWebサーバーは、ユーザーがcharsetパラメーターを指定できるよう改善されています。第四に、[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エンコード宣言を埋め込むことにより、チャーセットに関する情報を永続的に保存すべきです (SHOULD)。
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.
エンコーディングに関する考慮事項：このメディアタイプは、charsetと基礎となるMIMEトランスポートの能力に応じて適切にエンコードしてもよいです (MAY)。7ビットのトランスポートでは、UTF-8のデータはquoted-printableまたはbase64でエンコードしなければなりません (MUST)。8ビットクリーンなトランスポート（例：8BITMIME [RFC1652] ESMTPやNNTP [RFC0977]）では、UTF-8をエンコードする必要はありません。HTTP [RFC2616]上では、content-transfer-encodingは不要であり、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プロセッサがこの情報を使用してXML MIMEエンティティのcharsetを権威をもって判断できるため、charsetパラメーターの使用が強く推奨されます (RECOMMENDED)。charsetパラメーターは、HTTPにおけるcharsetに基づくコンテンツネゴシエーションなど、プロトコル固有の操作を提供するためにも使用できます。
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パラメーターが省略されたapplication/xmlエンティティを受信した場合、MIMEのContent-Typeヘッダーからはcharsetに関する情報が何も提供されていません。準拠するXMLプロセッサは、この事態に直接対処する[XML]のセクション4.3.3の要件に従わなければなりません (MUST)。ただし、XMLプロセッサではないMIMEプロセッサは、application/xmlエンティティでcharsetパラメーターが省略されている場合に、デフォルトのcharsetを想定すべきではありません (SHOULD NOT)。
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エンコード宣言を埋め込むことにより、チャーセットに関する情報を永続的に保存すべきです (SHOULD)。
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トランスポートの焦点と機能に適しているようにエンコードされる場合があります (MAY)。7ビットトランスポートの場合、UTF-8またはUTF-16のいずれかのデータを引用プリント可能またはBase64でエンコードしなければなりません (MUST)。8ビットのクリーントランスポート（例：8bitmime [RFC1652] ESMTPまたはNNTP [RFC0977]）の場合、UTF-8はエンコードされていませんが、UTF-16ファミリーはbase64でエンコードしなければなりません (MUST)。バイナリクリーントランスポート（例：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、text/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 存在する場合は、エンコード宣言は無関係ですが、受信リソースをファイルとして保存する場合、正しいエンコーディング宣言を挿入すべきです (SHOULD)。
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の要件に従わなければなりません (MUST)。
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）、すなわち16進オクテット列0xFE 0xFF（エンディアンによっては0xFF 0xFE）で開始しなければならない (MUST) ことを規定しています。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を剥奪しなければなりません (MUST)。同様に、別のエンコードから「UTF-16」に変換する場合、変換が完了した後にBOMを追加しなければなりません (MUST)。
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から始めてはなりません (MUST NOT)が、エンコーディング宣言を含めるべきです (SHOULD)。「UTF-16」から「UTF-16BE」または「UTF-16LE」への変換と他の方向への変換は、それぞれBOMをストリップまたは追加しなければなりません (MUST)。
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）」は、text/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.
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が公開したProposed Recommendationである「XML Base」は、text/xml、application/xml、text/xml-external-parsed-entity、およびapplication/xml-external-parsed-entityについて、そのようなメカニズムの定義を試みています。XML Baseの現在の仕様は、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」で終わるべきです (SHOULD)。この規約により、XMLを汎用的に処理できるアプリケーションは、MIMEエンティティがXML文書であるはずだと検出し、何らかのXMLプロセッサを呼び出してこの想定を検証し、それに応じてXML文書を処理できます。アプリケーションは、サブタイプをパターン「*/*+xml」と比較することで、XML MIMEエンティティを表すタイプに一致させることができます。（もちろん、この文書で定義する5つのメディアタイプのうち4つ、すなわちtext/xml、application/xml、text/xml-external-parsed-entity、およびapplication/xml-external-parsed-entityも、「*/*+xml」パターンには従わないもののXML MIMEエンティティを表します。）
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」規則を使用すべきです (SHOULD)。
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ベースのドキュメントの最大の相互運用性を確保するために、この条約に従うべきです (SHOULD)。同様に、XML MIMEエンティティを表していないメディアサブタイプを「XML」サフィックスに登録することを許可してはなりません (MUST NOT)。
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で指定されているtext/xmlと定義すべきです (SHOULD)。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."
「text」以外のトップレベルタイプの下での新しいXMLベースのメディアタイプの登録では、charsetパラメーターとエンコーディングに関する考慮事項を規定する際に、それらを「RFC 3023で規定されたapplication/xmlの[charsetパラメーター / エンコーディングに関する考慮事項]と同じ」と定義すべきです (SHOULD)。
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プロセッサがこの情報を使用してXML MIMEエンティティのcharsetを権威をもって判断できるため、charsetパラメーターの使用が強く推奨されます (RECOMMENDED)。
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に記載されているすべてのセキュリティに関する考慮事項と、そのメディアタイプに固有の追加の考慮事項があることを指定すべきです (SHOULD)。
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を参照すべきです (SHOULD)。
These registrations MAY reference the text/xml registration in RFC 3023 in specifying interoperability considerations, if these considerations are not overridden by issues specific to that media type.
これらの登録は、これらの考慮事項がそのメディアタイプに固有の問題によって無効にされない場合、相互運用性の考慮事項を指定する際にRFC 3023のtext/xml登録を参照する場合があります (MAY)。
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.
これは、text/xmlで使用するために推奨される炭化値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-8エンコードとして扱わなければなりません (MUST)。
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のコンテンツ転移エンコードを使用しなければなりません (MUST)。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).
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]の仕様に続いてエンコードされた韓国のチャーセット（ハングルなど）を使用したtext/xmlを示しています。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、密閉されたエンティティをRFC 1557ごとにエンコードしたものとして扱わなければなりません (MUST)。
Since ISO-2022-KR has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport.
ISO-2022-KRは7ビットのデータしか使用しないように定義されているため、輸送にはコンテンツ転送エンコードは必要ありません。
Content-type: text/xml
コンテンツタイプ：text/xml
{BOM}<?xml version="1.0" encoding="utf-16"?>
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パラメーターを省略したtext/xmlを示しています。この場合、MIMEプロセッサとXMLプロセッサは、charsetが[RFC2046]で規定されたtextメディアタイプのデフォルトのcharset値である「us-ascii」であると想定しなければなりません (MUST)。「us-ascii」というデフォルトは、text/xmlエンティティがHTTPを使用して転送される場合でも有効です。
Omitting the charset parameter is NOT RECOMMENDED for text/xml. For example, even if the contents of the XML MIME entity are UTF-16 or UTF-8, or the XML MIME entity has an explicit encoding declaration, XML and MIME processors MUST assume the charset is "us-ascii".
text/xmlについてcharsetパラメーターを省略することは推奨されません (NOT RECOMMENDED)。たとえば、XML MIMEエンティティの内容がUTF-16やUTF-8である場合や、XML MIMEエンティティに明示的なエンコーディング宣言がある場合でも、XMLプロセッサとMIMEプロセッサはcharsetが「us-ascii」であると想定しなければなりません (MUST)。
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.
これは、application/xmlで使用するための推奨されるcharSet値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-16エンコードとして扱わなければなりません (MUST)。
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でエンコードしなければなりません (MUST)。バイナリクリーントランスポート（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エンコードとして扱わなければなりません (MUST)。
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]の仕様に続いてエンコードされた韓国のチャーセット（ハングルなど）を使用したapplication/xmlを示しています。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、XML MIMEエンティティが内部エンコーディング宣言を持っているかどうかとは無関係に、囲まれたエンティティをRFC 1557ごとにエンコードするものとして扱わなければなりません (MUST)（この例は、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
コンテンツタイプ：application/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を認識しないMIMEプロセッサは、XML MIMEエンティティの文字セットについて前提を置くべきではありません (SHOULD)。
Content-type: application/xml
コンテンツタイプ：application/xml
<?xml version='1.0'?>
In this example, the charset parameter has been omitted, and there is no BOM. Since there is no BOM, the XML processor follows the requirements in section 4.3.3 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を認識しないMIMEプロセッサは、XML MIMEエンティティの文字セットについて前提を置くべきではありません (SHOULD)。
Content-type: application/xml
コンテンツタイプ：application/xml
<?xml version='1.0' encoding="iso-10646-ucs-4"?>
In this example, the charset parameter has been omitted, and there is no BOM. However, the XML 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を認識しないMIMEプロセッサは、XML MIMEエンティティの文字セットについて前提を置くべきではありません (SHOULD)。
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.
これは、text/xml-external-parsed-entityで使用するための推奨されるcharSet値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-8エンコードとして扱わなければなりません (MUST)。
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のコンテンツ移動エンコードを使用しなければなりません (MUST)。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.
これは、application/xml-external-parsed-entityで使用するための推奨されるcharSet値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-16エンコードとして扱わなければなりません (MUST)。
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でエンコードしなければなりません (MUST)。バイナリクリーントランスポート（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エンコードとして扱わなければなりません (MUST)。
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"は、application/xml-dtdで使用するための推奨されるcharset値です。charsetパラメーターが提供されるため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-8エンコードとして扱わなければなりません (MUST)。
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」サフィックスコンベンションを使用すべきです (SHOULD)。ただし、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」サフィックス条約を使用すべきです (SHOULD)。ただし、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」サフィックス条約を使用すべきです (SHOULD)。ただし、RDFにはまだコンテンツタイプが登録されていないため、このような登録が完了するまでこのメディアタイプを使用しないでください。
Content-type: image/svg+xml
Content-type: 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」サフィックス条約を使用すべきです (SHOULD)。ただし、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エンコードとして扱わなければなりません (MUST)。つまり、「ISO-8859-1」エンコーディングは無視しなければなりません (MUST)。
Processors generating XML MIME entities MUST NOT label conflicting charset information between the MIME Content-Type and the XML declaration.
XML MIMEエンティティを生成するプロセッサは、MIMEコンテンツタイプとXML宣言の間に競合する炭化情報にラベルを付けてはなりません (MUST NOT)。
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には、表示された際に後続の操作に悪影響を与える形で表示プロセッサの環境を変更する可能性のあるエスケープシーケンスを含めることができます。考えられる影響には、キーボードのロック、後続の表示テキストが読めなくなるような表示パラメーターの変更、あるいは後続の表示内容を意図的に不明瞭にしたり歪めたりしてその意味を失わせたり変えたりするような表示パラメーターの変更などがありますが、これらに限定されません。表示プロセッサは、表示テキストからそのような内容を除去するか、あるいは表示操作の完了後に重要な設定をすべて確実にリセットするかのいずれかを行うべきです (SHOULD)。
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.
一部の端子デバイスには、ディスプレイプロセッサに文字シーケンスを送信することで、出力を押すと変更できるキーがあります。これが可能な場合、そのような文字シーケンスを含むテキストオブジェクトの表示は、キーがその後ユーザーによって押されたときに、違法または危険なアクションを実行するためにキーを再プログラムすることができます。場合によっては、キーをプログラムできるだけでなく、リモートでトリガーでき、テキスト表示操作が不要なアクションを直接実行できるようにすることができます。そのため、キーをプログラムする機能は、フィルタリングまたはキーを完全にプログラムする機能を無効にすることでブロックすべきです (SHOULD)。
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, level 2 (CSS2) Specification", World Wide Web Consortium Recommendation REC-CSS2, May 1998, <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. and 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. and 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. and 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. and D. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
[RFC1874] Levinson, 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. and 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. and 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. and 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] Whitehead, E. and M. Murata、「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. and 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. and 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. and 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. and 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] International Standard Organization、「情報処理 - テキストおよびオフィスシステム - 標準的な一般化マークアップ言語（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. and 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/
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」接尾辞の代替案とその選択の理由を以下に説明します。
text/xml and application/xml remain useful in many situations, especially for document-oriented applications that involve combining XML with a stylesheet in order to present the data. However, XML is also used to define entirely new data types, and an XML-based format such as image/svg+xml fits the definition of a MIME media type exactly as well as image/png[PNG] does. (Note that image/svg+xml is not yet registered.) Although extra functionality is available for MIME processors that are also XML processors, XML-based media types -- even when treated as opaque, non-XML media types -- are just as useful as any other media type and should be treated as such.
text/xmlとapplication/xmlは、多くの状況、特にデータを提示するためにXMLをスタイルシートと組み合わせる文書指向のアプリケーションにおいて、引き続き有用です。しかし、XMLはまったく新しいデータ型を定義するためにも使用されており、image/svg+xmlのようなXMLベースの形式は、image/png [PNG]とまったく同様にMIMEメディアタイプの定義に合致します。（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タイプで作業するため、text/xmlまたはapplication/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]）は、タイプがどのような構文を使用するかではなく、どのような種類のコンテンツであるかを決定します。たとえば、任意の画像形式を受け入れることを示すためにimage/*を使用するエージェントには、あらゆる点で標準的な画像サブタイプであるメディアタイプimage/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処理をサポートする（またはそれにフォールバックする）ために更新する必要がありますが、パラメーターではなくメディアタイプに基づいて動作する方が、この機能を実装しやすいと指摘されています。さらに重要なことに、送信側のエージェントは、画像を「image/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ディスパッチャーも持たないユーザーという最も単純なケースで失敗します。その場合、正しいデフォルトの動作は、コンテンツタイプを担当するアプリケーション（たとえば、このメディアタイプが登録された後のapplication/iotp+xml [RFC2801]であれば電子商取引エンジン）にコンテンツをディスパッチすることであるのに、ユーザーのMIMEディスパッチャーはコンテンツをXML処理アプリケーションにディスパッチしてしまう可能性が高いです。
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ディスパッチャーも個別にアップグレードする必要があります。
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.
送信者がimage/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」接尾辞を完全に不透明として扱うため、その存在に追加のセマンティクスを割り当てないことが不可欠です。したがって、application/fooとapplication/foo+xmlは、完全に独立したメディアタイプとして扱うべきです (SHOULD)。たとえば、text/calendar+xmlはtext/calendar[RFC2445]のXMLバージョンである可能性がありますが、この（仮説的な）新しいメディアタイプには新しいセマンティクスと新しい構文が含まれる可能性があります。いずれにせよ、text/calendarはサポートしていてもtext/calendar+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」接尾辞が常に最も外側の接尾辞であることを規定する必要があります（例：application/foo+xml+ebmlではなくapplication/foo+ebml+xml）。XMLでない場合は、通常の接尾辞を使用します（例：application/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.
まず、text/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.
第二に、application/xml-dtdは、外部DTDサブセットおよび外部パラメーターエンティティのメディアタイプとして追加され、text/xmlおよびアプリケーション/XMLが禁止されています。
Third, "utf-16le" and "utf-16be" are added. RFC 2781 has introduced these BOM-less variations of the UTF-16 family.
第三に、「UTF-16LE」と「UTF-16BE」が追加されます。RFC 2781は、UTF-16ファミリーのこれらのBOMのないバリエーションを導入しました。
Fourth, a naming convention ('+xml') for XML-based media types has been added, which also updates [RFC2048] as described in Section 7. By following this convention, an XML-based media type can be easily recognized as such.
第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エディター機能の資金は現在、インターネット協会によって提供されています。