[要約] RFC 2376は、XMLメディアタイプの定義と使用方法に関するガイドラインです。このRFCの目的は、XMLデータの正確な表現と相互運用性を確保するための標準化を提供することです。
Network Working Group E. Whitehead
Request for Comments: 2376 UC Irvine
Category: Informational M. Murata
Fuji Xerox Info. Systems
July 1998
XML Media Types
CMLメディアタイプ
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML 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）に準拠しているネットワークエンティティの交換に使用するために、text / xmlとapplication / xmlの2つの新しいメディアサブタイプを提案しています。 XMLエンティティは現在、World Wide Web上のHyperText Transfer Protocolを介して交換され、リモートWebオーサリングのためのWebDAVプロトコルの不可欠な部分であり、多くのドメインでの実用性が期待されています。
Table of Contents
目次
1 INTRODUCTION ....................................................2
2 NOTATIONAL CONVENTIONS ..........................................3
3 XML MEDIA TYPES .................................................3
3.1 Text/xml Registration ........................................3
3.2 Application/xml Registration .................................6
4 SECURITY CONSIDERATIONS .........................................8
5 THE BYTE ORDER MARK (BOM) AND CONVERSIONS TO/FROM UTF-16 ........9
6 EXAMPLES ........................................................9
6.1 text/xml with UTF-8 Charset .................................10
6.2 text/xml with UTF-16 Charset ................................10
6.3 text/xml with ISO-2022-KR Charset ...........................10
6.4 text/xml with Omitted Charset ...............................11
6.5 application/xml with UTF-16 Charset .........................11
6.6 application/xml with ISO-2022-KR Charset ....................11
6.7 application/xml with Omitted Charset and UTF-16 XML Entity ..12
6.8 application/xml with Omitted Charset and UTF-8 Entity .......12
6.9 application/xml with Omitted Charset and Internal Encoding
Declaration.......................................................12
7 REFERENCES .....................................................13
8 ACKNOWLEDGEMENTS ...............................................14
9 ADDRESSES OF AUTHORS ...........................................14
10 FULL COPYRIGHT STATEMENT ......................................15
1 Introduction
1はじめに
The World Wide Web Consortium (W3C) has issued a Recommendation [REC-XML] which defines the Extensible Markup Language (XML), version 1. To enable the exchange of XML network entities, this document proposes two new media types, text/xml and application/xml.
World Wide Web Consortium（W3C）は、Extensible Markup Language（XML）バージョン1を定義する勧告[REC-XML]を発行しました。XMLネットワークエンティティの交換を可能にするために、このドキュメントでは、text / xmlという2つの新しいメディアタイプを提案しています。およびapplication / xml。
XML entities are currently exchanged on the World Wide Web, and XML is also used for property values and parameter marshalling by the WebDAV protocol for remote web authoring. Thus, there is a need for a media type to properly label the exchange of XML network entities. (Note that, as sometimes happens between two communities, both MIME and XML have defined the term entity, with different meanings.)
XMLエンティティは現在、World Wide Webで交換されており、XMLは、リモートWebオーサリング用のWebDAVプロトコルによるプロパティ値とパラメーターのマーシャリングにも使用されます。したがって、XMLネットワークエンティティの交換に適切にラベルを付けるメディアタイプが必要です。 （2つのコミュニティ間で時々発生するように、MIMEとXMLの両方でエンティティという用語が異なる意味で定義されていることに注意してください。）
Although XML is a subset of the Standard Generalized Markup Language (SGML) [ISO-8897], and currently is 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 which can process XML, but which 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 [RFC-1874] includes parameters for SGML bit combination transformation format (SGML-bctf), and SGML boot attribute (SGML-boot). Since XML does not use these parameters, it would be ambiguous if such parameters were given for an XML entity. For these reasons, the best approach for labeling XML network entities is to provide new media types for XML.
XMLは標準汎用マークアップ言語（SGML）[ISO-8897]のサブセットであり、現在メディアタイプtext / sgmlおよびapplication / sgmlが割り当てられていますが、text / sgmlまたはapplication / sgmlを使用してラベルXMLは不適切です。第1に、SGMLのより大きな機能セットにより、XMLは処理できるがSGMLは処理できない多くのアプリケーションが存在します。第2に、XMLはSGMLに対する最近の技術的修正の機能を使用するため、SGMLアプリケーションは常にXMLエンティティを処理できるわけではありません。 3番目に、text / sgmlとapplication / sgmlの定義[RFC-1874]には、SGMLビットの組み合わせ変換形式（SGML-bctf）とSGMLブート属性（SGML-boot）のパラメーターが含まれています。 XMLはこれらのパラメーターを使用しないため、そのようなパラメーターがXMLエンティティーに指定された場合はあいまいになります。これらの理由により、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 Consortium勧告には従来からIETFツリーメディアタイプが割り当てられており、同様のメディアタイプ（HTML、SGML）にはIETFツリーメディアタイプが割り当てられているため、XMLメディアはタイプもIETFメディアタイプツリーに属します。
2 Notational Conventions
2表記規則
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC-2119]で説明されているように解釈されます。
3 XML Media Types
ξCMLメディアタイプ
This document introduces two new media types for XML entities, text/xml and application/xml. Registration information for these media types are described in the sections below.
このドキュメントでは、XMLエンティティの2つの新しいメディアタイプ、text / xmlとapplication / xmlを紹介します。これらのメディアタイプの登録情報については、以下のセクションで説明します。
Every XML entity is suitable for use with the application/xml media type without modification. But this does not exploit the fact that XML can be treated as plain text in many cases. MIME user agents (and web user agents) that do not have explicit support for application/xml will treat it as application/octet-stream, for example, by offering to save it to a file.
すべてのXMLエンティティは、変更せずにapplication / xmlメディアタイプでの使用に適しています。しかし、これは多くの場合XMLがプレーンテキストとして処理できるという事実を利用しません。 application / xmlを明示的にサポートしていないMIMEユーザーエージェント（およびWebユーザーエージェント）は、たとえば、ファイルに保存することを申し出て、application / octet-streamとして扱います。
To indicate that an XML entity should be treated as plain text by default, use the text/xml media type. This restricts the encoding used in the XML entity to those that are compatible with the requirements for text media types as described in [RFC-2045] and [RFC-2046], e.g., UTF-8, but not UTF-16 (except for HTTP).
XMLエンティティをデフォルトでプレーンテキストとして扱う必要があることを示すには、text / xmlメディアタイプを使用します。これにより、XMLエンティティで使用されるエンコーディングは、[RFC-2045]と[RFC-2046]で説明されているテキストメディアタイプの要件と互換性のあるエンコーディングに制限されます。 HTTP）。
XML provides a general framework for defining sequences of structured data. In some cases, it may be desirable to define new media types which use XML but define a specific application of XML, perhaps due to domain-specific security considerations or runtime information. This document does not prohibit future media types dedicated to such XML applications. However, developers of such media types are recommended to use this document as a basis. In particular, the charset parameter should be used in the same manner.
XMLは、構造化データのシーケンスを定義するための一般的なフレームワークを提供します。場合によっては、XMLを使用し、XMLの特定のアプリケーションを定義する新しいメディアタイプを定義することが望ましい場合があります。これは、おそらくドメイン固有のセキュリティ上の考慮事項またはランタイム情報が原因です。このドキュメントでは、そのようなXMLアプリケーション専用の将来のメディアタイプを禁止していません。ただし、そのようなメディアタイプの開発者は、このドキュメントをベースとして使用することをお勧めします。特に、charsetパラメータは同じ方法で使用する必要があります。
Within the XML specification, XML entities can be classified into four types. In the XML terminology, they are called "document entities", "external DTD subsets", "external parsed entities", and "external parameter entities". The media types text/xml and application/xml can be used for any of these four types.
XML仕様では、XMLエンティティを4つのタイプに分類できます。 XML用語では、これらは「ドキュメントエンティティ」、「外部DTDサブセット」、「外部解析エンティティ」、および「外部パラメータエンティティ」と呼ばれます。メディアタイプtext / xmlおよびapplication / xmlは、これら4つのタイプのいずれにも使用できます。
MIME media type name: text
MIMEメディアタイプ名：テキスト
MIME subtype name: xml
MIMEサブタイプ名：xml
Mandatory parameters: none Optional parameters: charset
必須パラメーター：なしオプションパラメーター：文字セット
Although listed as an optional parameter, the use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the character encoding of the XML entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP. "UTF-8" [RFC-2279] is the recommended value, representing the UTF-8 charset. UTF-8 is supported by all conforming XML processors [REC-XML].
オプションのパラメーターとしてリストされていますが、charsetパラメーターの使用は強く推奨されます。この情報は、XMLエンティティーの文字エンコードを正式に決定するためにXMLプロセッサーが使用できるためです。 charsetパラメータを使用して、HTTPでの文字セットベースのコンテンツネゴシエーションなど、プロトコル固有の操作を提供することもできます。 "UTF-8" [RFC-2279]は、UTF-8文字セットを表す推奨値です。 UTF-8は、すべての準拠XMLプロセッサ[REC-XML]でサポートされています。
If the XML 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 HTTP 1.1 [RFC-2068]), "UTF-16" (Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646]) is also recommended. UTF-16 is supported by all conforming XML processors [REC-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 entity from a text/xml; charset="utf-16" to application/xml; charset="utf-16".
XMLエンティティがHTTPを介して送信される場合、テキストのトップレベルタイプ（HTTP 1.1 [RFC-2068]のセクション19.4.1を参照）の制限から除外されるMIMEのようなメカニズムを使用する場合、「UTF-16」 （[UNICODE]の付録C.3および[ISO-10646]の修正1）も推奨されます。 UTF-16は、すべての準拠XMLプロセッサ[REC-XML]でサポートされています。ほとんどのMIMEアプリケーションでテキストタイプのCR、LF、NULを処理すると、個々のオクテットがUTF-16マルチオクテット文字に望ましくない変換を起こすため、HTTPからこれらのMIMEアプリケーションへのゲートウェイは、text / xmlからXMLエンティティを変換する必要があります。 charset = "utf-16"をapplication / xmlに。 charset = "utf-16"。
Conformant with [RFC-2046], if a text/xml entity is received with the charset parameter omitted, MIME processors and XML processors MUST use the default charset value of "us-ascii". In cases where the XML entity is transmitted via HTTP, the default charset value is still "us-ascii".
[RFC-2046]に準拠し、charsetパラメータを省略してtext / xmlエンティティを受信した場合、MIMEプロセッサとXMLプロセッサは、デフォルトの文字セット値「us-ascii」を使用する必要があります。 XMLエンティティがHTTP経由で送信される場合でも、デフォルトの文字セット値は「us-ascii」のままです。
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 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 entity.
charsetパラメータは信頼できるため、charsetは常にXMLエンコーディング宣言内で宣言されるわけではありません。したがって、受信者がMIMEヘッダーを取り除き、受信したXMLエンティティの永続的なストレージを提供する場合は（ファイルシステムなどで）、特別な注意が必要です。文字セットがUTF-8またはUTF-16でない限り、受信者は、おそらくXMLエンティティ内に正しい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 both UTF-8 and UTF-16 is encoded in quoted-printable or base64. For 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64 encoded. For binary clean transports (e.g., HTTP), no content-transfer-encoding is necessary.
このメディアタイプは、文字セットと基になるMIMEトランスポートの機能に応じて適切にエンコードされる場合があります。 7ビットトランスポートの場合、UTF-8とUTF-16の両方のデータはquoted-printableまたはbase64でエンコードされます。 8ビットのクリーントランスポート（ESMTP、8BITMIME、NNTPなど）の場合、UTF-8はエンコードされませんが、UTF-16はbase64でエンコードされます。バイナリクリーントランスポート（HTTPなど）の場合、content-transfer-encodingは必要ありません。
Security considerations:
セキュリティに関する考慮事項：
See section 4 below.
以下のセクション4を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項：
XML has proven to be interoperable across WebDAV clients and servers, and for import and export from multiple XML authoring tools.
XMLは、WebDAVクライアントおよびサーバー間で相互運用可能であり、複数のXMLオーサリングツールからのインポートおよびエクスポートが可能であることが証明されています。
Published specification: see [REC-XML]
公開された仕様：[REC-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 clients and servers, as well as XML authoring tools.
XMLはデバイス、プラットフォーム、ベンダーに依存せず、さまざまなWebユーザーエージェント、WebDAVクライアント、サーバー、およびXMLオーサリングツールでサポートされています。
Additional information:
追加情報：
Magic number(s): none
マジックナンバー：なし
Although no byte sequences can be counted on to always be present, XML entities in ASCII-compatible charsets (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"). For more information, see Appendix F of [REC-XML].
バイトシーケンスが常に存在するとは限りませんが、ASCII互換の文字セット（UTF-8を含む）のXMLエンティティは、多くの場合、16進数の3C 3F 78 6D 6C（ "<？xml"）で始まります。詳細については、[REC-XML]の付録Fを参照してください。
File extension(s): .xml, .dtd
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
詳細についての人とメールアドレス：
Dan Connolly <connolly@w3.org>
Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp>
Intended usage: COMMON
使用目的：COMMON
Author/Change controller:
著者/変更コントローラ：
The XML specification is a work product of the World Wide Web Consortium's XML Working Group, and was edited by:
XML仕様は、World Wide WebコンソーシアムのXMLワーキンググループの成果物であり、次の者によって編集されました。
Tim Bray <tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
The W3C, and the W3C XML working group, has 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 entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP.
オプションのパラメーターとしてリストされていますが、charsetパラメーターの使用は強く推奨されています。これは、この情報をXMLプロセッサーがXMLエンティティの文字セットを正式に決定するために使用できるためです。 charsetパラメータを使用して、HTTPでの文字セットベースのコンテンツネゴシエーションなど、プロトコル固有の操作を提供することもできます。
"UTF-8" [RFC-2279] and "UTF-16" (Appendix C.3 of [UNICODE] and Amendment 1 of [ISO-10646]) are the recommended values, representing the UTF-8 and UTF-16 charsets, respectively. These charsets are preferred since they are supported by all conforming XML processors [REC-XML].
"UTF-8" [RFC-2279]および "UTF-16"（[UNICODE]の付録C.3および[ISO-10646]の修正1）は、UTF-8およびUTF-16文字セットを表す推奨値です、それぞれ。これらの文字セットは、すべての準拠XMLプロセッサ[REC-XML]でサポートされているため、推奨されます。
If an application/xml entity is received where the charset parameter is omitted, no information is being provided about the charset by the MIME Content-Type header. Conforming XML processors MUST follow the requirements in section 4.3.3 of [REC-XML] which directly address this contingency. However, MIME processors which 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ヘッダーによって文字セットに関する情報が提供されません。適合XMLプロセッサは、この不測の事態に直接対処する[REC-XML]のセクション4.3.3の要件に従う必要があります。ただし、XMLプロセッサではないMIMEプロセッサは、application / xmlエンティティから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 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 entity.
charsetパラメータは信頼できるため、charsetは常にXMLエンコーディング宣言内で宣言されるわけではありません。したがって、受信者がMIMEヘッダーを取り除き、受信したXMLエンティティの永続的なストレージを提供する場合は（ファイルシステムなどで）、特別な注意が必要です。文字セットがUTF-8またはUTF-16でない限り、受信者は、おそらくXMLエンティティ内に正しい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 both UTF-8 and UTF-16 is encoded in quoted-printable or base64. For 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), UTF-8 is not encoded, but UTF-16 is base64 encoded. For binary clean transport (e.g., HTTP), no content-transfer-encoding is necessary.
このメディアタイプは、文字セットと基になるMIMEトランスポートの機能に応じて適切にエンコードされる場合があります。 7ビットトランスポートの場合、UTF-8とUTF-16の両方のデータはquoted-printableまたはbase64でエンコードされます。 8ビットのクリーントランスポート（ESMTP、8BITMIME、NNTPなど）の場合、UTF-8はエンコードされませんが、UTF-16はbase64でエンコードされます。バイナリクリーントランスポート（HTTPなど）の場合、content-transfer-encodingは必要ありません。
Security considerations:
セキュリティに関する考慮事項：
See section 4 below.
以下のセクション4を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項：
XML has proven to be interoperable for import and export from multiple XML authoring tools.
XMLは、複数のXMLオーサリングツールからのインポートおよびエクスポートに対して相互運用可能であることが証明されています。
Published specification: see [REC-XML]
公開された仕様：[REC-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 and XML authoring tools.
XMLはデバイス、プラットフォーム、ベンダーに依存せず、さまざまなWebユーザーエージェントとXMLオーサリングツールでサポートされています。
Additional information:
追加情報：
Magic number(s): none
マジックナンバー：なし
Although no byte sequences can be counted on to always be present, XML entities in ASCII-compatible charsets (including UTF-8) often begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D or FF FE 3C 00 3F 00 78 00 6D 00 (the Byte Order Mark (BOM) followed by "<?xml"). For more information, see Annex F of [REC-XML].
常に存在するバイトシーケンスを数えることはできませんが、ASCII互換の文字セット（UTF-8を含む）のXMLエンティティは、多くの場合16進数の3C 3F 78 6D 6C（ "<？xml"）で始まり、UTF-16のエンティティは多くの場合16進数のFE FF 00 3C 00 3F 00 78 00 6DまたはFF FE 3C 00 3F 00 78 00 6D 00（バイトオーダーマーク（BOM）の後に "<？xml"が続く）で始まります。詳細については、[REC-XML]の付録Fを参照してください。
File extension(s): .xml, .dtd
Macintosh File Type Code(s): "TEXT"
Person & email address for further information:
詳細についての人とメールアドレス：
Dan Connolly <connolly@w3.org>
Murata Makoto (Family Given) <murata@fxis.fujixerox.co.jp>
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コンソーシアムのXMLワーキンググループの成果物であり、次の者によって編集されました。
Tim Bray <tbray@textuality.com>
Jean Paoli <jeanpa@microsoft.com>
C. M. Sperberg-McQueen <cmsmcq@uic.edu>
The W3C, and the W3C XML working group, has change control over the XML specification.
W3CおよびW3C XMLワーキンググループは、XML仕様を変更管理します。
4 Security Considerations
4セキュリティに関する考慮事項
XML, as a subset of SGML, has the same security considerations as specified in [RFC-1874].
XMLはSGMLのサブセットとして、[RFC-1874]で指定されているのと同じセキュリティ上の考慮事項があります。
To paraphrase section 3 of [RFC-1874], XML 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 entities may be at 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エンティティには、受信者のXMLシステムによって解析および処理される情報が含まれています。これらのエンティティにはデータが含まれている可能性があり、そのようなシステムでは、データの処理中に明示的なシステムレベルのコマンドを実行できる場合があります。 XMLシステムが任意のコマンド文字列を実行する範囲で、XMLエンティティの受信者が危険にさらされる可能性があります。一般に、不正なファイル操作を実行するコマンドを指定したり、後続の操作に影響を与えるディスプレイプロセッサの環境を変更したりすることが可能です。
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 group is using XML for document metadata, and a new effort has begun which 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は、コミュニティ固有のメタデータの一般的な構文として使用するために、幅広いコミュニティによって精査されています。たとえば、ダブリンコアグループはドキュメントメタデータに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 which, when displayed, have the potential to change the display processor environment in ways that adversely affect subsequent operations. Possible effects include, but are not limited to, locking the keyboard, changing display parameters so subsequent displayed text is unreadable, or even changing display parameters to deliberately obscure or distort subsequent displayed material so that its meaning is lost or altered. Display processors should either filter such material from displayed text or else make sure to reset all important settings after a given display operation is complete.
XMLには、プレーンテキストと同じセキュリティ上の懸念がある場合もあります。プレーンテキストと同様に、XMLにはエスケープシーケンスを含めることができます。エスケープシーケンスは、表示されると、後続の操作に悪影響を与える方法でディスプレイプロセッサ環境を変更する可能性があります。可能性のある影響には、キーボードのロック、表示パラメータの変更による後続の表示テキストの判読不能、または表示パラメータの変更による後続の表示資料の意図的な不明瞭化または変形などが含まれますが、これらに限定されません。ディスプレイプロセッサは、表示されたテキストからそのような素材をフィルタリングするか、特定の表示操作が完了した後にすべての重要な設定をリセットする必要があります。
Some terminal devices have keys whose output, when pressed, can be changed by sending the display processor a character sequence. If this is possible the display of a text object containing such character sequences could reprogram keys to perform some illicit or dangerous action when the key is subsequently pressed by the user. In some cases not only can keys be programmed, they can be triggered remotely, making it possible for a text display operation to directly perform some unwanted action. As such, the ability to program keys should be blocked either by filtering or by disabling the ability to program keys entirely.
一部の端末デバイスにはキーがあり、そのキーを押すと、ディスプレイプロセッサに文字シーケンスを送信することで出力を変更できます。これが可能である場合、そのような文字シーケンスを含むテキストオブジェクトの表示は、ユーザーがキーを押し続けたときに、キーを再プログラムして、不法または危険なアクションを実行する可能性があります。場合によっては、キーをプログラムできるだけでなく、リモートでトリガーできるため、テキスト表示操作で不要なアクションを直接実行できます。したがって、キーをプログラムする機能は、フィルタリングするか、キーを完全にプログラムする機能を無効にすることによってブロックする必要があります。
Note that it is also possible to construct XML documents which make use of what XML terms "entity references" (using the XML meaning of the term "entity", which differs from the MIME definition of this term), to construct repeated expansions of text. Recursive expansions are prohibited [REC-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用語を使用して（この用語のMIME定義とは異なる「エンティティ」という用語のXMLの意味を使用して）XMLドキュメントを作成し、テキストの繰り返し展開を作成することもできます。 。再帰的な展開は禁止されており[REC-XML]、それらを検出するにはXMLプロセッサが必要です。ただし、非再帰的な拡張であっても、何度も実行すると、コンピューターの有限のコンピューティングリソースに問題が発生する可能性があります。
5 The Byte Order Mark (BOM) and Conversions to/from UTF-16
5バイトオーダーマーク（BOM）およびUTF-16との変換
The XML Recommendation, in section 4.3.3, specifies that UTF-16 XML entities must begin with a byte order mark (BOM), which is the ZERO WIDTH NO-BREAK SPACE character, hexadecimal sequence 0xFEFF (or 0xFFFE, 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.
セクション4.3.3のXML勧告では、UTF-16 XMLエンティティはバイトオーダーマーク（BOM）で始まる必要があると規定しています。これは、ZERO WIDTH NO-BREAK SPACE文字、16進シーケンス0xFEFF（またはエンディアンに応じて0xFFFE）です。 。さらに、XML勧告では、BOMはエンコーディングシグネチャであり、XMLドキュメントのマークアップまたは文字データの一部ではないことが規定されています。
Due to the BOM, applications which convert XML from the UTF-16 encoding to another encoding SHOULD strip the BOM before conversion. Similarly, when converting from another encoding into UTF-16, the BOM SHOULD be added after conversion is complete.
BOMのため、XMLをUTF-16エンコーディングから別のエンコーディングに変換するアプリケーションは、変換前にBOMを削除する必要があります。同様に、別のエンコーディングからUTF-16に変換する場合、変換の完了後にBOM SHOULDを追加する必要があります。
6 Examples
6例
The examples below give the value of the Content-type MIME header and the XML declaration (which includes the encoding declaration) inside the XML 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 entity, immediately following the BOM. Note that other MIME headers may be present, and the XML 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エンティティ内のContent-type MIMEヘッダーとXML宣言（エンコーディング宣言を含む）の値を示しています。 UTF-16の例では、バイトオーダーマーク文字は「{BOM}」として示され、XML宣言はBOMの直後のXMLエンティティの先頭にあると想定されています。他のMIMEヘッダーが存在する場合があり、XMLエンティティにはXML宣言に加えて他のデータが含まれる場合があることに注意してください。例では、わかりやすくするためにContent-typeヘッダーとエンコーディング宣言に焦点を当てています。
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エンコードとして処理する必要があります。
If sent using a 7-bit transport (e.g. SMTP), the XML entity must use a content-transfer-encoding of either quoted-printable or base64. For an 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), or a binary clean transport (e.g., HTTP) no content-transfer-encoding is necessary.
7ビットのトランスポート（SMTPなど）を使用して送信する場合、XMLエンティティはquoted-printableまたはbase64のcontent-transfer-encodingを使用する必要があります。 8ビットのクリーントランスポート（ESMTP、8BITMIME、NNTPなど）、またはバイナリのクリーントランスポート（HTTPなど）の場合、コンテンツ転送エンコーディングは不要です。
Content-type: text/xml; charset="utf-16"
{BOM}<?xml version='1.0' encoding='utf-16'?>
This is possible only when the XML 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. This differs from typical text MIME type processing (see section 19.4.1 of HTTP 1.1 [RFC-2068] for details).
これは、XMLエンティティがHTTP経由で送信される場合にのみ可能です。HTTPはMIMEのようなメカニズムを使用し、バイナリクリーンなプロトコルであるため、CRおよびLF変換を実行せず、NULオクテットを許可します。これは、一般的なテキストMIMEタイプの処理とは異なります（詳細については、HTTP 1.1 [RFC-2068]のセクション19.4.1を参照してください）。
Since HTTP is binary clean, no content-transfer-encoding is necessary.
HTTPはバイナリクリーンであるため、content-transfer-encodingは必要ありません。
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 [RFC-1557]. Since the charset parameter is provided, MIME and XML processors must treat the enclosed entity as encoded per [RFC-1557].
この例は、[RFC-1557]の仕様に従ってエンコードされた韓国語の文字セット（ハングルなど）を含むtext / xmlを示しています。 charsetパラメータが指定されているため、MIMEおよびXMLプロセッサは、囲まれたエンティティを[RFC-1557]に従ってエンコードされたものとして扱う必要があります。
Since ISO-2022-KR has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport.
ISO-2022-KRは7ビットのデータのみを使用するように定義されているため、トランスポートでコンテンツ転送エンコードは必要ありません。
Content-type: text/xml
コンテンツタイプ：text / xml
{BOM}<?xml version="1.0" encoding="utf-16"?>
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 [RFC-2046]. The default of "us-ascii" holds even if the text/xml entity is transported using HTTP.
この例は、charsetパラメータを省略したtext / xmlを示しています。この場合、MIMEおよびXMLプロセッサは、文字セットが[us-ascii]であると想定する必要があります。これは、[RFC-2046]で指定されているテキストメディアタイプのデフォルトの文字セット値です。 「us-ascii」のデフォルトは、text / xmlエンティティがHTTPを使用して転送される場合でも保持されます。
Omitting the charset parameter is NOT RECOMMENDED for text/xml. For example, even if the contents of the XML entity are UTF-16 or UTF-8, or the XML entity has an explicit encoding declaration, XML and MIME processors must assume the charset is "us-ascii".
charsetパラメータを省略することは、text / xmlでは推奨されません。たとえば、XMLエンティティのコンテンツがUTF-16またはUTF-8である場合、またはXMLエンティティに明示的なエンコーディング宣言がある場合でも、XMLおよびMIMEプロセッサは文字セットが「us-ascii」であると想定する必要があります。
Content-type: application/xml; charset="utf-16"
{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パラメータが指定されているため、MIMEおよびXMLプロセッサは、囲まれたエンティティをUTF-16エンコードとして処理する必要があります。
If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean transport (e.g., ESMTP, 8BITMIME, or NNTP), the XML 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ビットクリーントランスポート（ESMTP、8BITMIME、NNTPなど）を使用して送信する場合、XMLエンティティはquoted-printableまたはbase64でエンコードする必要があります。バイナリクリーントランスポート（HTTPなど）の場合、content-transfer-encodingは必要ありません。
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 [RFC-1557]. 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 entity has an internal encoding declaration (this example does show such a declaration, which agrees with the charset parameter).
この例は、[RFC-1557]の仕様に従ってエンコードされた韓国語の文字セット（ハングルなど）を含むapplication / xmlを示しています。 charsetパラメータが指定されているため、MIMEおよびXMLプロセッサは、XMLエンティティに内部エンコーディング宣言があるかどうかに関係なく、囲まれたエンティティを[RFC-1557]に従ってエンコードされたものとして処理する必要があります（この例では、このような宣言が示され、文字セットと一致します。パラメータ）。
Since ISO-2022-KR has been defined to use only 7 bits of data, no content-transfer-encoding is necessary with any transport.
ISO-2022-KRは7ビットのデータのみを使用するように定義されているため、トランスポートでコンテンツ転送エンコードは必要ありません。
Content-type: application/xml
コンテンツタイプ：application / xml
{BOM}<?xml version='1.0'?>
For this example, the XML entity begins with a BOM. Since the charset has been omitted, a conforming XML processor follows the requirements of [REC-XML], section 4.3.3. Specifically, the XML processor reads the BOM, and thus knows deterministically that the charset encoding is UTF-16.
この例では、XMLエンティティはBOMで始まります。文字セットが省略されているため、準拠するXMLプロセッサは[REC-XML]のセクション4.3.3の要件に従います。具体的には、XMLプロセッサはBOMを読み取るため、文字セットエンコーディングがUTF-16であることを確定的に認識します。
An XML-unaware MIME processor should make no assumptions about the charset of the XML entity.
XML非対応MIMEプロセッサは、XMLエンティティの文字セットについて想定しないでください。
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, and optionally applies the mechanism described in appendix F (which is non-normative) of [REC-XML] to determine the charset encoding of UTF-8. The XML entity does not contain an encoding declaration, but since the encoding is UTF-8, this is still a conforming XML entity.
この例では、charsetパラメーターが省略されており、BOMはありません。 BOMがないため、XMLプロセッサはセクション4.3.3の要件に従い、オプションで[REC-XML]の付録F（非規範的）で説明されているメカニズムを適用して、UTF-8の文字セットエンコーディングを決定します。 XMLエンティティにはエンコーディング宣言が含まれていませんが、エンコーディングはUTF-8であるため、これは準拠XMLエンティティのままです。
An XML-unaware MIME processor should make no assumptions about the charset of the XML entity.
XML非対応MIMEプロセッサは、XMLエンティティの文字セットについて想定しないでください。
6.9 application/xml with Omitted Charset and Internal Encoding Declaration
6.9 省略された文字セットと内部エンコーディング宣言を含むapplication / xml
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 entity does have an encoding declaration inside the XML entity which specifies the entity's charset. Following the requirements in section 4.3.3, and optionally applying the mechanism described in appendix F (non-normative) of [REC-XML], the XML processor determines the charset encoding of the XML entity (in this example, UCS-4).
この例では、charsetパラメーターが省略されており、BOMはありません。ただし、XMLエンティティには、エンティティの文字セットを指定するエンコーディング宣言がXMLエンティティ内にあります。セクション4.3.3の要件に従い、オプションで[REC-XML]の付録F（非規範的）で説明されているメカニズムを適用すると、XMLプロセッサはXMLエンティティ（この例ではUCS-4）の文字セットエンコーディングを決定します。
An XML-unaware MIME processor should make no assumptions about the charset of the XML entity.
XML非対応MIMEプロセッサは、XMLエンティティの文字セットについて想定しないでください。
7 References
7参考文献
[ISO-10646] ISO/IEC, Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane, May 1993.
[ISO-10646] ISO / IEC、情報技術-ユニバーサルマルチオクテットコード化文字セット（UCS）-パート1：アーキテクチャと基本的な多言語プレーン、1993年5月。
[ISO-8897] ISO (International Organization for Standardization) ISO 8879:1986(E) Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML). First edition -- 1986- 10-15.
[ISO-8897] ISO（国際標準化機構）ISO 8879：1986（E）情報処理-テキストおよびオフィスシステム-標準Generalized Markup Language（SGML）。初版-1986-10-15。
[REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)" World Wide Web Consortium Recommendation REC- xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210.
[REC-XML] T.ブレイ、J。パオリ、C。M.スペルバーグ-マックィーン、「Extensible Markup Language（XML）」World Wide Web Consortium Recommendation REC- xml-19980210。 http://www.w3.org/TR/1998/REC-xml-19980210。
[RFC-1557] Choi, U., Chon, K., and H. Park. "Korean Character Encoding for Internet Messages", RFC 1557. December, 1993.
[RFC-1557]チェ、U、チョン、K、Hパーク。 「インターネットメッセージの韓国語の文字エンコーディング」、RFC1557。1993年12月。
[RFC-1874] Levinson, E., "SGML Media Types", RFC 1874. December 1995.
[RFC-1874] Levinson、E。、「SGML Media Types」、RFC1874。1995年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC-2045] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC-2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC-2046] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[RFC-2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC-2068] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、1997年1月。
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC-2279] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
[UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard-Version 2.0」、Addison-Wesley、1996。
8 Acknowledgements
8謝辞
Chris Newman and Yaron Y. Goland both contributed content to the security considerations section of this document. In particular, some text in the security considerations section is copied verbatim from work in progress, draft-newman-mime-textpara-00, by permission of the author. Chris Newman additionally contributed content to the encoding considerations sections. Dan Connolly contributed content discussing when to use text/xml. Discussions with Ned Freed and Dan Connolly helped refine the author's understanding of the text media type; feedback from Larry Masinter was also very helpful in understanding media type registration issues.
Chris NewmanとYaron Y. Golandの両方が、このドキュメントのセキュリティに関する考慮事項のセクションにコンテンツを寄稿しました。特に、「セキュリティに関する考慮事項」セクションの一部のテキストは、作成者の許可を得て、進行中の作業案（draft-newman-mime-textpara-00）からそのままコピーされています。 Chris Newmanはさらに、エンコーディングの考慮事項のセクションにコンテンツを寄稿しました。 Dan Connollyは、text / xmlをいつ使用するかを議論するコンテンツを寄稿しました。 Ned FreedとDan Connollyとの議論は、テキストメディアタイプに対する著者の理解を深めるのに役立ちました。 Larry Masinterからのフィードバックは、メディアタイプ登録の問題を理解するのにも非常に役立ちました。
Members of the W3C XML Working Group and XML Special Interest group have made significant contributions to this document, and the authors would like to specially recognize James Clark, Martin Duerst, Rick Jelliffe, Gavin Nicol for their many thoughtful comments.
W3C XMLワーキンググループおよびXML Special Interestグループのメンバーは、このドキュメントに多大な貢献をしてくれました。著者は、James Clark、Martin Duerst、Rick Jelliffe、Gavin Nicolの多くの思慮深いコメントを特に認めたいと思います。
9 Addresses of Authors
著者の9つのアドレス
E. James Whitehead, Jr. Dept. of Information and Computer Science University of California, Irvine Irvine, CA 92697-3425
E.ジェームズホワイトヘッド、カリフォルニア大学アーバイン校情報およびコンピュータサイエンス学部、アーバインアーバイン、カリフォルニア州92697-3425
EMail: ejw@ics.uci.edu
Murata Makoto (Family Given) Fuji Xerox Information Systems, KSP 9A7, 2-1, Sakado 3-chome, Takatsu-ku, Kawasaki-shi, Kanagawa-ken, 213 Japan
むらた まこと （ふぁみｌｙ ぎゔぇん） ふじ ぇろｘ いんふぉｒまちおん Ｓｙｓてｍｓ、 ＫＳＰ ９あ７、 ２ー１、 さかど ３ーちょめ、 たかつーく、 かわさきーし、 かながわーけん、 ２１３ じゃぱん
EMail: murata@fxis.fujixerox.co.jp
10 Full Copyright Statement
10完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。