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
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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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標準プロトコル文書を追跡する - それらの中規範言語として含める必要があります。大文字のキーワード「SHOULD」、「MUST」、「REQUIRED」、などが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]）は、新たに定義されていた場合は、これらのガイドラインによって対処されるプロトコルの一例です。この文書では、通常の電子メールやWebコンテンツとしてのXML文書を送信するためにSMTPやHTTPなどのプロトコルの使用には対応していません。
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プロトコル」に完全に焦点を当て、既に使用中または開発中のプロトコルのフレームワークがいくつかあります。例えば、ワールドワイドウェブコンソーシアム（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は、[8] 2000年10月にいくつかの追加機能も基本仕様上の層を定義されている、もともと1998年2月[35]にW3C勧告として公開され、第2版で改訂されました。これらの追加は、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のビジネスアプリケーションへの献身的ないくつかは、[53]、[52]、全体のXML業界への献身的ないくつか[51]で、であり、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は終わりに向かっての手段を提供するツールです。与えられたタスクのための適切なツールを選択すると、タスクが良好に完了できることを保証する重要な部分です。このセクションでは、IETFプロトコルで使用するためのツールとしてXMLを検討する際に考慮する必要がある要因について説明します。
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インスタンスは、プロトコル仕様の正式な定義に照らして検証することができます。
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を使用するためのガイドラインに焦点を当てています。いくつかの他のメカニズムとは対照的に、1は、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.
また、通信プロトコル内で首尾よく使用されてきた他の表現と拡張フレームワークがあります。例えば、対応する基本符号化規則（BER、[29]）と共に、抽象構文記法1（ASN.1）[28] OSI通信プロトコルスイートの一部であり、多くの後続の通信規格（例えば、中に使用されていますANSI情報検索プロトコル[27]と簡易ネットワーク管理プロトコル（SNMP、[13]）。外部データ表現（XDR、[14]）とそのバリエーションは、他の多くの分散ネットワークアプリケーション（例えば、で使用されていますネットワークファイルシステム（NFS）プロトコル[22]）。XDRと、コンポーネントのデータ・タイプは、インタフェース仕様の一部として外部記述されている間、いくつかのASN.1符号化タイプでは、データ型は、表現に明示されています。
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]）を使用します。簡易メール転送プロトコル（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]、[8] 2000年に出版された編集第二版1998年出版以来。このセクションでは、第二版を指します。
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].
「<」、「=」、「＆」、等区切り文字として文字を使用して、文字のシーケンス：[8] XMLは、具体的な構文で定義されています。インスタンスは、それが十分に形成されている場合にのみと、すなわち、すべての文字とマークアップデータのセクション2.1で定義された構造の規則に準拠している場合、XMLである[8]。
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の具体的な構文に加えて、「情報セット」（情報セット）[37]として知られているXMLコンテンツの抽象モデルがあります。一つは、具体的な構文を消費し、さらに処理するために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に記載さカノニカルXML〜[6]。
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の構文表現の変動に制限が一つの理由または別のために必要である状況において、設計者は、すべてのそのような変動が除去されているので、プロトコル要素の定義として[6]「標準的なXML」を使用して検討すべきです。いくつかの具体的な問題は、セクション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,
（[8]のセクション2.8で定義された）XML宣言は、XMLのバージョンと使用される文字エンコーディングを示すXMLデータストリームの初めに小さなヘッダです。例えば、
<?xml version="1.0" encoding="UTF-8"?>
<？xml version = "1.0" エンコード= "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宣言は、重要なマーカーであり、信頼性および拡張性のために有用です。 UTF-8やUTF-16以外のエンコーディングが使用される場合、XML宣言は、（セクション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宣言が奨励されるべきである（「存在であるべきである」）と、常に（「送るかもしれません」）が許可されなければなりません。 XML宣言が許可されている場合は、文字エンコーディングがUTF-8またはUTF-16以外のもので、場合によっては必要とされなければなりません。
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:
（[8]のセクション2.6で定義された）XMLの処理命令は、受信機に、「帯域外」情報を余分信号XML文書の構成要素です。 XML処理命令の一般的な用途は、文書の用途のためのものです。例えば、XML2RFCアプリケーションがこの文書を生成するために使用され、RFC 2629に記載され[19]処理命令「の内容のテーブル」をサポートしています。
<?rfc toc="yes"?>
<？RFCのTOC = "はい"？>
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:
セクション2.6で説明したように、[8]、処理命令は、文書の文字データの一部ではないが、アプリケーションに渡さなければなりません。その結果、通常のプロトコル処理に遭遇した場合の処理命令を無視することをお勧めします。したがって、処理の手順は、次のような理由から規範プロトコルデータ構造や機能拡張を定義するために使用されていないことをお勧めします。
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:
（[8]のセクション2.5で定義された）XMLコメントは、文書の文字データの一部ではない記述的情報を提供する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の一つの重要な値は、構造とデータコンテンツの制約を定義するための正式なメカニズムがあるということです。これらは、要素や属性やその中に含まれる値のIDを制約します。以上のように定式化があります：
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.
「文書型定義」（DTD）O [8]のセクション2.8で定義されています。コンセプトは、SGMLのための同様のメカニズムから来ました。 、DTDを使用してIETFプロトコルに含むと豊富な経験があります。
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]とNG [48] RELAX。 ISO / IEC文書スキーマ定義言語の一部2（DSDL、[32]）規格は、RELAX 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.
第3節で説明したようにoを新しい拡張を認識することは必須であるか否かを示すための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名前空間は、特定の語彙にマークアップを割り当てる手段を提供します。異なる語彙からの二つの要素や属性の名前が同じである場合、それらは異なる名前空間に属している場合、彼らは明確に区別することができます。彼らは、定義された再利用、および動的に処理することができますように加え、名前空間は、プロトコルの拡張のための重要なサポートを提供しています。
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自身のWebスペースのいくつかの永続的な部分があった場合にはIETF標準トラック文書内の名前空間の場合には、それが有用であろう。使用することができるような、他の永久的なURIの代わりに、例えば、IETF URN名前空間内のURNは（[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"/>
<NS1：キツネ、A = "XXX" NS1：B = "QQQ" のxmlns = "http://example.org" /> <キツネ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.
「：B NS1は、」含んでいる要素と同じ名前空間がある一方、属性が「」、ノー名前空間にあります。デフォルト名前空間と属性との関係の具体的な説明は、[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：価値の選択= /「」>彼らのような非XSLT要素に表示される場合、それらは接頭辞 『XSL：バージョン』属性を 『リテラル結果要素のスタイルシート』を使用する場合：
<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>
<HTMLのxsl：バージョン= "1.0" のxmlns：XSL = "http://www.w3.org/1999/XSL/Transform" のxmlns = "http://www.w3.org/TR/xhtml1/strict"> <ヘッド> <タイトル>経費報告書の要約</ TITLE> </ HEAD> <BODY> <P>総ます。<xsl：価値の= "EXP-REP /合計" /選択> </ 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),
属性は空白で区切られたいくつかの値（[8]、セクション2.3および3.3.1）を含んでいてもよいけれども、O、指定された要素内の指定された属性のない複数のインスタンスが存在しないことができ、
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>
<アドレスADDRTYPE = "IPv4の"> 10.1.2.3 </アドレス>
One might encode the same information using an <addrType> element instead of an "addrType" attribute:
一つは、代わりに「ADDRTYPE」属性の<ADDRTYPE>要素を使用して同じ情報を符号化するかもしれません。
<address> <addrType>ipv4</addrType> <value>10.1.2.3</value> </address>
<アドレス> <ADDRTYPE>のIPv4 </ ADDRTYPE> <値> 10.1.2.3 </ value>の</アドレス>
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>
<アドレス> <ADDRTYPE> <はIPv4 /> </ ADDRTYPE> <値> 10.1.2.3 </ value>の</アドレス>
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での一般的な方法は、XML属性値やコンテンツとしてURIを使用することです。
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と進エンコーディングは非効率的であるので、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は、TAB（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.
"＆QUOT;" "＆＃038;"、 "＆LT;"、 "＆GT;"、 "＆APOS"、および：一方、XMLに組み込まれた5つの標準エンティティの参照があります。 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].
RFC 2396 [17]に記載の相対URIの処理に使用される「塩基」に影響することが意図されているXML名前空間に：XMLベースの仕様[36]属性「ベースXML」を定義します。 XMLの設備：URI処理を制御するためのベースは、プロトコル設計者に有用であるかもしれないが、XML場合：ベースはURIコンテキストを確立するための他のプロトコル設備との対話を許可されて明確に指定しなければなりません。 W3Cによって廃止されました名前空間宣言では相対URIの使用を注意してください。名前空間宣言とカノニカル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内のURIの構文を使用は、URIの中に非ASCII文字を可能にする、また、その注意してください。例えば、XMLスキーマ「anyURIの」データ型（[42]セクション3.2.17）は、US-ASCIIの範囲外の文字を直接符号化することを可能にします。現在のほとんどのIETFプロトコルと仕様はこの構文を許可していません。プロトコル仕様は、例えば、anyURIのスキーマのデータ型に使用できる文字の範囲に制限を加えることで、以前のプロトコルに渡されたとき、またはUS-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>
<アドレス> <ADDRTYPE> <はIPv4 /> </ ADDRTYPE> <値> 10.1.2.3 </ value>の</アドレス>
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
改行（U + 000A）文字にXMLプロセッサによって変換される、少なくとも3枚のラインセパレータ、（[8]のセクション2.11を参照）O、及び
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プレフィックス一つ以上の空白文字<ADDRTYPE>とXMLプロセッサは、インスタンスを読み取るソフトウェアに見えるようになります。<値>要素。
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:
：XMLは、IETFプロトコルで使用される場合など、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.
XMLメディアタイプO。プロトコル要素におけるXMLの部分は時々本質的にそれが表示されるプロトコルコンテキストにバインドされ、特に、直接プロトコル状態マシンの実装及び/又は入力から導出されるかもしれません。 XMLコンテンツは、それが本来のプロトコルコンテキストの外に該当する意味を持っていない場合には、MIMEタイプを登録する理由はありません。 XMLコンテンツがMIMEタイプのための特定のフォーマットを指定するために登録することができ、次いで、（例えば、そのXMLコンテンツをファイルシステムに格納された、または別のプロトコルを介してトンネリングされているときのように）元のコンテキストの外で解釈されることが可能である場合それが処理されるかもしれない方法についてのヒントを提供するためのデータと。
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は、新しい言語や文書タイプを表す場合、特に、新しいMIMEメディアタイプは、RFC 3023のセクション7とA.1に記載の理由のために登録されるべきです。 XMLは汎用構造化データを符号化するために使用されている状況では（例えば、スタイルシートとXMLを組み合わせることを含むドキュメント指向アプリケーション）、「アプリケーション/ XMLは、」（「が使用されるかもしれません」）適切であるかもしれません。 「text / 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.
URI登録O。名前空間名と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で説明しているキャラクタ・セットと言語の使用に関するIETF方針は、[3]にも適用されます。
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プロトコルは、しばしば「文字セット」または文字レパートリとバイトのシーケンスとして文字の配列を表すために使用される符号化の両方を示すために使用される文字列の「文字セット」と話します。
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は、[4]とUTF-16 UCSの[20]エンコード、UCSと互換性の他のエンコーディング（文字セット）を許可してもよいがUTF-8の両方をサポートするために、すべてのXMLプロセッサを必要とします。 UTF-16でエンコードされた文書および外部解析エンティティがバイトオーダーマーク（[8]のセクション4.3.3）で開始する必要があります。
IETF policy [3] requires that the UTF-8 charset be allowed for all text.
[3] IETF方針は、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.
のみUTF-8で発現されることがXMLデータを制限することは、状況に応じて、追加の実装の複雑さを追加する可能性があり、追加の構文制限（4.3節を参照します）。 UTF-8やUTF-16以外のエンコーディングが使用される場合、符号化は、符号化を指定するための他のプロトコルメカニズムがあるかもしれないとしても、（セクション4.4を参照）XML宣言で「符号化」属性を使用して指定されなければなりません。
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にカプセル化されたテキストは、さまざまな人間の言語で表現することができ、明示的にテキストを提示するために使用される言語を識別するのに便利です。 LANG、XML文書内のデータを表すために使用される言語を指定するために使用することができます：XMLは、「XML」名前空間、XMLで特殊な属性を定義します。 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属性：強くプロトコルは、XMLの人間の言語の委任、使用中のデータを表すことをお勧めします。
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"
単にXML文字列データ型を使って表現することが難しいことができ、いくつかの人間の言語のタイポグラフィにおける標準メカニズムがあります。例えば、発音の手がかりは、Ruby注釈[39]を用いて、及び（例えば、[34]のセクション3.4に記載されているような）コントロールまたはXHTML [40]「DIR」を埋め込む提供することができます
attribute can be used to note the proper display direction for bidirectional text.
属性は、双方向テキストのための適切な表示方向を注意するために使用することができます。
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 URIが制限されたUS-ASCIIのサブセットまたは任意のUnicodeを使用して表現されるべきかどうかについていくつかの議論がなされてきた（例えば、RFC 2396で「元の文字列」VS「URI文字列」[17]）。
Some of these issues are discussed, with recommendations, in the W3C's "Character Model for the World Wide Web" document [44].
これらの問題のいくつかは、文書[44] W3Cの「ワールド・ワイド・ウェブのためのキャラクタモデル」で、お薦めで、議論されています。
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]は意図しない開示を防ぐために、プライバシーサービスを提供しています。カノニカルXML [6]、XMLデジタル署名[7]データソースの同一性を確認するために修正および認証サービスを検出するために、完全性サービスを提供します。他の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.
マーク・ベイカー、ティム・バーナーズ=リー、ティム・ブレイ、James Clark氏、ジョシュ・コーエン、ジョン・コーワン、アラン・クラウチ、マーティンDuerst、6月藤沢、クリスチャンGeuer投票男、ヤロンGoland、グラハムKlyne、ダンコーン、リックJeliffe、クリス・リレイ、村田誠、マイケル・メオーリング、ジャン・ジャック・モロー、アンドリュー・ニュートン、ジュリアンReschke、ジョナサン・ローゼンバーグ、マイルセービン、リッチ・サルズ、ピーター・サン・アンドレ、サイモン・サンローラン、マーガレットワッサーマン、ダニエルVeillard。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2]ダークス、T.とC.アレン、 "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.、BCP 18、RFC 2277 "文字セットと言語のIETF方針"、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]村田、M.、サンローラン、S.およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[6] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[6]ボイヤー、J.、 "標準的な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]イーストレーク、D.、Reagle、J.およびD.ソロ "（拡張マークアップ言語）、XML署名の構文および処理"、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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、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]ブレイ、T.、オランダ、D.とA.素人、 "XMLで名前空間"、W3C REC-XML-名、1999年1月、<http://www.w3.org/TR/REC-xml-名前>。
[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]今村、T.、Dillaway、B.、Schaad、J. E.およびサイモン、 "XML暗号化構文と処理"、W3C REC-xmlencコア2001年10月、<http://www.w3.org / TR / xmlencコア/>。
[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.ハーディー、 "登録プロトコル・パラメータのためのIETF URNサブ名前空間"、ProgressのWork。
[12] Mealling, M., "The IETF XML Registry", Work in Progress.
[12] Mealling、M.、 "IETF XMLレジストリ"、ProgressのWork。
[13] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[13]ケース、J.、ヒョードル、M.、Schoffstall、M.とC.デーヴィン、 "簡易ネットワーク管理プロトコル（SNMP）"、STD 15、RFC 1157、1990年5月。
[14] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[14]スリニバサン、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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[16] Crocker, D. (Ed.) and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
"構文仕様のための増大しているBNF：ABNF" [16]クロッカー、D.（エド。）及びP. Overell、RFC 2234、1997年11月。
[17] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[17]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、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.
、BCP 26、RFC 2434、1998年10月[18] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[19] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[19]ローズ、M.、 "ライティングI-DSおよびXMLを使用しているRFC"、RFC 2629、1999年6月。
[20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[20]ホフマン、P.及び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.（編）、 "簡易メール転送プロトコル"、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.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、M.と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.とM.モーズリー、 "一般名解決プロトコル（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]バッカス、J.、1959年6月「チューリッヒACM-GAMM会議の提案国際代数言語の構文とセマンティクス」。
[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.
、ANSI X3.41、FIPS PUBの35、1974 [26]米国規格協会、「情報交換用米国標準コード（ASCII）の7ビットコード化文字セットを使用するためのコード拡張技術」。
[27] American National Standards Institute, "Information Retrieval: Application Service Definition and Protocol Specification", ANSI Z39.50, ISO Standard 23950, 1995.
[27]米国規格協会、 "情報検索：アプリケーション・サービスの定義およびプロトコル仕様"、ANSI Z39.50、ISO規格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]国際標準化機構、「情報処理システム - オープンシステムインターコネクション - 抽象構文記法1（ASN.1）の仕様」、ISO規格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規格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）」、8879 ISO規格、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規格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コンソーシアム、 "Unicode標準、それは随時改訂されたり、修正することができるように、" 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.及びA.フライターク、 "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]ブレイ、T.、パオリ、J.及びC. Sperberg-マックイーン、 "拡張マークアップ言語（XML）1.0"、W3C REC-XML-1998、1998年2月、<HTTP：// www.w3.org/ TR / 1998 / REC-XML-19980210 />。
[36] Marsh, J., "XML Base", W3C REC-xmlbase, June 2001, <http:// www.w3.org/TR/xmlbase/>.
[36]マーシュ、J.、 "XMLベース"、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]コーワン、J.とR.トビン、 "XML情報セット"、W3C REC-インフォセット、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.およびR.スウィック、 "リソース記述フレームワーク（RDF）モデルとシンタックス仕様"、W3C REC-RDF-構文、1999年2月、<http://www.w3.org/TR/REC- RDF構文>。
[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.、石川、M.、Duerst、M.及びT.テキシン、 "ルビー注釈"、W3C REC-RUBY、2001年5月、<http://www.w3.org/TR/ルビー/ >。
[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]トンプソン、H.、ブナ、D.、マロニー、M.およびN.メンデルゾーン、 "XMLスキーマパート1：構造"、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]ビロン、P.およびA.マルホトラ、 "XMLスキーマパート2：データ型"、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.、石田、R.、ウルフ、M.、フライターク、A.およびT.テキシン、 "ワールド・ワイド・ウェブ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.、ハドリー、M.、モロー、JJ。そして、H.ニールセン、 "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.、ハドリー、M.、モロー、JJ。そして、H.ニールセン、 "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通信チーム、 "10ポイントでXML"、2001年11月、<http://www.w3.org/XML/1999/XML-in-10-points>。
[48] OASIS Technical Committee: RELAX NG, "RELAX NG Specification", December 2001, <http://www.oasis-open.org/committees/relax-ng/ spec-20011203.html>.
[48] OASIS技術委員会：2001年12月、<http://www.oasis-open.org/committees/relax-ng/ 20011203.htmlスペック> "NG仕様RELAX"、NGをRELAX。
[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
URI
[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
スコットホレンベックベリサイン社21345 Ridgetopサークルダレス、バージニア州20166から6503米
Phone: +1 703 948 3257 EMail: shollenbeck@verisign.com
電話：+1 703 948 3257 Eメール：shollenbeck@verisign.com
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
マーシャルT.ローズドーバービーチコンサルティング株式会社POB 255268サクラメント、CA 95865から5268米
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
電話：+1 916 483 8878 Eメール：mrose@dbc.mtview.ca.us
Larry Masinter Adobe Systems Incorporated Mail Stop W14 345 Park Ave. San Jose, CA 95110 US
ラリーMasinter Adobe Systems Incorporated（アドビシステムズ社）のメールストップW14 345パークアベニュー。サンノゼ、CA 95110米国
Phone: +1 408 536 3024 EMail: LMM@acm.org URI: http://larry.masinter.net
電話：+1 408 536 3024 Eメール：LMM@acm.org URI：http://larry.masinter.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。