[要約] RFC 3470は、IETFプロトコル内でのXMLの使用に関するガイドラインです。その目的は、XMLの効果的な使用と実装の一貫性を確保することです。
Network Working Group S. Hollenbeck
Request for Comments: 3470 VeriSign, Inc.
BCP: 70 M. Rose
Category: Best Current Practice Dover Beach Consulting, Inc.
L. Masinter
Adobe Systems Incorporated
January 2003
Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols
IETFプロトコル内で拡張可能なマークアップ言語（XML）を使用するためのガイドライン
Status of this Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.
拡張可能なマークアップ言語（XML）は、データを構成するためのフレームワークです。主にドキュメントの構造化に焦点を当てたマークアップ言語である標準的な一般化マークアップ言語（SGML）から進化しましたが、XMLは構造化されたデータを表現するための広く使用されているメカニズムに進化しました。
There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols.
さまざまなインターネットプロトコルが開発されています。多くは、アプリケーションに関連する構造化されたデータの代表が必要です。表現方法としてのXMLの使用には多くの関心がありました。このドキュメントは、基本的なXMLの概念を説明し、XMLの使用におけるさまざまな代替案を分析し、IETF標準トラックプロトコル内でXMLを使用するためのガイドラインを提供します。
Table of Contents
目次
Conventions Used In This Document . . . . . . . . . . . . . . . . 2
1. Introduction and Overview . . . . . . . . . . . . . . . . . 2
1.1 Intended Audience. . . . . . . . . . . . . . . . . . . 3
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 XML Evolution . . . . . . . . . . . . . . . . . . . . 3
1.4 XML Users, Support Groups, and Additional
Information. . . . . . . . . . . . . . . . . . . . . . 4
2. XML Selection Considerations . . . . . . . . . . . . . . . . 4
3. XML Alternatives . . . . . . . . . . . . . . . . . . . . . . 5
4. XML Use Considerations and Recommendations . . . . . . . . . 7
4.1 XML Syntax and Well-Formedness . . . . . . . . . . . . 7
4.2 XML Information Set . . . . . . . . . . . . . . . . . 7
4.3 Syntactic Restrictions . . . . . . . . . . . . . . . . 8
4.4 XML Declarations . . . . . . . . . . . . . . . . . . . 9
4.5 XML Processing Instructions . . . . . . . . . . . . . 9
4.6 XML Comments . . . . . . . . . . . . . . . . . . . . . 10
4.7 Validity and Extensibility . . . . . . . . . . . . . . 10
4.8 Semantics as Well as Syntax. . . . . . . . . . . . . . 12
4.9 Namespaces . . . . . . . . . . . . . . . . . . . . . . 12
4.9.1 Namespaces and Attributes. . . . . . . . . . . . 13
4.10 Element and Attribute Design Considerations. . . . . . 14
4.11 Binary Data and Text with Control Characters . . . . . 16
4.12 Incremental Processing . . . . . . . . . . . . . . . . 16
4.13 Entity Declarations and Entity References . . . . . . 16
4.14 External References . . . . . . . . . . . . . . . . . 17
4.15 URI Processing . . . . . . . . . . . . . . . . . . . . 17
4.16 White Space . . . . . . . . . . . . . . . . . . . . . 18
4.17 Interaction with the IANA . . . . . . . . . . . . . . 19
5. Internationalization Considerations . . . . . . . . . . . . 19
5.1 Character Sets and Encodings . . . . . . . . . . . . . 19
5.2 Language Declaration . . . . . . . . . . . . . . . . . 20
5.3 Other Internationalization Considerations . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9. Normative References . . . . . . . . . . . . . . . . . . . . 22
10. Informative References . . . . . . . . . . . . . . . . . . . 23
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 28
Conventions Used In This Document
このドキュメントで使用されている規則
This document recommends, as policy, what specifications for Internet protocols -- and, in particular, IETF standards track protocol documents -- should include as normative language within them. The capitalized keywords "SHOULD", "MUST", "REQUIRED", etc. are used in the sense of how they would be used within other documents with the meanings as specified in BCP 14, RFC 2119 [1].
このドキュメントでは、ポリシーとして、インターネットプロトコルの仕様、特にIETF標準はプロトコルドキュメントを追跡することを推奨しています。大文字のキーワードは、「「必須」、「必須」などが、BCP 14、RFC 2119 [1]で指定されている意味を持つ他のドキュメント内でどのように使用されるかという意味で使用されます。
The Extensible Markup Language (XML, [8]) is a framework for structuring data. While it evolved from the Standard Generalized Markup Language (SGML, [30]) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data in protocol exchanges. See "XML in 10 points" [47] for an introduction to XML.
拡張可能なマークアップ言語（XML、[8]）は、データを構成するためのフレームワークです。主にドキュメントの構造化に焦点を当てたマークアップ言語である標準的な一般化マークアップ言語（SGML、[30]）から進化しましたが、XMLは、プロトコル交換で構造化されたデータを表現するための広く使用されているメカニズムに進化しました。XMLの紹介については、「10ポイントのXML」[47]を参照してください。
Many Internet protocol designers are considering using XML and XML fragments within the context of existing and new Internet protocols. This document is intended as a guide to XML usage and as IETF policy for standards track documents. Experienced XML practitioners will likely already be familiar with the background material here, but the guidelines are intended to be appropriate for those readers as well.
多くのインターネットプロトコル設計者は、既存のインターネットプロトコルと新しいインターネットプロトコルのコンテキスト内でXMLおよびXMLフラグメントを使用することを検討しています。このドキュメントは、XML使用法のガイドとして、および標準のIETFポリシーとしてドキュメントを追跡することを目的としています。経験豊富なXML開業医は、ここではすでに背景素材に精通している可能性がありますが、ガイドラインはこれらの読者にも適していることを目的としています。
This document is intended to give guidelines for the use of XML content within a larger protocol. The goal is not to suggest that XML is the "best" or "preferred" way to represent data; rather, the goal is to lay out the context for the use of XML within a protocol once other factors point to XML as a possible data representation solution. The Common Name Resolution Protocol (CNRP, [24]) is an example of a protocol that would be addressed by these guidelines if it were being newly defined. This document does not address the use of protocols like SMTP or HTTP to send XML documents as ordinary email or web content.
このドキュメントは、大規模なプロトコル内でXMLコンテンツを使用するためのガイドラインを提供することを目的としています。目標は、XMLがデータを表現するための「最良」または「好ましい」方法であることを示唆しないことです。むしろ、目標は、他の要因が可能なデータ表現ソリューションとしてXMLを指すと、プロトコル内でXMLを使用するためのコンテキストをレイアウトすることです。共通名の解像度プロトコル（CNRP、[24]）は、新たに定義されている場合、これらのガイドラインで対処されるプロトコルの例です。このドキュメントでは、SMTPやHTTPなどのプロトコルを使用して、XMLドキュメントを通常の電子メールまたはWebコンテンツとして送信することには対応していません。
There are a number of protocol frameworks already in use or under development which focus entirely on "XML protocol" -- the exclusive use of XML as the data representation in the protocol. For example, the World Wide Web Consortium (W3C) is developing an XML Protocol framework based on SOAP ([45] and [46]). The applicability of such protocols is not part of the scope of this document.
「XMLプロトコル」に完全に焦点を当てている多くのプロトコルフレームワークがすでに使用されている、または開発中にあります。これは、プロトコルのデータ表現としてXMLを排他的に使用しています。たとえば、World Wide Webコンソーシアム（W3C）は、SOAP（[45]および[46]）に基づいたXMLプロトコルフレームワークを開発しています。このようなプロトコルの適用性は、このドキュメントの範囲の一部ではありません。
In addition, there are higher-level representation frameworks, based on XML, that have been designed as carriers of certain classes of information; for example, the Resource Description Framework (RDF, [38]) is an XML-based representation for logical assertions. This document does not provide guidelines for the use of such frameworks.
さらに、特定のクラスの情報のキャリアとして設計されたXMLに基づく高レベルの表現フレームワークがあります。たとえば、リソース説明フレームワーク（RDF、[38]）は、論理アサーションのXMLベースの表現です。このドキュメントは、そのようなフレームワークを使用するためのガイドラインを提供していません。
XML 1.0 was originally published as a W3C recommendation in February 1998 [35], and was revised in a 2nd edition [8] in October 2000. Several additional facilities have also been defined that layer on the base specification. Although these additions are designed to be consistent with XML 1.0, they have varying levels of stability, consensus, and implementation. Accordingly, this document identifies the major evolutionary features of XML and makes suggestions as to the circumstances in which each feature should be used.
XML 1.0はもともと1998年2月にW3Cの推奨として公開され[35]、2000年10月に第2版[8]で改訂されました。これらの追加はXML 1.0と一致するように設計されていますが、安定性、コンセンサス、および実装のレベルがさまざまです。したがって、このドキュメントはXMLの主要な進化的特徴を識別し、各機能を使用する必要がある状況について提案します。
There are many XML support groups, with some devoted to the entire XML industry [51], some devoted to developers [52], some devoted to the business applications of XML [53], and many, many groups devoted to the use of XML in a particular context.
多くのXMLサポートグループがあり、一部はXML業界全体[51]、開発者に専念している[52]、XML [53]のビジネスアプリケーションに専念しているもの、およびXMLの使用に専念している多くのグループがあります。特定のコンテキストで。
It is beyond the scope of this document to provide a comprehensive list of referrals. Interested readers are directed to the three references above as starting points, as well as their favorite Internet search engine.
紹介の包括的なリストを提供することは、このドキュメントの範囲を超えています。興味のある読者は、上記の3つの参考文献と、お気に入りのインターネット検索エンジンに向けられています。
XML is a tool that provides a means towards an end. Choosing the right tool for a given task is an essential part of ensuring that the task can be completed in a satisfactory manner. This section describes factors to be aware of when considering XML as a tool for use in IETF protocols:
XMLは、目的に向けて手段を提供するツールです。特定のタスクに適したツールを選択することは、タスクを満足のいく方法で完了できるようにするための不可欠な部分です。このセクションでは、XMLをIETFプロトコルで使用するツールと見なす際に注意すべき要因について説明します。
1. XML is a meta-markup language that can be used to define markup languages for specific domains and problem spaces.
1. XMLは、特定のドメインと問題スペースのマークアップ言語を定義するために使用できるメタマークアップ言語です。
2. XML provides both logical structure and physical structure to describe data. Data framing is built-in.
2. XMLは、データを記述するために論理構造と物理構造の両方を提供します。データフレーミングは組み込まれています。
3. XML instances can be validated against the formal definition of a protocol specification.
3. XMLインスタンスは、プロトコル仕様の正式な定義に対して検証できます。
4. XML supports internationalization.
4. XMLは国際化をサポートします。
5. XML is extensible. Unlike some other markup languages (such as HTML), new tags (and thus new protocol elements) can be defined without requiring changes to XML itself.
5. XMLは拡張可能です。他のいくつかのマークアップ言語（HTMLなど）とは異なり、新しいタグ（したがって新しいプロトコル要素）は、XML自体に変更を必要とせずに定義できます。
6. XML is still evolving. The formal specifications are still being influenced and updated as use experience is gained and applied.
6. XMLはまだ進化しています。正式な仕様は、使用エクスペリエンスが得られ、適用されるにつれて、まだ影響を受け、更新されています。
7. XML does not provide native mechanisms to support detailed data typing. Additional mechanisms (such as those described in Section 4.7) are required to specify abstract protocol data types.
7. XMLは、詳細なデータタイピングをサポートするネイティブメカニズムを提供しません。抽象的なプロトコルデータ型を指定するには、追加のメカニズム（セクション4.7で説明されているようなものなど）が必要です。
8. XML is text-based, so XML fragments are easily created, edited, and managed using common utilities. Further, being text-based means it more readily supports incremental development, debugging, and logging. A simple "canned" XML fragment can be embedded within a program as a string constant, rather than having to be constructed.
8. XMLはテキストベースであるため、XMLフラグメントは一般的なユーティリティを使用して簡単に作成、編集、管理されます。さらに、テキストベースであることは、それがより容易に漸進的な開発、デバッグ、ロギングをサポートすることを意味します。単純な「缶詰」XMLフラグメントは、構築する必要があるのではなく、文字列定数としてプログラム内に埋め込むことができます。
9. Binary data has to be encoded into a text-based form to be represented in XML.
9. バイナリデータは、XMLで表現するためにテキストベースのフォームにエンコードする必要があります。
10. XML is verbose when compared with many other structured data representation languages. A representation with element extensibility and human readability typically requires more bits when compared to one optimized for efficient machine processing.
10. XMLは、他の多くの構造化されたデータ表現言語と比較すると、冗長です。要素の拡張性と人間の読み取り可能性を備えた表現は、通常、効率的な機械処理のために最適化されたものと比較すると、より多くのビットが必要です。
11. XML implementations are still relatively new. As designers and implementers gain experience, it is not uncommon to find defects in early and current products.
11. XMLの実装はまだ比較的新しいものです。設計者と実装者が経験を積むにつれて、初期および現在の製品に欠陥を見つけることは珍しくありません。
12. XML support is available in a large number of software development utilities, available in both open source and proprietary products.
12. XMLサポートは、多数のソフトウェア開発ユーティリティで利用でき、オープンソースと独自の製品の両方で利用できます。
13. XML processing speed can be an issue in some environments. XML processing can be slower because XML data streams may be larger than other representations, and the use of general purpose XML parsers will add a software layer with its own performance costs (though these costs can be reduced through consistent use of an optimized parser). In some situations, processing XML requires examining every byte of the entire XML data stream, with higher overhead than with representations where uninteresting segments can be skipped.
13. XML処理速度は、一部の環境で問題になる可能性があります。XMLデータストリームは他の表現よりも大きくなる可能性があるため、XML処理は遅くなる可能性があり、一般的な目的XMLパーサーの使用により、独自のパフォーマンスコストを備えたソフトウェアレイヤーが追加されます（ただし、これらのコストは最適化されたパーサーを一貫して使用することで削減できます）。状況によっては、XMLの処理では、XMLデータストリーム全体のすべてのバイトを調べる必要があります。面白くないセグメントをスキップできる表現よりもオーバーヘッドが高くなります。
This document focuses on guidelines for the use of XML. It is useful to consider why one might use XML as opposed to some other mechanism. This section considers some other commonly used representation mechanisms and compares XML to those alternatives.
このドキュメントは、XMLを使用するためのガイドラインに焦点を当てています。他のメカニズムとは対照的に、なぜXMLを使用するのかを考慮すると便利です。このセクションでは、他の一般的に使用される表現メカニズムを検討し、XMLをそれらの代替案と比較します。
For many fundamental protocols, the extensibility requirements are modest, and the performance requirements are high enough that fixed binary data blocks are the appropriate representation; mechanisms such as XML merely add bloat. RFC 3252 [23] describes a humorous example of XML as protocol bloat.
多くの基本的なプロトコルでは、拡張性要件は控えめであり、パフォーマンス要件は固定バイナリデータブロックが適切な表現であるほど十分に高いです。XMLなどのメカニズムは、単に膨らんだだけです。RFC 3252 [23]は、XMLのプロトコルブロートとしてのユーモラスな例を説明しています。
In addition, there are other representation and extensibility frameworks that have been used successfully within communication protocols. For example, Abstract Syntax Notation 1 (ASN.1) [28] along with the corresponding Basic Encoding Rules (BER, [29]) are part of the OSI communication protocol suite, and have been used in many subsequent communications standards (e.g., the ANSI Information Retrieval protocol [27] and the Simple Network Management Protocol (SNMP, [13]). The External Data Representation (XDR, [14]) and variations of it have been used in many other distributed network applications (e.g., the Network File System (NFS) protocol [22]). With some ASN.1 encoding types, data types are explicit in the representation, while with XDR, the data types of components are described externally as part of an interface specification.
さらに、通信プロトコル内で正常に使用されている他の表現および拡張性フレームワークがあります。たとえば、抽象的構文表記1（ASN.1）[28]と対応する基本エンコードルール（BER、[29]）はOSI通信プロトコルスイートの一部であり、その後の多くの通信基準（例えば、ANSI情報検索プロトコル[27]およびシンプルなネットワーク管理プロトコル（SNMP、[13]）。外部データ表現（XDR、[14]）とそのバリエーションは、他の多くの分散ネットワークアプリケーション（例えば、ネットワークファイルシステム（NFS）プロトコル[22]）。いくつかのasn.1エンコーディングタイプでは、データ型が表現で明示的であり、XDRでは、コンポーネントのデータ型がインターフェイス仕様の一部として外部から記述されています。
Many other protocols use data structures directly (without data encapsulation) by describing the data structure with Backus Normal Form (BNF, [25]); many IETF protocols use an Augmented Backus-Naur Form (ABNF, [16]). The Simple Mail Transfer Protocol (SMTP, [21]) is an example of a protocol specified using ABNF.
他の多くのプロトコルは、データ構造を（データカプセル化なしで）直接使用します（BNF、[25]）。多くのIETFプロトコルは、拡張されたバックスノーフォームを使用しています（ABNF、[16]）。Simple Mail転送プロトコル（SMTP、[21]）は、ABNFを使用して指定されたプロトコルの例です。
ASN.1, XDR, and BNF are described here as examples of alternatives to XML for use in IETF protocols. There are other alternatives, but a complete enumeration of all possible alternatives is beyond the scope of this document.
ASN.1、XDR、およびBNFは、IETFプロトコルで使用するためのXMLの代替案の例としてここで説明されています。他の選択肢はありますが、すべての可能な代替案の完全な列挙は、このドキュメントの範囲を超えています。
Other representation methods may differ from XML in several important ways:
他の表現方法は、いくつかの重要な方法でXMLと異なる場合があります。
Text Encoding and character sets: the character encoding used to represent a formal specification. XML defines a consistent character model based on the Universal Character Set (UCS, [31] and [33]), and requires that XML parsers accept at least UTF-8 [4] and UTF-16 [20], and allows for other encodings. While ASN.1 and XDR may carry strings in any encoding, there is no common mechanism for defining character encodings within them. Typically, ABNF definitions tend to be defined in terms of octets or characters in ASCII.
テキストエンコーディングと文字セット：正式な仕様を表すために使用される文字エンコード。XMLは、ユニバーサル文字セット（UCS、[31]および[33]）に基づいて一貫した文字モデルを定義し、XMLパーサーが少なくともUTF-8 [4]およびUTF-16 [20]を受け入れることを要求し、他のものを許可しますエンコーディング。ASN.1およびXDRは、エンコーディングに文字列を運ぶ場合がありますが、文字エンコーディングを定義するための一般的なメカニズムはありません。通常、ABNFの定義は、ASCIIのオクテットまたは文字の観点から定義される傾向があります。
Data Encoding: XML is defined as a sequence of characters, rather than a sequence of bytes. XML Schema [42] includes mechanisms for representing some data types (integer, date, array, etc.) but many binary data types are encoded in Base64 [15] or hexadecimal. ASN.1 and XDR have rich mechanisms for encoding a wide variety of data types.
データエンコーディング：XMLは、バイトのシーケンスではなく、文字のシーケンスとして定義されます。XMLスキーマ[42]には、いくつかのデータ型（整数、日付、配列など）を表すためのメカニズムが含まれていますが、多くのバイナリデータ型はBase64 [15]または16進数でエンコードされています。ASN.1とXDRには、さまざまなデータ型をエンコードするための豊富なメカニズムがあります。
Extensibility: XML has a rich extensibility model such that XML specifications can frequently be versioned independently. Specifications can be extended by adding new element names and attributes (if done compatibly); other extensions can be added by defining new XML namespaces [9], though there is no standard mechanism in XML to indicating whether or not new extensions are mandatory to recognize. Similarly, there are several techniques available to extend ASN.1 specifications. XDR specifications tend to not be independently extensible by different parties because the framing and data types are implicit and not self-describing. The extensibility of BNF-based protocol elements needs to be explicitly planned.
拡張性：XMLには、XML仕様を独立してバージョンすることができるように、豊富な拡張性モデルがあります。仕様は、新しい要素名と属性を追加することで拡張できます（互換性がある場合）。新しいXMLネームスペース[9]を定義することで他の拡張機能を追加できますが、XMLには新しい拡張機能が認識できるかどうかを示す標準メカニズムはありません。同様に、ASN.1仕様を拡張するためのいくつかの手法があります。XDRの仕様は、フレーミングとデータ型が暗黙的であり、自己記述的ではないため、異なる関係者によって独立して拡張できない傾向があります。BNFベースのプロトコル要素の拡張性を明示的に計画する必要があります。
Legibility of protocol elements: As noted above, XML is text-based, and thus carries the advantages (and disadvantages) of text-based protocol elements. Typically this is shared with (A)BNF-defined protocol elements. ASN.1 and XDR use binary encodings which are not easily human readable.
プロトコル要素の読みやすさ：上記のように、XMLはテキストベースであり、したがって、テキストベースのプロトコル要素の利点（および短所）が含まれます。通常、これは（a）BNF定義のプロトコル要素と共有されます。ASN.1とXDRは、人間が読みやすく簡単ではないバイナリエンコーディングを使用します。
This section notes several aspects of XML and makes recommendations for use. Since the 1998 publication of XML version 1 [35], an editorial second edition [8] was published in 2000; this section refers to the second edition.
このセクションには、XMLのいくつかの側面が表示され、使用に関する推奨事項があります。XMLバージョン1 [35]の1998年の出版以来、編集第2版[8]が2000年に公開されました。このセクションでは、第2版を参照してください。
XML [8] is defined in terms of a concrete syntax: a sequence of characters, using the characters "<", "=", "&", etc. as delimiters. An instance is XML if and only if it is well-formed, i.e., all character and markup data conforms to the structural rules defined in section 2.1 of [8].
XML [8]は、具体的な構文の観点から定義されます。文字のシーケンス「<」、 "="、 "＆"などをデリミターとして使用します。インスタンスはXMLである場合、つまり、[8]のセクション2.1で定義されている構造ルールに適合し、すべての文字データとマークアップデータが適合します。
Character and markup data that is not well-formed is not XML; well-formedness is the basis for syntactic compatibility with XML. Without well-formedness, all of the advantages of using XML disappear. For this reason, it is recommended that protocol specifications explicitly require XML well-formedness ("MUST be well-formed").
よく形成されていない文字およびマークアップデータはXMLではありません。整形式は、XMLとの構文互換性の基礎です。うまく形成されずに、XMLを使用することのすべての利点は消えます。このため、プロトコル仕様はXMLの整形式を明示的に必要とすることをお勧めします（「「よく形成する必要があります」）。
The IETF has a long-standing tradition of "be liberal in what you accept" that might seem to be at odds with this recommendation. Given that XML requires well-formedness, conforming XML parsers are intolerant of well-formedness errors. When specifying the handing of erroneous XML protocol elements, a protocol design must never recommend attempting to partially interpret non-well-formed instances of an element which is required to be XML. Reasonable behaviors in such a scenario could include attempting retransmission or aborting an in-progress session.
IETFには、この推奨事項と対立するように見える「あなたが受け入れるものにリベラルになる」という長年の伝統があります。XMLには整形式が必要であることを考えると、XMLパーサーの適合は、整形式エラーに不寛容です。誤ったXMLプロトコル要素の引き渡しを指定する場合、プロトコル設計は、XMLにする必要がある要素の非ウェル形成されたインスタンスを部分的に解釈することを試みることを決して推奨しないでください。このようなシナリオでの合理的な行動には、再送信の試みや進行中のセッションの中止が含まれます。
In addition to the concrete syntax of XML, there is an abstract model of XML content known as the "Information Set" (infoset) [37]. One might think of an XML parser as consuming the concrete syntax and producing an XML Information Set for further processing.
XMLの具体的な構文に加えて、「情報セット」（InfoSet）として知られるXMLコンテンツの抽象モデルがあります[37]。XMLパーサーは、具体的な構文を消費し、さらに処理するためのXML情報セットを生成すると考えるかもしれません。
In typical use of XML, the definition of allowable XML documents is often defined in terms of the Information Set of the XML and not the concrete syntax. The notion is that any syntactic representation which yielded the same information set would be treated equivalently.
XMLの典型的な使用では、許容可能なXMLドキュメントの定義は、具体的な構文ではなくXMLの情報セットの観点から定義されることがよくあります。概念は、同じ情報セットを生成した構文表現は同等に扱われるということです。
It some cases, protocols have been defined solely in terms of the XML Information Set, or by allowing other concrete syntax representations. However, since the context of XML embedded within other Internet protocols requires an unambiguous definition of the concrete syntax, defining an XML protocol element in terms of its XML Information Set alone and allowing other concrete syntax representations is out of scope for this document.
一部の場合、プロトコルはXML情報セットのみで、または他の具体的な構文表現を許可することによって定義されています。ただし、他のインターネットプロトコルに埋め込まれたXMLのコンテキストには、具体的な構文の明確な定義が必要であり、XML情報セットのみでXMLプロトコル要素を定義し、このドキュメントの他の具体的な構文表現を許可することは範囲外です。
In some circumstances a protocol designer may be tempted to define an XML-based protocol element as "XML", but at the same time imposing additional restrictions beyond those imposed by the XML recommendation itself -- for example, restricting the document character encoding, or avoiding CDATA sections, character entity references, imposing additional restrictions on use of white space, etc. The general category of restrictions addressed by this section are ones that would allow some but not other of the set of syntactic representations which have the same canonical representation according to canonical XML described in RFC 3076 [6].
状況によっては、プロトコルデザイナーがXMLベースのプロトコル要素を「XML」と定義するように誘惑される場合がありますが、XML推奨自体によって課されるものを超えて追加の制限を課します。CDATAセクションの回避、キャラクターエンティティ参照、空白の使用に関する追加の制限など。このセクションで扱われる制限の一般的なカテゴリは、同じ標準表現を持つ構文表現のセットの一部ではないが他のものではないものを許可するものではありません。RFC 3076 [6]に記載されている標準的なXMLへ。
Making these kinds of restrictions in a protocol definition may have the disadvantage that an implementer of the protocol may not be able to use an otherwise conforming XML processor to parse the XML-based protocol elements. In some cases, the motivation for subsetting XML is to allow implementers to build special-purpose processors that are lighter weight than a full-scale conforming XML processor. There are a number of good, conforming XML parsers that are small, fast, and free, while special-purpose processors have frequently been known to fail to handle some cases of legal XML syntax.
プロトコル定義でこれらの種類の制限を作成するには、プロトコルの実装者がXMLベースのプロトコル要素を解析するために適切な適合XMLプロセッサを使用できない可能性があるという欠点があります。場合によっては、サブセットXMLの動機は、実装者がフルスケールの適合XMLプロセッサよりも軽量の特殊な目的プロセッサを構築できるようにすることです。小さく、高速で、無料の優れた適合XMLパーサーがたくさんありますが、特別な目的のプロセッサは、法的XML構文のいくつかのケースを処理できないことが知られています。
In general, such syntactic restrictions should be avoided. In circumstances where restrictions on the variability of the syntactic representation of XML is necessary for one reason or another, designers should consider using "Canonical XML" [6] as the definition of the protocol element, since all such variability has been removed. Some specific issues are discussed in Section 4.4, Section 4.13, and Section 5.1 below.
一般に、このような構文制限は避けるべきです。XMLの構文表現の変動性の制限が何らかの理由で必要である状況では、設計者は、すべてのそのような変動性が削除されているため、プロトコル要素の定義として「Canonical XML」[6]を使用することを検討する必要があります。いくつかの特定の問題については、以下のセクション4.4、セクション4.13、およびセクション5.1で説明します。
An XML declaration (defined in section 2.8 of [8]) is a small header at the beginning of an XML data stream that indicates the XML version and the character encoding used. For example,
XML宣言（[8]のセクション2.8で定義）は、XMLバージョンと使用される文字エンコードを示すXMLデータストリームの先頭にある小さなヘッダーです。例えば、
<?xml version="1.0" encoding="UTF-8"?>
specifies the use of XML version 1 and UTF-8 character encoding.
XMLバージョン1およびUTF-8文字エンコードの使用を指定します。
In some uses of XML as an embedded protocol element, the XML used is a small fragment in a larger context, where the XML version is fixed at "1.0" and the character encoding is known to be "UTF-8". In those cases, an XML declaration might add extra overhead. In cases where the XML is a larger component which may find its way alone as an external entity body (transported as a MIME message, for example), the XML declaration is an important marker and is useful for reliability and extensibility. The XML declaration is also an important marker for character set/encoding (see Section 5.1), if any encoding other than UTF-8 or UTF-16 is used. Note that in the case of UTF-16, XML requires that the entity starts with a Byte Order Mark (BOM), which is not part of the character data. Note that the XML Declaration itself is not part of the XML document's Information Set.
XMLの埋め込みプロトコル要素としてのいくつかの使用では、使用されるXMLはより大きなコンテキストの小さなフラグメントであり、XMLバージョンは「1.0」に固定されており、文字エンコードは「UTF-8」であることが知られています。そのような場合、XML宣言はオーバーヘッドを追加する可能性があります。XMLがより大きなコンポーネントである場合、外部エンティティボディ（たとえばMIMEメッセージとして輸送）として単独でその方法を見つける可能性がある場合、XML宣言は重要なマーカーであり、信頼性と拡張性に役立ちます。XML宣言は、UTF-8またはUTF-16以外のエンコーディングが使用されている場合、文字セット/エンコードの重要なマーカーでもあります（セクション5.1を参照）。UTF-16の場合、XMLは、エンティティが文字データの一部ではないバイトオーダーマーク（BOM）で始まることを要求することに注意してください。XML宣言自体は、XMLドキュメントの情報セットの一部ではないことに注意してください。
Protocol specifications must be clear about use of XML declarations. XML [8] notes that "XML documents should begin with an XML declaration which specifies the version of XML being used." In general, an XML declaration should be encouraged ("SHOULD be present") and must always be allowed ("MAY be sent"). An XML declaration should be required in cases where, if allowed, the character encoding is anything other than UTF-8 or UTF-16.
プロトコル仕様は、XML宣言の使用について明確でなければなりません。XML [8]は、「XMLドキュメントが使用されているXMLのバージョンを指定するXML宣言から開始する必要がある」と述べています。一般に、XML宣言を奨励する必要があり（「存在する必要がある」）、常に許可されなければなりません（「送信される場合があります」）。許可されている場合、文字エンコードがUTF-8またはUTF-16以外のものである場合、XML宣言が必要である必要があります。
An XML processing instruction (defined in section 2.6 of [8]) is a component of an XML document that signals extra "out of band" information to the receiver; a common use of XML processing instructions are for document applications. For example, the XML2RFC application used to generate this document and described in RFC 2629 [19] supports a "table of contents" processing instruction:
XML処理命令（[8]のセクション2.6で定義）は、レシーバーに余分な「バンドから」情報を示すXMLドキュメントのコンポーネントです。XML処理手順の一般的な使用は、ドキュメントアプリケーション用です。たとえば、このドキュメントの生成に使用され、RFC 2629 [19]で説明されているXML2RFCアプリケーションは、「目次」処理命令をサポートしています。
<?rfc toc="yes"?>
As described in section 2.6 of [8], processing instructions are not part of the document's character data, but must be passed through to the application. As a consequence, it is recommended that processing instructions be ignored when encountered in normal protocol processing. It is thus also recommended that processing instructions not be used to define normative protocol data structures or extensions for the following reasons:
[8]のセクション2.6で説明されているように、処理命令はドキュメントの文字データの一部ではありませんが、アプリケーションに渡す必要があります。結果として、通常のプロトコル処理で遭遇した場合、処理手順を無視することをお勧めします。したがって、以下の理由により、規範的なプロトコルデータ構造または拡張機能を定義するために処理手順を使用しないこともお勧めします。
o Processing instructions are not namespace aware; there is no way to qualify a processing instruction target with a namespace.
o 処理手順は、名前空間が認識していません。名前空間で処理命令ターゲットを修飾する方法はありません。
o Processing instruction use can not be constrained by most schema languages,
o 処理命令の使用は、ほとんどのスキーマ言語で制約することはできません。
o Character references are not recognized within a processing instruction.
o 文字参照は、処理命令内で認識されません。
o Processing instructions don't have any XML-defined structure beyond the division between the target and everything else. This means that applications typically have to parse the content of the processing instruction in a system-dependent way; if the content was provided within an element instead, the structure could be expressed in the XML and the parsing could be done by the XML parser.
o 処理手順には、ターゲットと他のすべての間の分割を超えたXML定義構造はありません。これは、アプリケーションが通常、処理命令のコンテンツをシステム依存的に解析する必要があることを意味します。代わりにコンテンツが要素内で提供された場合、構造はXMLで表現でき、解析はXMLパーサーによって実行できます。
An XML comment (defined in section 2.5 of [8]) is a component of an XML document that provides descriptive information that is not part of the document's character data. XML comments, like comments used in programming languages, are often used to provide explanatory information in human-understandable terms. An example:
XMLコメント（[8]のセクション2.5で定義）は、ドキュメントの文字データの一部ではない説明情報を提供するXMLドキュメントのコンポーネントです。XMLコメントは、プログラミング言語で使用されているコメントと同様に、人間の理解可能な用語で説明情報を提供するために使用されることがよくあります。例：
<!-- This is a example comment. -->
XML comments can be ignored by conformant processors. As a consequence, it is strongly recommended that comments not be used to define normative protocol data structures or extensions. It is thus also strongly recommended that comments be ignored if encountered in normal protocol processing.
XMLのコメントは、コンフォーマントプロセッサによって無視できます。結果として、コメントは、規範的なプロトコルデータ構造または拡張機能を定義するために使用されないことを強くお勧めします。したがって、通常のプロトコル処理で発生した場合、コメントを無視することを強くお勧めします。
One important value of XML is that there are formal mechanisms for defining structural and data content constraints; these constrain the identity of elements or attributes or the values contained within them. There is more than one such formalism:
XMLの重要な値の1つは、構造およびデータコンテンツの制約を定義するための正式なメカニズムがあることです。これらは、要素または属性のアイデンティティ、またはそれらに含まれる値を制約します。そのような形式主義が複数あります：
o A "Document Type Definition" (DTD) is defined in section 2.8 of [8]; the concept came from a similar mechanism for SGML. There is significant experience with using DTDs, including in IETF protocols.
o 「ドキュメントタイプ定義」（DTD）は、[8]のセクション2.8で定義されています。この概念は、SGMLの同様のメカニズムから来ました。IETFプロトコルを含め、DTDを使用することで重要な経験があります。
o XML Schema (defined in [41] and [42]) provides additional features to allow a tighter and more precise specification of allowable protocol syntax and data type specifications.
o XMLスキーマ（[41]および[42]で定義）は、許容プロトコルの構文とデータ型仕様のより狭く、より正確な仕様を可能にする追加機能を提供します。
o There are also a number of other mechanisms for describing XML instance validity; these include, for example, Schematron [49] and RELAX NG [48]. Part 2 of the ISO/IEC Document Schema Definition Language (DSDL, [32]) standard is based on RELAX NG.
o XMLインスタンスの妥当性を説明するための他の多くのメカニズムもあります。これらには、たとえば、Schematron [49]およびRelax Ng [48]が含まれます。ISO/IECドキュメントスキーマ定義言語（DSDL、[32]）標準のパート2は、リラックスNgに基づいています。
There is ongoing discussion (and controversy) within the XML community on the use and applicability of various validity constraint mechanisms. The choice of tool depends on the needs for extensibility or for a formal language and mechanism for constraining permissible values and validating adherence to the constraints.
さまざまな妥当性制約メカニズムの使用と適用性について、XMLコミュニティ内で進行中の議論（および論争）があります。ツールの選択は、拡張性のニーズ、または許容値を制約し、制約の順守を検証するための正式な言語とメカニズムのニーズに依存します。
There are cases where protocols have defined validity using one or another validity mechanism, but the protocol definitions have not insisted that all corresponding protocol elements be "valid". The decision depends in part on the design for protocol extensibility. Each formalism has different ways of allowing for future extensions; in addition, a protocol design may have its own versioning mechanism, way of updating the schema, or pointing to a new one. For example, the use of XML namespaces (Section 4.9) with XML Schema allows other kinds of extensibility without compromising schema validity.
プロトコルが1つまたは別の妥当性メカニズムを使用して妥当性を定義している場合がありますが、プロトコルの定義は、すべての対応するプロトコル要素が「有効」であると主張していません。この決定は、プロトコルの拡張性の設計に一部依存しています。それぞれの形式主義には、将来の拡張を可能にするさまざまな方法があります。さらに、プロトコル設計には、独自のバージョン化メカニズム、スキーマを更新する方法、または新しいものを指す方法があります。たとえば、XMLスキーマを使用したXMLネームスペース（セクション4.9）を使用すると、スキーマの有効性を損なうことなく他の種類の拡張性が可能になります。
No matter what formalism is chosen, there are usually additional syntactic constraints, and inevitably additional semantic constraints, on the validity of XML elements that cannot be expressed in the formalism.
どんな形式主義が選択されていても、通常は、形式で表現できないXML要素の妥当性について、追加の構文制約と必然的に追加のセマンティック制約があります。
This document makes the following recommendations for the definition of protocols using XML:
このドキュメントは、XMLを使用したプロトコルの定義について次の推奨事項を作成します。
o Protocols should use an appropriate formalism for defining validity of XML protocol elements.
o プロトコルは、XMLプロトコル要素の妥当性を定義するために適切な形式主義を使用する必要があります。
o Protocols may or may not insist that all corresponding protocol elements be valid, according to the validity mechanism chosen; in either case, the extensibility design should be clear. What happens if the data is not valid?
o プロトコルは、選択された有効性メカニズムに従って、対応するすべてのプロトコル要素が有効であることを主張する場合と主張する場合があります。どちらの場合でも、拡張性設計は明確にする必要があります。データが有効でない場合はどうなりますか？
o As described in Section 3 there is no standard mechanism in XML for indicating whether or not new extensions are mandatory to recognize. XML-based protocol specifications should thus explicitly describe extension mechanisms and requirements to recognize or ignore extensions.
o セクション3で説明されているように、XMLには、新しい拡張機能が認識できるかどうかを示すための標準メカニズムはありません。したがって、XMLベースのプロトコル仕様は、拡張メカニズムと要件を明示的に説明して、拡張機能を認識または無視する必要があります。
An idealized model for XML processing might first check for well-formedness; if OK, apply the primary formalism and, if the instances "passes", apply the other constraints so that the entire set (or as much as is machine processable) can be checked at the same time.
XML処理の理想的なモデルは、最初に整形式をチェックする可能性があります。OKの場合は、一次形式を適用し、インスタンスが「合格」する場合、他の制約を適用して、セット全体（または機械加工可能なものと同じくらい）を同時に確認できるようにします。
However, it is reasonable to allow conforming implementations to avoid doing validation at run-time and rely instead on ad-hoc code to avoid the higher expense, for example, of schema validation, especially given that there will likely be additional hand-crafted semantic validation.
ただし、特に追加の手作りのセマンティックがある可能性が高いことを考えると、たとえばスキーマ検証など、ランタイムで検証を行い、代わりにアドホックコードに依存して代わりに依存して、適合実装を許可することが合理的です。検証。
While the definition of an XML protocol element using a validity formalism is useful, it is not sufficient. XML by itself does not supply semantics. Any document defining a protocol element with XML MUST also have sufficient prose in the document describing the semantics of whatever XML the document has elected to define.
妥当性形式を使用したXMLプロトコル要素の定義は有用ですが、十分ではありません。XML自体はセマンティクスを提供しません。XMLを使用してプロトコル要素を定義するドキュメントには、ドキュメントが定義することを選択したXMLのセマンティクスを説明するドキュメントに十分な散文も必要です。
XML namespaces, defined in [9], provide a means of assigning markup to a specific vocabulary. If two elements or attributes from different vocabularies have the same name, they can be distinguished unambiguously if they belong to different namespaces. Additionally, namespaces provide significant support for protocol extensibility as they can be defined, reused, and processed dynamically.
[9]で定義されているXMLネームスペースは、特定の語彙にマークアップを割り当てる手段を提供します。異なる語彙の2つの要素または属性が同じ名前を持っている場合、それらが異なる名前空間に属している場合、それらは明確に区別できます。さらに、名前空間は、動的に定義、再利用、および処理できるため、プロトコルの拡張性に大きなサポートを提供します。
Markup vocabulary collisions are very possible when namespaces are not used to separate and uniquely identify vocabularies. Protocol definitions should use existing XML namespaces where appropriate. When a new namespace is needed, the "namespace name" is a URI that is used to identify the namespace; it's also useful for that URI to point to a description of the namespace. Typically (and recommended practice in W3C) is to assign namespace names using persistent http URIs.
名前空間が語彙を分離して一意に識別するために使用されない場合、マークアップの語彙衝突は非常に可能です。プロトコル定義では、必要に応じて既存のXMLネームスペースを使用する必要があります。新しい名前空間が必要な場合、「名前空間名」は、名前空間を識別するために使用されるURIです。また、そのURIが名前空間の説明を指すことも役立ちます。通常（およびW3Cで推奨されるプラクティス）、永続的なHTTP URIを使用して名前空間名を割り当てることです。
In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. In lieu of such, other permanent URIs can be used, e.g., URNs in the IETF URN namespace (see [11] and [12]). Although there are instances of IETF specifications creating new URI schemes to define XML namespaces, this practice is strongly discouraged.
IETF Standards-Trackドキュメントの名前空間の場合、この目的に使用できるIETF独自のWebスペースの永続的な部分がある場合に役立ちます。そのようなことの代わりに、他の永久URIを使用できます。たとえば、IETF urnネームスペースのurns（[11]および[12]を参照）。XMLネームスペースを定義するための新しいURIスキームを作成するIETF仕様のインスタンスがありますが、このプラクティスは強く落胆しています。
There is a frequently misunderstood aspect of the relationship between unprefixed attributes and the default XML namespace - the natural assumption is that an unprefixed attribute is qualified by the default namespace, but this is not true. Rather, the unprefixed attribute belongs to no namespace at all. Thus, in the following example:
未定の属性とデフォルトのXMLネームスペースとの関係には頻繁に誤解されている側面があります。自然な仮定は、未定の属性がデフォルトの名前空間によって適格であるということですが、これは真実ではありません。むしろ、再固定されていない属性は、まったく名前のないものに属します。したがって、次の例では：
<ns1:fox a="xxx" ns1:b="qqq"
xmlns="http://example.org"/>
<fox a="xxx" ns1:b="qqq"
xmlns="http://example.org" xmlns:ns1="http://example.org"/>
the attribute "a" is in no namespace, while "ns1:b" is the same namespace as the containing element. A specific description of the relationship between default namespaces and attributes can be found in section 5.2 of [9]. The practical implication of the relationship between namespaces and attributes is that care must be taken to ensure that no element contains multiple attributes that have identical names or have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical.
属性「a」は名前空間なしで、「ns1：b」は含まれる要素と同じ名前空間です。デフォルトの名前空間と属性の関係の特定の説明は、[9]のセクション5.2に記載されています。名前空間と属性の関係の実際的な意味は、同じローカルパーツと同一の名前空間名にバインドされている名前の名前を持つ名前が同一の名前を持つ複数の属性を含む要素がないことを確認するために注意する必要があるということです。。
In XML applications, the choice between prefixed and non-prefixed attributes frequently is based on whether they always appear inside elements of the same namespace (in which case non-prefixed and thereby non-namespaced names are used) or whether it's required that they can be applied to elements in other arbitrary namespaces (in which case a prefixed name is used). Both situations occur in the XSLT [43] language: while attributes are unprefixed when they occur inside elements in the XSLT namespace, such as:
XMLアプリケーションでは、プレフィックスされた属性と非ペリックス属性を頻繁に頻繁に選択することは、それらが常に同じ名前空間の要素内に表示されるかどうか（この場合は非拡張されていないため、非ネームスケートの名前が使用されるかどうか、または彼らができるかどうかに基づいています。他の任意の名前空間の要素に適用されます（この場合、接頭辞名が使用されます）。どちらの状況もXSLT [43]言語で発生します。一方、属性はXSLT名空間の要素内で発生すると再定義されていません。
<xsl:value-of select="."/> they are prefixed when they appear in non-XSLT elements, such as the "xsl:version" attribute when using "literal result element stylesheets":
<xsl：value-of select = "
<html xsl:version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/TR/xhtml1/strict">
<head>
<title>Expense Report Summary</title>
</head>
<body>
<p>Total: <xsl:value-of select="exp-rep/total"/></p>
</body>
</html>
XML provides much flexibility in allowing a designer to use either elements, attributes, or element content to carry data. This section gives a flavor of the design considerations; there is much written about this in the XML literature. Consistent use of elements, attributes, and values is an important characteristic of a sound design.
XMLは、デザイナーが要素、属性、または要素コンテンツのいずれかを使用してデータをキャリーすることを許可する柔軟性を提供します。このセクションでは、設計上の考慮事項の風味を示します。XMLの文献にはこれについて多くの書かれています。要素、属性、および値の一貫した使用は、サウンドデザインの重要な特徴です。
Attributes are generally intended to contain meta-data that describes the element, and as such they are subject to the following restrictions:
属性は一般に、要素を説明するメタデータを含むことを目的としているため、次の制限の対象となります。
o Attributes are unordered,
o 属性は順序付けられていません、
o There can be no more than one instance of a given attribute within a given element, though an attribute may contain several values separated by white space ([8], section 2.3 and 3.3.1),
o 特定の要素内に特定の属性のインスタンスが1つしかない可能性がありますが、属性には空白によって区切られたいくつかの値が含まれる場合があります（[8]、セクション2.3および3.3.1）、
o Attribute values can have no internal XML markup for providing internal structure, and
o 属性値には、内部構造を提供するための内部XMLマークアップがありません。
o Attribute values are normalized ([8], section 3.3) before processing
o 属性値は、処理前に正規化されます（[8]、セクション3.3）
Consider the following example that describes an IP address using an attribute to describe the address value:
アドレス値を記述するために属性を使用してIPアドレスを記述する次の例を考えてみましょう。
<address addrType="ipv4">10.1.2.3</address> One might encode the same information using an <addrType> element instead of an "addrType" attribute:
<address addrtype = "ipv4"> 10.1.2.3 </address>「addrtype」属性の代わりに<addrtype>要素を使用して同じ情報をエンコードする場合があります。
<address>
<addrType>ipv4</addrType>
<value>10.1.2.3</value>
</address>
Another way of encoding the same information would be to use markup for the "addrType":
同じ情報をエンコードする別の方法は、「addrtype」にマークアップを使用することです。
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
Choosing between these designs involves tradeoffs concerning, among other considerations, the likely extensibility patterns and the ability of the formalism to constrain the values appropriately. In the first example, the attribute can be thought of as meta-data to the element which it modifies, and provides for a kind of "element extensibility". The third example allows for a different kind of extensibility: the "ipv4" space can be extended using other namespaces, and the <ipv4> element can include additional markup.
これらの設計を選択するには、他の考慮事項の中でも、値を適切に制約する形式主義の可能性が高い可能性のある拡張パターンと能力に関するトレードオフが含まれます。最初の例では、属性は、変更する要素に対するメタデータと考えることができ、一種の「要素の拡張性」を提供します。3番目の例では、異なる種類の拡張性が可能になります。「IPv4」空間を他の名前空間を使用して拡張でき、<IPv4>要素には追加のマークアップを含めることができます。
Many protocols include parameters that are selected from an enumerated set of values. Such enumerated values can be encoded as elements, attributes, or strings within element values. Any protocol design should consider how the set of enumerated values is to be extended: by revising the protocol, by including different values in different XML namespaces, or by establishing an IANA registry (as per RFC 2434 [18]). In addition, a common practice in XML is to use a URI as an XML attribute value or content.
多くのプロトコルには、列挙された値のセットから選択されたパラメーターが含まれています。このような列挙された値は、要素、属性、または要素値内の文字列としてエンコードできます。プロトコル設計は、列挙された値のセットをどのように拡張するかを考慮する必要があります。プロトコルを改訂する、異なるXMLネームスペースに異なる値を含めるか、IANAレジストリを確立することにより（RFC 2434 [18]）。さらに、XMLの一般的な慣行は、URIをXML属性値またはコンテンツとして使用することです。
Languages that describe syntactic validity (including XML Schema and DTDs) often provide a mechanism for specifying "default" values for an attribute. If an element does not specify a value for the attribute, then the "default" value is used. The use of default values for attributes is discouraged by this document. Although the use of this feature can reduce both the size and clutter of XML documents, it has a negative impact on software which doesn't know the document's validity constraints (e.g., for packet tracing or digital signature).
構文の妥当性（XMLスキーマとDTDを含む）を記述する言語は、多くの場合、属性の「デフォルト」値を指定するメカニズムを提供します。要素が属性の値を指定しない場合、「デフォルト」値が使用されます。属性のデフォルト値の使用は、このドキュメントによって落胆します。この機能を使用すると、XMLドキュメントのサイズとクラッターの両方を減らすことができますが、ドキュメントの有効性の制約を知らないソフトウェアにマイナスの影響を与えます（たとえば、パケットトレースやデジタル署名など）。
XML is defined as a character stream rather than a stream of octets. There is no way to embed raw binary data directly within an XML data stream; all binary data must be encoded as characters. There are a number of possible encodings; for example, XML Schema [42] defines encodings using decimal digits for integers, Base64 [15], or hexadecimal digits. In addition, binary data might be transmitted using some other communication channel, and referenced within the XML data itself using a URI.
XMLは、オクテットのストリームではなく、文字ストリームとして定義されます。XMLデータストリーム内に生のバイナリデータを直接埋め込む方法はありません。すべてのバイナリデータは文字としてエンコードする必要があります。可能なエンコーディングがいくつかあります。たとえば、XMLスキーマ[42]は、整数、base64 [15]、または16進数桁の小数桁を使用してエンコーディングを定義します。さらに、バイナリデータは他の通信チャネルを使用して送信され、URIを使用してXMLデータ自体内で参照される場合があります。
Protocols that need a container that can hold both structural data and large quantities of binary data should consider carefully whether XML is appropriate, since the Base64 and hex encodings are inefficient. Otherwise, protocols should use the mechanisms of XML Schema to represent binary data; the Base64 encoding is best for larger quantities of data.
構造データと大量のバイナリデータの両方を保持できるコンテナを必要とするプロトコルは、base64およびhexエンコーディングが非効率的であるため、XMLが適切かどうかを慎重に検討する必要があります。それ以外の場合、プロトコルはXMLスキーマのメカニズムを使用してバイナリデータを表す必要があります。Base64エンコーディングは、大量のデータに最適です。
XML does not allow "control" characters (0x00-0x1F) except for TAB (0x09), CR (0x0A), and LF (0x0D). They can not be specified even using character entity references. There is currently no common way of encoding them within what is otherwise ordinary text. This means that strings that might be considered "text" within an ABNF-defined protocol element may need to be treated as binary data within an XML representation, or some other encoding mechanism might need to be invented.
XMLは、タブ（0x09）、Cr（0x0a）、およびLF（0x0d）を除き、「制御」文字（0x00-0x1f）を許可しません。文字エンティティ参照を使用しても指定できません。現在、通常のテキストの中でそれらをエンコードする一般的な方法はありません。これは、ABNF定義のプロトコル要素内で「テキスト」と見なされる文字列をXML表現内のバイナリデータとして扱う必要がある場合、または他のエンコードメカニズムを発明する必要がある場合があることを意味します。
In some situations, it is possible to incrementally process an XML document as each tag is received; this is analogous to the process by which browsers incrementally render HTML pages as they are received. Note that incremental processing is difficult to implement if interspersed across multiple interactions. In other words, if a protocol requires incremental processing across both directions of a bidirectional stream, then it may place an unusual burden on protocol implementers.
状況によっては、各タグが受信されたときにXMLドキュメントを段階的に処理することができます。これは、ブラウザが受信したときにHTMLページを徐々にレンダリングするプロセスに類似しています。複数の相互作用に散在する場合、増分処理は実装が困難であることに注意してください。言い換えれば、プロトコルが双方向のストリームの両方向にわたって漸進的な処理を必要とする場合、プロトコルの実装者に異常な負担をかける可能性があります。
In addition to its role as a validity mechanism, an XML DTD provides a facility for "entity declarations" ([8], section 4.2). An entity declaration defines, in the DTD, a kind of macro capability where an "entity reference" may be used to call up and include the content of the entity declaration.
有効性メカニズムとしての役割に加えて、XML DTDは「エンティティ宣言」の施設を提供します（[8]、セクション4.2）。エンティティ宣言は、DTDでは、「エンティティリファレンス」を使用して、エンティティ宣言のコンテンツを呼び出して含めるために使用できるようにすることができます。
This feature adds complexity to XML processing, and seems more appropriate for use of XML in document processing than in data representation. As such, this document recommends avoiding entity declarations in protocol specifications.
この機能はXML処理に複雑さを追加し、データ表現よりもドキュメント処理でXMLの使用により適しているようです。そのため、このドキュメントでは、プロトコル仕様のエンティティ宣言を回避することを推奨しています。
On the other hand, there are five standard entity references built into XML: "&", "<", ">", "'", and """. XML also has the ability to write character data using numeric entity references (using the Unicode [33] value for the character). Entity references are normally expanded before the XML Information Set is computed. Restricting the use of these entity references would introduce an additional syntactic restriction (see Section 4.3) unnecessarily; these entity references should be allowed.
一方、XMLに組み込まれた5つの標準エンティティ参照があります： "＆amp;"、 "＆lt;"、 "＆gt;"、 "＆apos;"、および "＆quot;"。XMLには、数値エンティティ参照を使用して文字データを記述する機能もあります（文字のUnicode [33]値を使用）。XML情報セットが計算される前に、エンティティ参照は通常拡張されます。これらのエンティティ参照の使用を制限すると、追加の構文制限が導入されます（セクション4.3を参照）不必要に。これらのエンティティ参照を許可する必要があります。
When using XML in the context of a stateless protocol, be it the protocol itself (e.g., SOAP), or simply as content transferred by an existing protocol (e.g., XML/HTTP), care must be taken to not make the meaning of a message depend on information outside the message itself. XML provides external entities (see Section 4.13), which are an easy way to make the meaning of a message depend on something external. Using schema languages that can change the Infoset, like XML Schema, is another way.
ステートレスプロトコルのコンテキストでXMLを使用する場合、プロトコル自体（SOAPなど）、または単に既存のプロトコル（XML/HTTPなど）によって転送されるコンテンツとして、メッセージは、メッセージ自体の外側の情報に依存します。XMLは外部エンティティを提供します（セクション4.13を参照）。これは、メッセージの意味を外部の何かに依存させる簡単な方法です。XMLスキーマのように、インフォセットを変更できるスキーマ言語を使用することも別の方法です。
The XML Base specification [36] defines an attribute "xml:base" in the XML namespace that is intended to affect the "base" to be used for relative URI processing described in RFC 2396 [17]. The facilities of xml:base for controlling URI processing may be useful to protocol designers, but if xml:base is allowed the interaction with any other protocol facilities for establishing URI context must be specified clearly. Note that use of relative URIs in namespace declarations has been deprecated by the W3C; some specific issues with relative URIs in namespace declarations and canonical XML can be found in section 1.3 of RFC 3076 [6].
XMLベース仕様[36]は、RFC 2396 [17]で説明されている相対URI処理に使用される「ベース」に影響することを目的としたXMLネームスペースの属性「XML：ベース」を定義します。XML：URI処理を制御するためのベースの施設は、プロトコル設計者に役立つ場合がありますが、XML：ベースが許可されている場合、URIコンテキストを確立するための他のプロトコル施設との相互作用を明確に指定する必要があります。名前空間宣言での相対的なURIの使用は、W3Cによって非推奨されていることに注意してください。名前空間宣言と標準的なXMLの相対的なURIに関するいくつかの特定の問題は、RFC 3076のセクション1.3に記載されています[6]。
Note also that, in many cases, the term "URI" and the syntactic use of URIs within XML allows non-ASCII characters within URIs. For example, the XML Schema "anyURI" datatype ([42] section 3.2.17) allows for direct encoding of characters outside of the US-ASCII range. Most current IETF protocols and specifications do not allow this syntax. Protocol specifications should be clear about the range of characters specified, e.g., by adding a restriction to the range of characters allowed in the anyURI schema datatype, or by specifying that characters outside the US-ASCII range should be escaped when passed to older protocols or APIs.
また、多くの場合、「URI」という用語とXML内のURISの構文使用により、URIS内の非ASCII文字が許可されることに注意してください。たとえば、XMLスキーマ「Anyuri」データ型（[42]セクション3.2.17）により、US-ASCII範囲外の文字を直接エンコードできます。現在のほとんどのIETFプロトコルと仕様では、この構文は許可されていません。プロトコル仕様は、たとえば、Anyuriスキーマデータ型で許可されている文字の範囲に制限を追加するか、米国ASCII範囲外の文字を古いプロトコルまたは古いプロトコルに渡すと逃げる必要があることを指定することにより、指定された文字の範囲について明確にする必要があります。API。
XML's prescribed white space handling behavior can be a source of confusion between protocol designers and implementers. In XML instances all white space is considered significant and is by default visible to processing applications. Consider this example from Section 4.10:
XMLの処方された空白の取り扱い行動は、プロトコル設計者と実装者の間の混乱の原因となる可能性があります。XMLインスタンスでは、すべての空白が重要であると見なされ、デフォルトでは処理アプリケーションに表示されます。セクション4.10のこの例を考えてみましょう。
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
This fragment contains an <address> element and two child elements. It also contains white space for pretty-printing purposes:
このフラグメントには、<アドレス>要素と2つの子要素が含まれています。また、きれいな印刷目的のためにホワイトスペースが含まれています。
o at least three line separators, which will be converted by the XML processor to newline (U+000A) characters (see section 2.11 of [8]), and
o XMLプロセッサによってNewLine（U 000A）文字に変換される少なくとも3つのラインセパレータ（[8]のセクション2.11を参照）、および
o one or more white space characters prefixing the <addrType> and <value> elements, which an XML processor will make visible to software reading the instance.
o XMLプロセッサがインスタンスを読み取るソフトウェアに目に見えるようにする<addrtype>および<value>要素をプレフィックスする1つ以上のホワイトスペース文字。
Implementers might safely assume that they can ignore the white space in the example above, but white space used for pretty-printing can be a source of confusion in other situations. Consider a minor change to the <value> element:
実装者は、上記の例では白い空間を無視できると安全に想定するかもしれませんが、きれいな印刷に使用される空白は、他の状況では混乱の原因となる可能性があります。<値>要素への小さな変更を考えてみましょう：
<value> 10.1.2.3 </value>
<値> 10.1.2.3 </value>
where white space is found on both sides of the IP address. XML processors treat the white space surrounding "10.1.2.3" as an integral part of the <value> element. A failure to recognize this behavior can lead to confusion and errors in both design and implementation.
IPアドレスの両側に空白が見つかります。XMLプロセッサは、「10.1.2.3」を取り巻く空白を<値>要素の不可欠な部分として扱います。この動作を認識できないと、設計と実装の両方に混乱とエラーにつながる可能性があります。
All white space is considered significant in XML instances. As a consequence, it is recommended that protocol designers provide specific guidelines to address white space handling within protocols that use XML.
すべての空白は、XMLインスタンスで重要であると考えられています。結果として、プロトコル設計者は、XMLを使用するプロトコル内の空白の取り扱いに対処するための特定のガイドラインを提供することをお勧めします。
When XML is used in an IETF protocol there are multiple factors that might require IANA action, including:
IETFプロトコルでXMLが使用される場合、次のようなIANAアクションを必要とする可能性のある複数の要因があります。
o XML media types. A piece of XML in a protocol element is sometimes intrinsically bound to the protocol context in which it appears, and in particular might be directly derived from and/or input to protocol state-machine implementations. In cases where the XML content has no relevant meaning outside it's original protocol context, there is no reason to register a MIME type. When it is possible that XML content can be interpreted outside of its original context (such as when that XML content is being stored in a file system or tunneled over another protocol), then a MIME type can be registered to specify the specific format for the data and to provide a hint as to how it might be processed.
o XMLメディアタイプ。プロトコル要素内のXMLの一部は、それが表示されるプロトコルコンテキストに本質的に結合されることがあり、特にProtocol State-Machineの実装に直接導出され、および/または入力される場合があります。XMLコンテンツに関連する意味がない場合は、元のプロトコルのコンテキストである場合、MIMEタイプを登録する理由はありません。XMLコンテンツを元のコンテキストの外で解釈できる可能性がある場合（XMLコンテンツがファイルシステムに保存されている場合や別のプロトコル上にトンネリングされている場合など）、MIMEタイプを登録して、データと、それがどのように処理されるかについてのヒントを提供します。
If MIME labeling is needed, then the advice of RFC 3023 [5] applies. In particular, if the XML represents a new language or document type, a new MIME media type should be registered for the reasons described in RFC 3023 sections 7 and A.1. In situations where XML is used to encode generic structured data (e.g., a document-oriented application that involves combining XML with a stylesheet), "application/xml" might be appropriate ("MAY be used"). The "text/xml" media type is not recommended ("SHOULD NOT be used") because of issues involving display behavior and default charsets.
MIMEラベルが必要な場合は、RFC 3023 [5]のアドバイスが適用されます。特に、XMLが新しい言語またはドキュメントタイプを表す場合、RFC 3023セクション7およびA.1で説明されている理由により、新しいMIMEメディアタイプを登録する必要があります。XMLが一般的な構造化データをエンコードするために使用される状況では（例：XMLとStyleSheetを組み合わせたドキュメント指向アプリケーション）、「アプリケーション/XML」が適切である場合があります（「使用する場合があります」）。ディスプレイの動作とデフォルトの充電器を伴う問題のため、「テキスト/XML」メディアタイプは推奨されません（「使用しないでください」）。
o URI registration. There is an ongoing effort ([11], [12]) to create a URN namespace explicitly for defining URIs for namespace names and other URI-designated protocol elements for use within IETF standards track documents; it might also establish IETF policy for such use.
o URI登録。IETF標準トラックドキュメント内で使用するために、名前空間名およびその他のURI指定プロトコル要素のURIを定義するためのURN名前空間を明示的に作成するための継続的な取り組み（[11]、[12]）があります。また、このような使用のためにIETFポリシーを確立する可能性があります。
This section describes internationalization considerations for the use of XML to represent data in IETF protocols. In addition to the recommendations here, IETF policy on the use of character sets and languages described in RFC 2277 [3] also applies.
このセクションでは、IETFプロトコルのデータを表すためにXMLを使用するための国際化に関する考慮事項について説明します。ここでの推奨事項に加えて、RFC 2277 [3]に記載されている文字セットと言語の使用に関するIETFポリシーも適用されます。
IETF protocols frequently speak of the "character set" or "charset" of a string, which is used to denote both the character repertoire and the encoding used to represent sequences of characters as sequences of bytes.
IETFプロトコルは、文字列の「文字セット」または「charset」を頻繁に語ります。これは、文字レパートリーとバイトのシーケンスとしての文字のシーケンスを表すために使用されるエンコードの両方を示すために使用されます。
XML performs all character processing in terms of the Universal Character Set (UCS, [31] and [33]). XML requires all XML processors to support both the UTF-8 [4] and UTF-16 [20] encodings of UCS, although other encodings (charsets) compatible with UCS may be allowed. Documents and external parsed entities encoded in UTF-16 are required to begin with a Byte Order Mark ([8] section 4.3.3).
XMLは、ユニバーサル文字セット（UCS、[31]および[33]）に関してすべての文字処理を実行します。XMLは、UCSのUTF-8 [4]とUTF-16 [20]エンコーディングの両方をサポートするためにすべてのXMLプロセッサを必要としますが、UCSと互換性のある他のエンコーディング（charsets）が許可される場合があります。UTF-16でエンコードされたドキュメントと外部解析されたエンティティは、バイト順序マーク（[8]セクション4.3.3）から始める必要があります。
IETF policy [3] requires that the UTF-8 charset be allowed for all text.
IETFポリシー[3]では、すべてのテキストに対してUTF-8チャーセットを許可する必要があります。
This document requires that IETF protocols using XML allow for the UTF-8 encoding of XML data. Since conforming XML processors are mandated to also accept UTF-16 encoding, also allowing for UTF-16 encoding (with the mandated Byte Order Mark) is recommended. Some XML applications are using a Byte Order Mark with UTF-8 encoding, but this use should not be encouraged and isn't appropriate for XML embedded in other protocols.
このドキュメントでは、XMLを使用したIETFプロトコルにより、XMLデータのUTF-8エンコードが可能になることが必要です。XMLプロセッサの適合もUTF-16エンコーディングを受け入れることが義務付けられているため、UTF-16エンコーディング（義務付けられたバイトオーダーマーク付き）も推奨されます。一部のXMLアプリケーションは、UTF-8エンコードでバイト順序マークを使用していますが、この使用は奨励されるべきではなく、他のプロトコルに埋め込まれたXMLには適切ではありません。
Restricting XML data to only be expressed in UTF-8 is an additional syntactic restriction (see Section 4.3) which, depending on circumstances, might add additional implementation complexity. When encodings other than UTF-8 or UTF-16 are used, the encoding must be specified using an "encoding" attribute in the XML declaration (see Section 4.4), even if there might be other protocol mechanisms for designating the encoding.
XMLデータをUTF-8でのみ表現することを制限することは、状況に応じて、追加の実装の複雑さを追加する可能性のある追加の構文制限です（セクション4.3を参照）。UTF-8またはUTF-16以外のエンコーディングを使用する場合、エンコードを指定するための他のプロトコルメカニズムがある場合でも、XML宣言の「エンコード」属性（セクション4.4を参照）を使用してエンコードを指定する必要があります。
Text encapsulated in XML can be represented in many different human languages, and it is often useful to explicitly identify the language used to present the text. XML defines a special attribute in the "xml" namespace, xml:lang, that can be used to specify the language used to represent data in an XML document. The xml:lang attribute (which has to be explicitly declared for use within a DTD or XML Schema) and the values it can assume are defined in section 2.12 of [8].
XMLにカプセル化されたテキストは、さまざまな人間の言語で表現でき、テキストを提示するために使用される言語を明示的に識別することがしばしば役立ちます。XMLは、XMLドキュメントのデータを表すために使用される言語を指定するために使用できる「XML」名前空間XML：Langの特別な属性を定義します。XML：Lang属性（DTDまたはXMLスキーマ内で使用するために明示的に宣言される必要があります）と仮定できる値は、[8]のセクション2.12で定義されています。
It is strongly recommended that protocols representing data in a human language mandate use of an xml:lang attribute if the XML instance might be interpreted in language-dependent contexts.
XMLインスタンスが言語依存コンテキストで解釈される可能性がある場合、人間の言語の義務を表すプロトコル：lang属性：lang属性を強くお勧めします。
There are standard mechanisms in the typography of some human languages that can be difficult to represent using merely XML character string data types. For example, pronunciation clues can be provided using Ruby annotation [39], and embedding controls (such as those described in section 3.4 of [34]) or an XHTML [40] "dir" attribute can be used to note the proper display direction for bidirectional text.
いくつかの人間言語のタイポグラフィには、XML文字列データ型を使用するだけで表現することが困難な標準的なメカニズムがあります。たとえば、Ruby Annotation [39]を使用して発音の手がかりを提供し、コントロール（[34]のセクション3.4に記載されているものなど）またはXHTML [40] "dir"属性を使用して、適切な表示方向に注意することができます。双方向テキストの場合。
There are a number of tricky issues that can arise when using extended character sets with XML document formats. For example:
XMLドキュメント形式で拡張された文字セットを使用すると、多くのトリッキーな問題が発生する可能性があります。例えば：
o There are different ways of representing characters consisting of combining characters, and
o キャラクターを組み合わせることで構成される文字を表現するさまざまな方法があり、
o There has been some debate about whether URIs should be represented using a restricted US-ASCII subset or arbitrary Unicode (e.g., "URI character sequence" vs "original character sequence" in RFC 2396 [17]).
o RFC 2396 [17]の制限されたUS-ASCIIサブセットまたは任意のUnicode（例えば、「URI文字シーケンス」対オリジナル文字シーケンス」を使用してURIを表現すべきかどうかについて、いくつかの議論がありました。
Some of these issues are discussed, with recommendations, in the W3C's "Character Model for the World Wide Web" document [44].
これらの問題のいくつかは、W3Cの「World Wide Webのキャラクターモデル」ドキュメント[44]で推奨事項で議論されています。
It is strongly recommended that protocols representing data in a human language reuse existing mechanisms as needed to ensure proper display of human-legible text.
人間の言語のデータを表すプロトコルは、必要に応じて既存のメカニズムを再利用して、人間の軟テキストを適切に表示することを強くお勧めします。
This memo, per se, has no impact on the IANA. Section 4.17 notes some factors that might require IANA action when protocols using XML are defined.
このメモ自体は、IANAに影響を与えません。セクション4.17は、XMLを使用したプロトコルが定義されている場合にIANAアクションを必要とする可能性のあるいくつかの要因を示しています。
Network protocols face many different kinds of threats, including unintended disclosure, modification, and replay. Passive attacks, such as packet sniffing, allow an attacker to capture and view information intended for someone else. Captured data can be modified and replayed to the original intended recipient, with the recipient having no way to know that the information has been compromised, detect modifications, be assured of the sender's identity, or to confirm which protocol instance is legitimate.
ネットワークプロトコルは、意図しない開示、変更、リプレイなど、さまざまな種類の脅威に直面しています。パケットスニッフィングなどのパッシブ攻撃により、攻撃者は他の誰かを対象とした情報をキャプチャして表示できます。キャプチャされたデータは、元の意図された受信者に変更および再生できます。受信者は、情報が侵害されていることを知り、変更を検出したり、送信者の身元を保証したり、どのプロトコルインスタンスが合法であるかを確認する方法がありません。
Several security service options for XML are available to help mitigate these risks. Though XML does not include any built-in security services, other protocols and protocol layers provide services that can be used to protect XML protocols. XML encryption [10] provides privacy services to prevent unintended disclosure. Canonical XML [6] and XML digital signatures [7] provide integrity services to detect modification and authentication services to confirm the identity of the data source. Other IETF security protocols (e.g., the Transport Layer Security (TLS) protocol [2]) are also available to protect data and service endpoints as appropriate.
これらのリスクを軽減するために、XMLのセキュリティサービスオプションをいくつか利用できます。XMLには組み込みのセキュリティサービスは含まれていませんが、他のプロトコルとプロトコルレイヤーは、XMLプロトコルを保護するために使用できるサービスを提供します。XML暗号化[10]は、意図しない開示を防ぐためのプライバシーサービスを提供します。Canonical XML [6]およびXML Digital Signatures [7]は、データソースのIDを確認するための変更と認証サービスを検出するための整合性サービスを提供します。他のIETFセキュリティプロトコル（たとえば、輸送層セキュリティ（TLS）プロトコル[2]）も、必要に応じてデータとサービスのエンドポイントを保護するために利用できます。
Given the lack of security services in XML, it is imperative that protocol specifications mandate additional security services to counter common threats and attacks; the specific required services will depend on the protocol's threat model.
XMLのセキュリティサービスの不足を考えると、プロトコル仕様が一般的な脅威と攻撃に対抗するために追加のセキュリティサービスを義務付けることが不可欠です。特定の必要なサービスは、プロトコルの脅威モデルに依存します。
Experience has shown that code that parses network traffic is often a "soft target" for blackhats. Accordingly, implementers MUST take great care to ensure that their XML handling code is robust with respect to malformed XML, buffer overruns, misuse of entity declarations, and so on.
経験により、ネットワークトラフィックを解析するコードは、多くの場合、ブラックハットの「ソフトターゲット」であることが示されています。したがって、実装者は、不正なXML、バッファオーバーラン、エンティティ宣言の誤用などに関してXML処理コードが堅牢であることを確認するために細心の注意を払う必要があります。
XML mechanisms that follow external references (Section 4.14) may also expose an implementation to various threats by causing the implementation to access external resources automatically. It is important to disallow arbitrary access to such external references within XML data from untrusted sources. Many XML grammars define constructs using URIs for external references; in such cases, the same precautions must be taken.
外部参照（セクション4.14）に従うXMLメカニズムは、実装が外部リソースに自動的にアクセスすることにより、さまざまな脅威に実装を公開する場合があります。信頼されていないソースからのXMLデータ内のこのような外部参照への任意のアクセスを許可することが重要です。多くのXML文法は、外部参照にURIを使用して構成要素を定義しています。そのような場合、同じ予防策を講じなければなりません。
The authors would like to thank the following people who have provided significant contributions to the development of this document:
著者は、この文書の開発に多大な貢献を提供してくれた以下の人々に感謝したいと思います。
Mark Baker, Tim Berners-Lee, Tim Bray, James Clark, Josh Cohen, John Cowan, Alan Crouch, Martin Duerst, Jun Fujisawa, Christian Geuer-Pollmann, Yaron Goland, Graham Klyne, Dan Kohn, Rick Jeliffe, Chris Lilley, Murata Makoto, Michael Mealling, Jean-Jacques Moreau, Andrew Newton, Julian Reschke, Jonathan Rosenberg, Miles Sabin, Rich Salz, Peter Saint-Andre, Simon St Laurent, Margaret Wasserman, and Daniel Veillard.
マーク・ベイカー、ティム・バーナーズ・リー、ティム・ブレイ、ジェームズ・クラーク、ジョシュ・コーエン、ジョン・コーワン、アラン・クラウチ、マーティン・デュエルスト、藤崎jun、ヤロン・ゴーランド、グラハム・クライネ、ダン・コーン、リック・ジェリフ、クリス・リリー、ムラタマコト、マイケル・ミールリング、ジャン・ジャック・モロー、アンドリュー・ニュートン、ジュリアン・レシュケ、ジョナサン・ローゼンバーグ、マイルズ・サビン、リッチ・サルツ、ピーター・サン・アンドレ、サイモン・セント・ローレント、マーガレット・ワッサーマン、ダニエル・ベイラード。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[3] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[4] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[5] Murata、M.、St。Laurent、S。およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[6] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[6] Boyer、J。、「Canonical XMLバージョン1.0」、RFC 3076、2001年3月。
[7] Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[7] Eastlake、D.、Reagle、J。and D. Solo、「（拡張可能なマークアップ言語）XML-Signature構文と処理」、RFC 3275、2002年3月。
[8] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[8] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C。、およびE. Maler、「拡張可能なマークアップ言語（XML）1.0（第2版）」、W3C Rec-XML、2000年10月、<http：// www。w3.org/tr/rec-xml>。
[9] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[9] Bray、T.、Hollander、D。and A. layman、「XMLの名前空間」、W3C Rec-Xml-Names、1999年1月、<http://www.w3.org/tr/rec-xml-names>。
[10] Imamura, T., Dillaway, B., Schaad, J. and E. Simon, "XML Encryption Syntax and Processing", W3C REC-xmlenc-core, October 2001, <http://www.w3.org/TR/xmlenc-core/>.
[10] Imamura、T.、Dillaway、B.、Schaad、J。and E. Simon、 "xml暗号化構文と処理"、W3c Rec-Xmlenc-Core、2001年10月、<http://www.w3.org/tr/xmlenc-core/>。
[11] Masinter, L., Mealling, M., Klyne, G. and T. Hardie, "An IETF URN Sub-namespace for Registered Protocol Parameters", Work in Progress.
[11] Masinter、L.、Mealling、M.、Klyne、G。、およびT. Hardie、「登録されたプロトコルパラメーターのIETF URNサブネームスペース」、進行中の作業。
[12] Mealling, M., "The IETF XML Registry", Work in Progress.
[12] Mealling、M。、「IETF XMLレジストリ」、進行中の作業。
[13] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[13] Case、J.、Fedor、M.、Schoffstall、M。and C. Davin、「Simple Network Management Protocol（SNMP）」、STD 15、RFC 1157、1990年5月。
[14] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[14] Srinivasan、R。、「XDR：外部データ表現標準」、RFC 1832、1995年8月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[15] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[16] Crocker, D. (Ed.) and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[16] Crocker、D。（ed。）およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[17] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[17] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[18] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[19] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[19] Rose、M。、「XMLを使用したI-DSおよびRFCの執筆」、RFC 2629、1999年6月。
[20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[20] Hoffman、P。and F. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[21] Klensin, J. (Ed.), "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[21] Klensin、J。（ed。）、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[22] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000.
[22] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。and D. Noveck、「NFSバージョン4プロトコル」、RFC 3010、2000年12月。
[23] Kennedy, H., "Binary Lexical Octet Ad-hoc Transport", RFC 3252, April 2002.
[23] ケネディ、H。、「バイナリ語彙オクテットアドホック輸送」、RFC 3252、2002年4月。
[24] Popp, N., Mealling, M. and M. Moseley, "Common Name Resolution Protocol (CNRP)", RFC 3367, August 2002.
[24] Popp、N.、Mealling、M。and M. Moseley、「Common Name Resolution Protocol（CNRP）」、RFC 3367、2002年8月。
[25] Backus, J., "The syntax and semantics of the proposed international algebraic language of the Zurich ACM-GAMM conference", June 1959.
[25] Backus、J。、「チューリッヒACM-Gamm会議の提案された国際代数言語の構文とセマンティクス」、1959年6月。
[26] American National Standards Institute, "Code Extension Techniques for Use with the 7-bit Coded Character Set of American National Standard Code (ASCII) for Information Interchange", ANSI X3.41, FIPS PUB 35, 1974.
[26] American National Standards Institute、「情報交換のためのAmerican National Standard Code（ASCII）の7ビットコード化された文字セットで使用するコード拡張手法」、ANSI X3.41、Fips Pub 35、1974。
[27] American National Standards Institute, "Information Retrieval: Application Service Definition and Protocol Specification", ANSI Z39.50, ISO Standard 23950, 1995.
[27] American National Standards Institute、「情報検索：アプリケーションサービス定義とプロトコル仕様」、ANSI Z39.50、ISO Standard 23950、1995。
[28] International Organization for Standardization, "Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", ISO Standard 8824, December 1990.
[28] 国際標準化機関、「情報処理システム - オープンシステムの相互接続 - 抽象的構文表記の仕様（ASN.1）」、ISO Standard 8824、1990年12月。
[29] International Organization for Standardization, "Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", ISO Standard 8825, December 1990.
[29] 国際標準化機関、「情報処理システム - オープンシステムの相互接続 - 抽象的構文表記1（ASN.1）の基本エンコードルールの仕様」、ISO Standard 8825、1990年12月。
[30] International Organization for Standardization, "Information processing - Text and office systems - Standard Generalized Markup Language (SGML)", ISO Standard 8879, 1988.
[30] 国際標準化機関、「情報処理 - テキストおよびオフィスシステム - 標準的な一般化マークアップ言語（SGML）」、ISO Standard 8879、1988。
[31] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993.
[31] 国際標準化機関、「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS） - パート1：アーキテクチャと基本的な多言語平面」、ISO Standard 10646-1、1993年5月。
[32] International Organization for Standardization, "DSDL Part 0 - Overview", December 2001, <http://www.jtc1.org/FTP/Public/SC34/ DOCREG/0275.htm>.
[32] 国際標準化機関、「DSDLパート0-概要」、2001年12月、<http://www.jtc1.org/ftp/public/sc34/ docreg/0275.htm>。
[33] Unicode Consortium, "The Unicode Standard, as it may from time to time be revised or amended", March 2002, <http:// www.unicode.org/unicode/standard/standard.html>.
[33] Unicode Consortium、「Unicode Standardは、時々改訂または修正される可能性がある」、2002年3月<http：// www.unicode.org/unicode/standard/standard.html>。
[34] Duerst, M. and A. Freytag, "Unicode in XML and other Markup Languages", February 2002, <http://www.w3.org/TR/unicode-xml/>.
[34] Duerst、M。and A. Freytag、「XMLおよびその他のマークアップ言語のUnicode」、2002年2月、<http://www.w3.org/tr/unicode-xml/>。
[35] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", W3C REC-xml-1998, February 1998, <http:// www.w3.org/TR/1998/REC-xml-19980210/>.
[35] Bray、T.、Paoli、J。and C. Sperberg-Mcqueen、「Extensible Markup Language（XML）1.0」、W3C REC-XML-1998、1998年2月、<http：// www.w3.org/tr/1998/rec-xml-1980210/>。
[36] Marsh, J., "XML Base", W3C REC-xmlbase, June 2001, <http:// www.w3.org/TR/xmlbase/>.
[36] Marsh、J。、「XML Base」、W3C Rec-XmlBase、2001年6月、<http：// www.w3.org/tr/xmlbase/>。
[37] Cowan, J. and R. Tobin, "XML Information Set", W3C REC-infoset, October 2001, <http://www.w3.org/TR/xml-infoset/>.
[37] Cowan、J。およびR. Tobin、「XML Information Set」、W3C Rec-Infoset、2001年10月、<http://www.w3.org/tr/xml-infoset/>。
[38] Lassila, O. and R. Swick, "Resource Description Framework (RDF) Model and Syntax Specification", W3C REC-rdf-syntax, February 1999, <http://www.w3.org/TR/REC-rdf-syntax>.
[38] Lassila、O。and R. Swick、「リソース説明フレームワーク（RDF）モデルと構文仕様」、W3C Rec-RDF-Syntax、1999年2月、<http://www.w3.org/tr/rec-rdf-syntax>。
[39] Suignard, M., Ishikawa, M., Duerst, M. and T. Texin, "Ruby Annotation", W3C REC-RUBY, May 2001, <http://www.w3.org/TR/ ruby/>.
[39] Suignard、M.、Ishikawa、M.、Duerst、M. and T. Texin、「Ruby Annotation」、W3C Rec-Ruby、2001年5月、<http://www.w3.org/tr/ ruby/>。
[40] Pemberton, S., "XHTML 1.0: The Extensible HyperText Markup Language", W3C REC-XHTML, January 2000, <http://www.w3.org/TR/ xhtml1/>.
[40] ペンバートン、S。、「XHTML 1.0：拡張可能なハイパーテキストマークアップ言語」、W3C REC-XHTML、2000年1月、<http://www.w3.org/tr/ xhtml1/>。
[41] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[41] Thompson、H.、Beech、D.、Maloney、M. and N. Mendelsohn、「XML Schema Part 1：Structures」、W3C Rec-Xmlschema-1、2001年5月、<http://www.w3.org/tr/xmlschema-1/>。
[42] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
[42] Biron、P。and A. Malhotra、「XML Schema Part 2：DataTypes」、W3C REC-XMLSCHEMA-2、2001年5月、<http://www.w3.org/tr/xmlschema-2/>。
[43] Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C REC-xslt, November 1999, <http://www.w3.org/TR/xslt>.
[43] クラーク、J。、「XSL変換（XSLT）バージョン1.0」、W3C REC-XSLT、1999年11月、<http://www.w3.org/tr/xslt>。
[44] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., Freytag, A. and T. Texin, "Character Model for the World Wide Web 1.0", April 2002, <http://www.w3.org/TR/charmod/>.
[44] Duerst、M.、Yergeau、F.、Ishida、R.、Wolf、M.、Freytag、A。、およびT. Texin、「World Wide Web 1.0のキャラクターモデル」、2002年4月、<http：// www。w3.org/tr/charmod/>。
[45] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", June 2002, <http://www.w3.org/TR/soap12-part1/>.
[45] Gudgin、M.、Hadley、M.、Moreau、JJ。H. Nielsen、「SOAPバージョン1.2パート1：メッセージングフレームワーク」、2002年6月、<http://www.w3.org/tr/soap12-part1/>。
[46] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", June 2002, <http://www.w3.org/TR/soap12-part2/>.
[46] Gudgin、M.、Hadley、M.、Moreau、JJ。H. Nielsen、「SOAPバージョン1.2パート2：付属品」、2002年6月、<http://www.w3.org/tr/soap12-part2/>。
[47] W3C Communications Team, "XML in 10 points", November 2001, <http://www.w3.org/XML/1999/XML-in-10-points>.
[47] W3C Communications Team、「XML in 10 Points」、2001年11月、<http://www.w3.org/xml/1999/xml-in-10ポイント>。
[48] OASIS Technical Committee: RELAX NG, "RELAX NG Specification", December 2001, <http://www.oasis-open.org/committees/relax-ng/ spec-20011203.html>.
[48] OASIS技術委員会：リラックスNG、「NG仕様をリラックス」、2001年12月、<http://www.oasis-open.org/committees/relax-ng/ Spec-20011203.html>。
[49] Jelliffe, R., "The Schematron", November 2001, <http:// www.ascc.net/xml/schematron/>.
[49] Jelliffe、R。、「Schematron」、2001年11月、<http：// www.ascc.net/xml/schematron/>。
URIs
ウリス
[50] <http://www.imc.org/ietf-xml-use/>
[51] <http://xml.org/>
[52] <http://xmlhack.com/>
[53] <http://oasis-open.org/>
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 US
Phone: +1 703 948 3257
EMail: shollenbeck@verisign.com
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
マーシャルT.ローズドーバービーチコンサルティング、Inc。POB 255268サクラメント、CA 95865-5268 US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Larry Masinter Adobe Systems Incorporated Mail Stop W14 345 Park Ave. San Jose, CA 95110 US
Larry Masinter Adobe Systems Incorporated Mail Stop W14 345 Park Ave. San Jose、CA 95110 US
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。