RFC3741 日本語訳
3741 Exclusive XML Canonicalization, Version 1.0. J. Boyer, D.Eastlake 3rd, J. Reagle. March 2004. (Format: TXT=35403 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Boyer
Request for Comments: 3741 PureEdge Solutions
Category: Informational D. Eastlake 3rd
Motorola
J. Reagle
W3C
March 2004
コメントを求めるワーキンググループJ.ボワイエ要求をネットワークでつないでください: 3741年のPureEdgeソリューションカテゴリ: 2004年のD.イーストレーク情報の3モトローラのJ.Reagle W3C行進番目
Exclusive XML Canonicalization, Version 1.0
排他的なXML Canonicalization、バージョン1.0
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the "xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization.
正準なXMLが「副-ドキュメント」に適用されるとそれが名前空間宣言と属性のすべてを含む「副-ドキュメント」の先祖文脈を含むXMLの標準の連載を指定する、「xml:」 名前空間。 しかしながら、いくつかのアプリケーションが先祖文脈を範囲に実用的にcanonicalized subdocumentに入れないようにするメソッドを必要とします。 例えば、人はその「副-ドキュメント」がオリジナルのメッセージから取り除く、そして/または、異なった文脈に挿入されるとき知れ渡らないXMLメッセージのXMLペイロード(「副-ドキュメント」)の上デジタル署名を必要とするかもしれません。 この要件はExclusive XML Canonicalizationによって満たされています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Applications . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Limitations. . . . . . . . . . . . . . . . . . . . . . . 5
2. The Need for Exclusive XML Canonicalization. . . . . . . . . . 5
2.1. A Simple Example . . . . . . . . . . . . . . . . . . . . 6
2.2. General Problems with re-Enveloping. . . . . . . . . . . 7
3. Specification of Exclusive XML Canonicalization. . . . . . . . 8
3.1. Constrained Implementation (non-normative) . . . . . . . 9
4. Use in XML Security. . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
5.1. Target Context . . . . . . . . . . . . . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 用語。 . . . . . . . . . . . . . . . . . . . . . . 2 1.2. アプリケーション. . . . . . . . . . . . . . . . . . . . . . 4 1.3。 制限。 . . . . . . . . . . . . . . . . . . . . . . 5 2. 排他的なXML Canonicalizationの必要性。 . . . . . . . . . 5 2.1. 簡単な例. . . . . . . . . . . . . . . . . . . . 6 2.2。 再のおおうのに関する一般的問題。 . . . . . . . . . . 7 3. 排他的なXML Canonicalizationの仕様。 . . . . . . . 8 3.1. 強制的な実装(非標準の).9 4。 XMLでセキュリティを使用してください。 . . . . . . . . . . . . . . . . . . . . . 10 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 5.1. 目標文脈. . . . . . . . . . . . . . . . . . . . . 12
Boyer, et al. Informational [Page 1] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[1ページ]のRFC3741
5.2. 'Esoteric' Node-sets . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
7. Acknowledgements (Informative) . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
5.2. '難解な'ノードセット.136。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1。 引用規格. . . . . . . . . . . . . . . . . . 13 6.2。 有益な参照. . . . . . . . . . . . . . . . . 14 7。 承認(有益な).14人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 15の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
The XML Recommendation [XML] specifies the syntax of a class of objects called XML documents. The Namespaces in XML Recommendation [XML-NS] specifies additional syntax and semantics for XML documents. It is normal for XML documents and subdocuments which are equivalent for the purposes of many applications to differ in their physical representation. For example, they may differ in their entity structure, attribute ordering, and character encoding. The goal of this specification is to establish a method for serializing the XPath node-set representation of an XML document or subset such that:
XML Recommendation[XML]はXMLドキュメントと呼ばれるオブジェクトのクラスの構文を指定します。 XML Recommendation[XML-NS]のNamespacesは追加構文と意味論をXMLドキュメントに指定します。 XMLドキュメントと同等な「副-ドキュメント」に、多くのアプリケーションの目的が彼らの具現において異なるのは、正常です。 例えば、彼らはそれらの実体構造、属性注文、および文字符号化において異なるかもしれません。 この仕様の目標がXMLドキュメントのXPathノードセット表現を連載するためのメソッドを確立することであるか部分集合がそのようなものであるので:
1. The node-set is minimally affected by any XML context which has
been omitted.
2. The canonicalization of a node-set representing well-balanced
XML [XML-Fragment] will be unaltered by further applications of
exclusive canonicalization.
3. It can be determined whether two node-sets are identical except
for transformations considered insignificant by this
specification under [XML, XML-NS].
1. ノードセットは省略されたどんなXML文脈でも最少量で影響を受けます。 2. バランスの良いXML[XML-断片]を表す1つのノードセットのcanonicalizationは排他的なcanonicalizationのさらなるアプリケーションで非変更されるでしょう。 3. 無意味にであるとこの仕様で考えられた変換を除いて、2つのノードセットが[XML、XML-NS]の下で同じであるかどうかが決定できます。
An understanding of the Canonical XML Recommendation [XML-C14N] is required.
Canonical XML Recommendation[XML-C14N]の理解が必要です。
The World Wide Web Consortium Recommendation corresponding to this RFC is at: http://www.w3.org/TR/xml-exc-c14n. Errata are located at http://www.w3.org/2002/07/xml-exc-c14n-errata.
このRFCに対応するワールドワイドウェブコンソーシアムRecommendationが以下にあります。 http://www.w3.org/TR/xml-exc-c14n 。 誤字は http://www.w3.org/2002/07/xml-exc-c14n-errata に位置しています。
1.1. Terminology
1.1. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Keywords].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
The XPath 1.0 Recommendation [XPath] defines the term node-set and specifies a data model for representing an input XML document as a set of nodes of various types (element, attribute, namespace, text, comment, processing instruction, and root). The nodes are included in or excluded from a node-set based on the evaluation of an expression. Within this specification and [XML-C14N], a node-set is
XPath1.0Recommendation[XPath]は1セットの様々なタイプのノード(要素、属性、名前空間、テキスト、コメント、処理命令、および根)として入力XMLドキュメントを表すのに用語ノードセットを定義して、データモデルを指定します。 ノードは式の評価を、含まれているか、またはベースのノードセットから除かれます。 この仕様と[XML-C14N]の中では、ノードセットはそうです。
Boyer, et al. Informational [Page 2] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[2ページ]のRFC3741
used to directly indicate whether or not each node should be rendered in the canonical form (in this sense, it is used as a formal mathematical set). A node that is excluded from the set is not rendered in the canonical form being generated, even if its parent node is included in the node-set. However, an omitted node may still impact the rendering of its descendants (e.g., by affecting the namespace context of the descendants).
各ノードが標準形に表されるべきであるかどうかを(この意味で、それは正式な数学のセットとして使用されます)直接示すのにおいて、使用されています。 セットから除かれるノードは生成される標準形に表されません、親ノードがノードセットに含まれても。 しかしながら、省略されたノードはまだ子孫(例えば、子孫の名前空間文脈に影響するのによる)のレンダリングに影響を与えているかもしれません。
A document subset is a portion of an XML document indicated by an XPath node-set that may not include all of the nodes in the document. As defined in [XPath] every node (e.g., element, attribute, and namespace), has exactly one parent, which is either an element node or the root node. An apex node is an element node in a document subset having no element node ancestor in the document subset. An orphan node is an element node whose parent element node is not in the document subset. The output parent of an orphan node that is not an apex node is the nearest ancestor element of the orphan node that is in the document subset; an apex node has no output parent. The output parent of a non-orphan node is the parent of the node. An output ancestor is any ancestor element node in the document subset.
ドキュメント部分集合はドキュメントにノードのすべてを含まないかもしれないXPathノードセットによって示されたXMLドキュメントの一部です。 [XPath]であらゆるノード(例えば、要素、属性、および名前空間)を定義して、まさに1人の親、どれが要素ノードであるか、そして、または根のノードを持っているとき。 ドキュメント部分集合には要素ノード先祖が全くいないドキュメント部分集合では、頂点ノードは要素ノードです。 親のないノードはドキュメント部分集合には親元素ノードがない要素ノードです。 頂点ノードでない親のないノードの出力親はドキュメント部分集合にはある親のないノードの最も近い先祖原理です。 頂点ノードには、出力親が全くいません。 非孤児ノードの出力親はノードの親です。 出力先祖はドキュメント部分集合のあらゆる先祖要素ノードです。
For example given a document tree with three generations under the root node A and where capitalization denotes the node is in the document subset (A,E,G).
例えば、ドキュメント木を考えて、三代と共に、根のノードAの下と、そして、資源化がノードを指示するところにドキュメント部分集合には(A、E、G)があります。
Pictorial Representation:
絵の表現:
[diagram of nodes,
http://www.w3.org/TR/xml-exc-c14n/exc-c14n.png]
[ノード、 http://www.w3.org/TR/xml-exc-c14n/exc-c14n.png のダイヤグラム]
Textual Representation:
原文の表現:
A-+-b
`-c-+-d
`-E-+-f
`-G
The following characteristics apply:
A+b、'、-、次の特性が適用するc-+d'電子+のf'-G:、'
* A is an apex node, output parent of E, and output ancestor of
(E,G);
* E is an orphan node and the output parent of G.
* Aは、頂点ノードと、Eの出力親と、(E、G)の出力先祖です。 * Eは、親のないノードとGの出力親です。
An element E in a document subset visibly utilizes a namespace declaration, i.e., a namespace prefix P and bound value V, if E or an attribute node in the document subset with parent E has a qualified name in which P is the namespace prefix. A similar definition
ドキュメント部分集合の要素Eは明らかに名前空間宣言を利用します、すなわち、名前空間接頭語PとバウンドはVを評価します、Eか親Eとのドキュメント部分集合の属性ノードにPが名前空間接頭語である適切な名前があるなら。 同様の定義
Boyer, et al. Informational [Page 3] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[3ページ]のRFC3741
applies for an element E in a document subset that visibly utilizes the default namespace declaration, which occurs if E has no namespace prefix.
明らかにEに名前空間接頭語が全くないなら起こるデフォルト名前空間宣言を利用するドキュメント部分集合で要素Eに申し込みます。
The namespace axis of an element contains nodes for all non-default namespace declarations made within the element as well as non-default namespace declarations inherited from ancestors of the element. The namespace axis also contains a node representing the default namespace if it is not the empty string, whether the default namespace was declared within the element or by an ancestor of the element. Any subset of the nodes in a namespace axis can be included in a document subset.
要素の名前空間軸は要素の先祖から引き継がれた非デフォルト名前空間宣言と同様に要素の中でされたすべての非デフォルト名前空間宣言のためのノードを含んでいます。 また、名前空間軸はそれが空のストリングでないならデフォルト名前空間を表すノードを含んでいます、デフォルト名前空間が要素の先祖によって要素以内か宣言されたか否かに関係なく。 ドキュメント部分集合に名前空間軸のノードのどんな部分集合も含むことができます。
The method of canonicalization described in this specification receives an InclusiveNamespaces PrefixList parameter, which lists namespace prefixes that are handled in the manner described by the Canonical XML Recommendation [XML-C14N].
この仕様で説明されたcanonicalizationのメソッドはInclusiveNamespaces PrefixListパラメタを受け取ります。(それは、Canonical XML Recommendation[XML-C14N]によって説明された方法で扱われる名前空間接頭語を記載します)。
The exclusive canonical form of a document subset is a physical representation of the XPath node-set, as an octet sequence, produced by the method described in this specification. It is as defined in the Canonical XML Recommendation [XML-C14N] except for the changes summarized as follows:
ドキュメント部分集合の唯一の標準形はXPathノードセットの具現です、この仕様で説明されたメソッドで作成された八重奏系列として。 それは以下の通りまとめられた変化以外のCanonical XML Recommendation[XML-C14N]で定義されるようにあります:
* attributes in the XML namespace, such as xml:lang and xml:space
are not imported into orphan nodes of the document subset, and
* namespace nodes that are not on the InclusiveNamespaces
PrefixList are expressed only in start tags where they are
visible and if they are not in effect from an output ancestor
of that tag.
* XML名前空間における、xmlなどの属性: *xml: langとスペースはドキュメント部分集合の親のないノードにインポートされないで、それらが目に見える開始タグだけで言い表されて、それらがそのタグの出力先祖から有効でないなら、InclusiveNamespaces PrefixListにない名前空間ノードはインポートされます。
The term exclusive canonical XML refers to XML that is in exclusive canonical form. The exclusive XML canonicalization method is the algorithm defined by this specification that generates the exclusive canonical form of a given XML document subset. The term exclusive XML canonicalization refers to the process of applying the exclusive XML canonicalization method to an XML document subset.
排他的であるという用語の正準なXMLは唯一の標準形にあるXMLについて言及します。 排他的なXML canonicalizationメソッドは与えられたXMLドキュメント部分集合の唯一の標準形を生成するこの仕様で定義されたアルゴリズムです。 排他的であるという用語XML canonicalizationは排他的なXML canonicalizationメソッドをXMLドキュメント部分集合に適用するプロセスについて言及します。
1.2. Applications
1.2. アプリケーション
The applications of Exclusive XML Canonicalization are very similar to those for Canonical XML [XML-C14N]. However, exclusive canonicalization, or equivalent means of excluding most XML context, is necessary for signature applications where the XML context of signed XML will change. This sort of change is typical of many protocol applications.
Canonical XML[XML-C14N]に、Exclusive XML Canonicalizationのアプリケーションはそれらと非常に同様です。 しかしながら、排他的なcanonicalization、またはほとんどのXML文脈を除く均等手段が署名しているXMLのXML文脈が変化する署名アプリケーションに必要です。 この種類の変化は多くのプロトコルアプリケーションの典型です。
Boyer, et al. Informational [Page 4] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[4ページ]のRFC3741
Note that in the case of the SignedInfo element of [XML-DSig], the specification of an appropriate canonicalization method is the only technique available to protect the signature from insignificant changes in physical form and changes in XML context.
[XML-DSig]のSignedInfo要素のケースでは、適切なcanonicalizationメソッドの仕様が物理的なフォームにおける重要でない変更とXML文脈における変化から署名を保護するために利用可能な唯一のテクニックであることに注意してください。
1.3. Limitations
1.3. 制限
Exclusive XML Canonicalization has the limitations of Canonical XML [XML-C14N] plus two additional limitations as follows:
排他的なXML CanonicalizationはCanonical XML[XML-C14N]と2つの追加制限の制限を以下の通りにします:
1. The XML being canonicalized may depend on the effect of XML
namespace attributes, such as xml:lang, xml:space, and xml:base
appearing in ancestor nodes. To avoid problems due to the
non-importation of such attributes into an enveloped document
subset, either they MUST be explicitly given in a node of the
XML document subset being canonicalized where their effect is
needed or which is an ancestor of the node where their effect
is needed or they MUST always be declared with an equivalent
value in every context in which the XML document subset will be
interpreted.
2. Applications that use the XML being canonicalized may depend on
the effect of XML namespace declarations where the namespace
prefix being bound is not visibly utilized. An example would
be an attribute whose value is an XPath expression and whose
evaluation therefore depends upon namespace prefixes referenced
in the expression. Or, an attribute value might be considered
a QName [XML-NS] by some applications, but it is only a
string-value to XPath:
1. canonicalizedされるXMLはXML名前空間属性の効果によるかもしれません、xml: langや、xml: スペースや、xmlなどのように: 先祖ノードのベース排臨。 そのような属性の非輸入のためおおわれたドキュメント部分集合として問題を避けるために、それらの効果が必要であるところでcanonicalizedされる先祖であるXMLドキュメント部分集合のノードで明らかに、それらの効果が必要である、または同等な値がXMLドキュメント部分集合が解釈されるあらゆる文脈にある状態でいつもそれらを宣言しなければならないノードをそれらに与えなければなりません。 2. 制限された名前空間接頭語が明らかに利用されないところでcanonicalizedされるXMLを使用するアプリケーションはXML名前空間宣言の効果によるかもしれません。 例は値がXPath式であり、したがって評価が式で参照をつけられる名前空間接頭語による属性でしょう。 または、属性値はQName[XML-NS]であるといくつかのアプリケーションで考えられるかもしれませんが、それはXPathへのストリング値にすぎません:
<number xsi:type="xsd:decimal">10.09</number>.
<番号xsi: =をタイプしてください、「xsd: 10進「>10.09</数の>。」
To avoid problems with such namespace declarations,
そのような名前空間宣言に関する問題を避けるために
o the XML MUST be modified so that use of the namespace prefix
involved is visible, or
o the namespace declarations MUST appear and be bound to the same
values in every context in which the XML will be interpreted,
or
o the prefixes for such namespaces MUST appear in the
InclusiveNamespaces PrefixList.
o XML MUST、かかわった名前空間接頭語の使用が目に見えるか、○ 名前空間宣言は現れて、XMLが解釈されるあらゆる文脈の同じ値に縛らなければならないか、または○ そのような名前空間のための接頭語がInclusiveNamespaces PrefixListに現れなければならないように、変更されてください。
2. The Need for Exclusive XML Canonicalization
2. 排他的なXML Canonicalizationの必要性
In some cases, particularly for signed XML in protocol applications, there is a need to canonicalize a subdocument in such a way that it is substantially independent of its XML context. This is because, in protocol applications, it is common to envelope XML in various layers of message or transport elements, to strip off such enveloping, and
いくつかの場合、特にプロトコルアプリケーションにおける署名しているXMLのために、XML文脈の如何にかかわらず実質的にそのような方法で「副-ドキュメント」をcanonicalizeする必要があります。 そしてこれがそれがそのようなおおうことを全部はぎ取るために様々な層のメッセージか輸送要素において封筒XMLにプロトコルアプリケーションでは、共通であるからである。
Boyer, et al. Informational [Page 5] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[5ページ]のRFC3741
to construct new protocol messages, parts of which were extracted from different messages previously received. If the pieces of XML in question are signed, they need to be canonicalized in a way such that these operations do not break the signature but the signature still provides as much security as can be practically obtained.
新しいプロトコルメッセージを構成するために。その部品は以前に受け取られた異なったメッセージから抽出されました。 問題のXMLの断片が署名されるなら、方法でcanonicalizedされるのが必要であるので、これらの操作は署名を壊しませんが、署名はまだ実際に得ることができるのと同じくらい多くのセキュリティを提供しています。
2.1. A Simple Example
2.1. 簡単な例
As a simple example of the type of problem that changes in XML context can cause for signatures, consider the following document:
XML文脈における変化が署名のために引き起こす場合がある問題のタイプの簡単な例と、以下のドキュメントを考えてください:
<n1:elem1 xmlns:n1="http://b.example">
content
</n1:elem1>
<n1:elem1 xmlns:n1が等しい、「 http://b.example 、「>内容</n1: elem1>」
this is then enveloped in another document:
次に、これは別のドキュメントでおおわれます:
<n0:pdu xmlns:n0="http://a.example">
<n1:elem1 xmlns:n1="http://b.example">
content
</n1:elem1>
</n0:pdu>
<n0:pdu xmlns:n0が等しい、「 http://a.example 、「><n1:elem1 xmlns:n1が等しい、「 http://b.example 、「>内容</n1: elem1></n0: pdu>」
The first document above is in canonical form. But assume that document is enveloped as in the second case. The subdocument with elem1 as its apex node can be extracted from this second case with an XPath expression such as:
上記の最初のドキュメントが標準形にあります。 しかし、ドキュメントが2番目のケースのようにおおわれると仮定してください。 以下などのXPath式でこの2番目のケースから頂点ノードとしてのelem1がある「副-ドキュメント」を抽出できます。
(//. | //@* | //namespace::*)[ancestor-or-self::n1:elem1]
(//| //@* | //名前空間: : *)[先祖か自己: : n1: elem1]
The result of applying Canonical XML to the resulting XPath node-set is the following (except for line wrapping to fit this document):
結果として起こるXPathノードセットにCanonical XMLを適用するという結果は以下(このドキュメントに合う系列ラッピングを除いた)です:
<n1:elem1 xmlns:n0="http://a.example"
xmlns:n1="http://b.example">
content
</n1:elem1>
<n1:elem1 xmlns:n0が" http://a.example "xmlns: n1=と等しい、「 http://b.example 、「>内容</n1: elem1>」
Note that the n0 namespace has been included by Canonical XML because it includes namespace context. This change which would break a signature over elem1 based on the first version.
名前空間文脈を含んでいるのでn0名前空間がCanonical XMLによって含まれていることに注意してください。 elem1の上で署名を壊すこの変化が最初のバージョンを基礎づけました。
Boyer, et al. Informational [Page 6] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[6ページ]のRFC3741
2.2. General Problems with re-Enveloping
2.2. 再のおおうのに関する一般的問題
As a more complete example of the changes in canonical form that can occur when the enveloping context of a document subset is changed, consider the following document:
ドキュメント部分集合のおおう文脈を変えるとき起こることができる標準形における変化の、より完全な例と、以下のドキュメントを考えてください:
<n0:local xmlns:n0="foo:bar"
xmlns:n3="ftp://example.org">
<n1:elem2 xmlns:n1="http://example.net"
xml:lang="en">
<n3:stuff xmlns:n3="ftp://example.org"/>
</n1:elem2>
</n0:local>
<n0: 地方のxmlns: n0がxmlns: 「foo: バー」n3=と等しい、「 ftp://example.org 、「><n1:elem2 xmlns:n1が" http://example.net "xml: lang=と等しい、「アン、「><n3: xmlnsを詰めてください: n3は" ftp://example.org "/></n1: elem2></n0: 地方の>と等しいです」。
And the following which has been produced by changing the enveloping of elem2:
elem2をおおうことを変えることによって生産された以下:
<n2:pdu xmlns:n1="http://example.com"
xmlns:n2="http://foo.example"
xml:lang="fr"
xml:space="retain">
<n2:pdu xmlns:n1は" http://example.com "xmlnsと等しいです: n2は" http://foo.example "xmlと等しいです: langが"fr"xml: スペース=と等しい、「">"を保有してください。
<n1:elem2 xmlns:n1="http://example.net"
xml:lang="en">
<n3:stuff xmlns:n3="ftp://example.org"/>
</n1:elem2>
</n2:pdu>
<n1:elem2 xmlns:n1が" http://example.net "xml: lang=と等しい、「アン、「><n3: xmlnsを詰めてください: n3は" ftp://example.org "/></n1: elem2></n2: pdu>と等しいです」。
Assume an XPath node-set produced from each case by applying the following XPath expression:
各ケースから以下のXPath式を適用することによって生産されたXPathノードセットを仮定してください:
(//. | //@* | //namespace::*)[ancestor-or-self::n1:elem2]
(//| //@* | //名前空間: : *)[先祖か自己: : n1: elem2]
Applying Canonical XML to the node-set produced from the first document yields the following serialization (except for line wrapping to fit in this document):
ノードセットにCanonical XMLを適用すると、最初のドキュメント利回りから、以下の連載(本書では合う系列ラッピングを除いた)は起こされました:
<n1:elem2 xmlns:n0="foo:bar"
xmlns:n1="http://example.net"
xmlns:n3="ftp://example.org"
xml:lang="en">
<n3:stuff></n3:stuff>
</n1:elem2>
<n1:elem2 xmlns:n0は「foo: バー」xmlnsと等しいです: n1は" http://example.net "xmlnsと等しいです: n3が" ftp://example.org "xml: lang=と等しい、「アン、「><n3: ></n3を詰めてください: ></n1: elem2>を詰めてください」
Boyer, et al. Informational [Page 7] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[7ページ]のRFC3741
However, although elem2 is represented by the same octet sequence in both pieces of external XML above, the Canonical XML version of elem2 from the second case would be (except for line wrapping so it will fit into this document) as follows:
しかしながら、elem2は両方の外部のXML上に同じ八重奏系列によって表されますが、2番目のケースからのelem2のCanonical XMLバージョンは以下の(系列がそれが収まるそうを包装するのを除いたこのドキュメント)でしょう:
<n1:elem2 xmlns:n1="http://example.net"
xmlns:n2="http://foo.example"
xml:lang="en"
xml:space="retain">
<n3:stuff xmlns:n3="ftp://example.org"></n3:stuff>
</n1:elem2>
<n1:elem2 xmlns:n1は" http://example.net "xmlnsと等しいです: n2は" http://foo.example "xmlと等しいです: langが「アン」xml: スペース=と等しい、「保有、「><n3: xmlns: n3=を詰めてください、「 ftp://example.org 、「></n3: ></n1: elem2>を詰めてください」
Note that the change in context has resulted in lots of changes in the subdocument as serialized by the inclusive Canonical XML [XML- C14N]. In the first example, n0 had been included from the context and the presence of an identical n3 namespace declaration in the context had elevated that declaration to the apex of the canonicalized form. In the second example, n0 has gone away but n2 has appeared, n3 is no longer elevated, and an xml:space declaration has appeared, due to changes in context. But not all context changes have effect. In the second example, the presence at ancestor nodes of an xml:lang and n1 prefix namespace declaration have no effect because of existing declarations at the elem2 node.
包括的なCanonical XML[XML- C14N]によって連載されるように変化が状況内において「副-ドキュメント」における多くの変化をもたらしたことに注意してください。 最初の例では、n0は文脈から含まれていました、そして、文脈での同じn3名前空間宣言の存在はcanonicalizedフォームの頂点にその宣言を登用しました。 n2は現れました、そして、n3はもう上げられません、そして、2番目の例では、n0は遠ざかりましたが、xml: 宇宙宣言は変化のため状況内において現れました。 しかし、すべての文脈変化が手答えがあるというわけではありません。 2番目の例、xmlの先祖ノードでの存在で: langとn1接頭語名前空間宣言は既存の宣言のためにelem2ノードで効き目がありません。
On the other hand, using Exclusive XML Canonicalization as specified herein, the physical form of elem2 as extracted by the XPath expression above is (except for line wrapping so it will fit into this document) as follows:
他方では、ここに指定されるとしてのExclusive XML Canonicalizationを使用して、抽出されるとしての上のXPath式によるelem2の物理的なフォームは以下の(系列がそれが収まるそうを包装するのを除いたこのドキュメント)です:
<n1:elem2 xmlns:n1="http://example.net"
xml:lang="en">
<n3:stuff xmlns:n3="ftp://example.org"></n3:stuff>
</n1:elem2>
<n1:elem2 xmlns:n1が" http://example.net "xml: lang=と等しい、「アン、「><n3: xmlns: n3=を詰めてください、「 ftp://example.org 、「></n3: ></n1: elem2>を詰めてください」
in both cases.
どちらの場合も。
3. Specification of Exclusive XML Canonicalization
3. 排他的なXML Canonicalizationの仕様
The data model, processing, input parameters, and output data for Exclusive XML Canonicalization are the same as for Canonical XML [XML-C14N] with the following exceptions:
データモデル、処理、入力パラメタ、およびExclusive XML Canonicalizationのための出力データは以下の例外があるCanonical XML[XML-C14N]のように同じです:
1. Canonical XML applied to a document subset requires the search
of the ancestor nodes of each orphan element node for
attributes in the XML namespace, such as xml:lang and
xml:space. These are copied into the element node except if a
declaration of the same attribute is already in the attribute
axis of the element (whether or not it is included in the
1. ドキュメント部分集合に適用された正準なXMLはXML名前空間における属性のためのそれぞれの親のない要素ノードの先祖ノードの検索を必要とします、xmlなどのように: langとxml: スペース。 これらが要素ノードと同じ属性の宣言が要素の属性軸に既にあるかにコピーされる、(それは中に含まれています。
Boyer, et al. Informational [Page 8] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[8ページ]のRFC3741
document subset). This search and copying are omitted from the
Exclusive XML Canonicalization method.
2. The Exclusive XML Canonicalization method may receive an
additional, possibly null, parameter InclusiveNamespaces
PrefixList containing a list of namespace prefixes and/or a
token indicating the presence of the default namespace. All
namespace nodes appearing on this list are handled as provided
in Canonical XML [XML-C14N].
3. A namespace node N with a prefix that does not appear in the
InclusiveNamespaces PrefixList is rendered if all of the
conditions are met:
1. Its parent element is in the node-set, and
2. it is visibly utilized by its parent element, and
3. the prefix has not yet been rendered by any output ancestor,
or the nearest output ancestor of its parent element that
visibly utilizes the namespace prefix does not have a
namespace node in the node-set with the same namespace
prefix and value as N.
4. If the token representing the default namespace is not present
in InclusiveNamespaces PrefixList, then the rules for rendering
xmlns="" are changed as follows. When canonicalizing the
namespace axis of an element E that is in the node-set, output
xmlns="" if and only if all of the conditions are met:
1. E visibly utilizes the default namespace (i.e., it has no
namespace prefix), and
2. it has no default namespace node in the node-set, and
3. the nearest output ancestor of E that visibly utilizes the
default namespace has a default namespace node in the node-
set. (This step for xmlns="" is necessary because it is not
represented in the XPath data model as a namespace node, but
as the absence of a namespace node; see Section 4.7
Propagation of Default Namespace Declaration in Document
Subsets [XML-C14N].)
ドキュメント部分集合) この検索とコピーはExclusive XML Canonicalizationメソッドから省略されます。 2. Exclusive XML Canonicalizationメソッドは名前空間接頭語のリストを含む追加していて、ことによるとヌルのパラメタInclusiveNamespaces PrefixList、そして/または、デフォルト名前空間の存在を示すトークンを受けるかもしれません。 このリストに現れるすべての名前空間ノードがCanonical XML[XML-C14N]に供給するように扱われます。 3. 状態のすべてが会われるなら、InclusiveNamespaces PrefixListに現れない接頭語がある名前空間ノードNは表されます: 1. 3 ノードセットに親元素があります、そして、2 それは親元素によって明らかに利用されます、そして、接頭語がどんな出力先祖によってもまだ表されていないか、または明らかに名前空間接頭語を利用する親元素の最も近い出力先祖は同じ名前空間接頭語と値と共にN.4としてノードセットで名前空間ノードを持っていません。 「デフォルト名前空間を表すトークンがInclusiveNamespaces PrefixList、レンダリングxmlns=のための当時の規則で存在していないなら」。」 以下の通り、変えます。 そして、「ノードセットにある要素Eの名前空間軸をcanonicalizingするときには、xmlns=を出力してください」、」、状態のすべてが会われる場合にだけ: 1. 3 Eは明らかにデフォルト名前空間を利用します、そして、(すなわち、それには、名前空間接頭語が全くありません)2 それはノードセットでデフォルト名前空間ノードを全く持っていません、そして、明らかにデフォルト名前空間を利用するEの最も近い出力先祖はノードのデフォルト名前空間ノードを設定させます。 「(xmlnsのためのこのステップが等しい、」、」、それが名前空間ノードとしてXPathデータモデルで表されないので必要ですが名前空間ノードの欠如;セクション4.7 Document Subsets[XML-C14N)のDefault Namespace DeclarationのPropagationを見るとして
3.1. Constrained Implementation (non-normative)
3.1. 強制的な実装(非標準)です。
The following is a (non-normative) method for implementing the Exclusive XML Canonicalization method for many straightforward cases -- it assumes a well-formed subset and that if an element is in the node-set, so is all of its namespace axis; if the element is not in the subset, neither is its namespace axis.
↓これは多くの簡単なケースのためのExclusive XML Canonicalizationメソッドを実装するための(非標準)のメソッドです--ノードセットに要素があるなら、それは整形式の部分集合とそれを仮定して、名前空間軸のすべてもそうです。 部分集合に要素がないなら、名前空間軸もそうではありません。
1. Recursively process the entire tree (from which the XPath
node-set was selected) in document order starting with the
root. (The operation of copying ancestor xml: namespace
attributes into output apex element nodes is not done.)
2. If the node is not in the XPath subset, continue to process its
children element nodes recursively.
1. 根から始まって、ドキュメントオーダーで全体の木(XPathノードセットが選択された)を再帰的に処理してください。 (先祖xmlをコピーします: 出力頂点要素ノードへの名前空間属性の操作をしません。) 2. XPath部分集合にノードがないなら、子供要素ノードを再帰的に処理し続けてください。
Boyer, et al. Informational [Page 9] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[9ページ]のRFC3741
3. If the element node is in the XPath subset then output the node
in accordance with Canonical XML except for namespace nodes
which are rendered as follows:
3. XPath部分集合に要素ノードがあるなら、以下の通りに表される名前空間ノード以外のCanonical XMLに従って、ノードを出力してください:
1. ns_rendered is a copy of a dictionary, off the top of the
state stack, of prefixes and their values which have already
been rendered by an output ancestor of the namespace node's
parent element.
2. Render each namespace node if and only if all of the
conditions are met:
1. it is visibly utilized by the immediate parent element or
one of its attributes, or is present in
InclusiveNamespaces PrefixList, and
2. its prefix and value do not appear in ns_rendered.
3. Render xmlns="" if and only if all of the conditions are
met:
1. The default namespace is visibly utilized by the
immediate parent element node, or the default prefix
token is present in InclusiveNamespaces PrefixList, and
2. the element does not have a namespace node in the node-
set declaring a value for the default namespace, and
3. the default namespace prefix is present in the dictionary
ns_rendered.
4. Insert all the rendered namespace nodes (including xmlns="")
into the ns_rendered dictionary, replacing any existing
entries. Push ns_rendered onto the state stack and recurse.
5. After the recursion returns, pop the state stack.
1. _がレンダリングしたナノ秒は辞書のコピーです、州のスタック、接頭語の先端と名前空間ノードの親元素の出力先祖によって既にレンダリングされたそれらの値で。 2. そして、それぞれの名前空間ノードを表してください、状態のすべてが会われる場合にだけ: 2 1. それは、即座の親元素か属性の1つによって明らかに利用されるか、またはInclusiveNamespaces PrefixListに存在しています、そして、その接頭語と値はナノ秒_でレンダリングされているように見えません。 3. そして、「xmlns=をレンダリングしてください」、」、状態のすべてが会われる場合にだけ: 1. 3 デフォルト接頭語トークンはInclusiveNamespaces PrefixListに存在しています、そして、2 デフォルト名前空間のために値を宣言しながら、要素でノードの名前空間ノードを設定しません、そして、デフォルト名前空間が即座の親元素ノードによって明らかに利用されるか、またはデフォルト名前空間接頭語は_がレンダリングした辞書ナノ秒に存在しています。 4. 「すべてのレンダリングされた名前空間ノードを挿入してください、(xmlnsを含んでいるのが等しい、」、」、)、ナノ秒に、どんな既存のエントリーも取り替えて、_は辞書を表しました。 州のスタックにされたナノ秒_と「再-呪い」を押してください。 5. 再帰が戻った後に、州のスタックを飛び出させてください。
4. Use in XML Security
4. XMLでセキュリティを使用してください。
Exclusive Canonicalization may be used as a Transform or CanonicalizationMethod algorithm in XML Digital Signature [XML-DSig] and XML Encryption [XML-Enc].
排他的なCanonicalizationはXML Digital Signature[XML-DSig]とXML Encryption[XML-Enc]のTransformかCanonicalizationMethodアルゴリズムとして使用されるかもしれません。
Identifier:
http://www.w3.org/2001/10/xml-exc-c14n#
識別子: http://www.w3.org/2001/10/xml-exc-c14n#
http://www.w3.org/2001/10/xml-exc-c14n#WithComments
http://www.w3.org/2001/10/xml-exc-c14n#WithComments
Just as with [XML-C14N] one may use the "#WithComments" parameter to include the serialization of XML comments. This algorithm also takes an optional explicit parameter of an empty InclusiveNamespaces element with a PrefixList attribute. The value of this attribute is a white space delimited list of namespace prefixes, and where #default indicates the default namespace, to be handled as per [XML- C14N]. The list is in NMTOKENS format (a white space separated list). For example:
「ちょうど[XML-C14N]なら使用されるかもしれない、」 #WithComments、」 XMLの連載を含むパラメタはコメントします。 また、このアルゴリズムはPrefixList属性がある空のInclusiveNamespaces要素の任意の明白なパラメタを取ります。 この属性の値は、名前空間接頭語の余白の区切られたリストであり、[XML- C14N]のように#デフォルトが扱われるためにデフォルト名前空間を示すところでリストです。 NMTOKENS形式(余白の切り離されたリスト)にはリストがあります。 例えば:
Boyer, et al. Informational [Page 10] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[10ページ]のRFC3741
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="dsig soap #default"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
<ds: Algorithm=を変えてください、「 http://www.w3.org/2001/10/xml-exc-c14n# 、「><ec: InclusiveNamespaces PrefixListは「dsig石鹸#デフォルト」xmlnsと等しいです: ecは" http://www.w3.org/2001/10/xml-exc-c14n# "/></dsと等しいです: >を変えてください」
indicates the exclusive canonicalization transform, but that namespaces with prefix "dsig" or "soap" and default namespaces should be processed according to [XML-C14N].
排他的なcanonicalization変換と、[XML-C14N]に従って接頭語"dsig"か「石鹸」がある名前空間とデフォルト名前空間が処理されるべきであるのを示します。
Schema Definition (expressed in [XML-schema]):
図式定義([XML-図式]で、言い表されます):
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE schema
PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
"http://www.w3.org/2001/XMLSchema.dtd"
[
<!ATTLIST schema xmlns:ec CDATA
#FIXED 'http://www.w3.org/2001/10/xml-exc-c14n#'>
<!ENTITY ec 'http://www.w3.org/2001/10/xml-exc-c14n#'>
<!ENTITY % p ''>
<!ENTITY % s ''>
]>
<?xmlバージョン=、「=「utf-8インチ?」をコード化する1インチ><!DOCTYPE図式PUBLIC「-//W3C//DTD XMLSchema200102//アン」" http://www.w3.org/2001/XMLSchema.dtd "[<!ATTLIST図式xmlns: ec CDATA#FIXED' http://www.w3.org/2001/10/xml-exc-c14n# '><!ENTITY ec' http://www.w3.org/2001/10/xml-exc-c14n# '><!ENTITY%p「>] ><!実体%s」>'
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
targetNamespace="http://www.w3.org/2001/10/xml-exc-c14n#"
version="0.1" elementFormDefault="qualified">
<図式xmlns=" http://www.w3.org/2001/XMLSchema "xmlns: " http://www.w3.org/2001/10/xml-exc-c14n# "ec=targetNamespaceは" http://www.w3.org/2001/10/xml-exc-c14n# "バージョン=「0.1インチのelementFormDefault=」適切な">"と等しいです。
<element name="InclusiveNamespaces"
type="ec:InclusiveNamespaces"/>
<complexType name="InclusiveNamespaces">
<attribute name="PrefixList" type="NMTOKENS"/>
</complexType>
</schema>
<要素名義の=「InclusiveNamespaces」タイプが「ec: InclusiveNamespaces」/><complexType名=と等しい、「InclusiveNamespaces「><属性名前="PrefixList"タイプ=「NMTOKENS」/></complexType></図式>」
DTD:
<!ELEMENT InclusiveNamespaces EMPTY >
<!ATTLIST InclusiveNamespaces
PrefixList NMTOKENS #REQUIRED >
DTD: <!の要素のInclusiveNamespacesの空の><!ATTLIST InclusiveNamespaces PrefixList NMTOKENS#は>を必要としました。
Boyer, et al. Informational [Page 11] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[11ページ]のRFC3741
5. Security Considerations
5. セキュリティ問題
This specification is used to serialize an XPath node-set under certain assumptions given in [XML-C14N] and this specification. Three such examples include:
この仕様は、[XML-C14N]とこの仕様で与えられたある仮定でXPathノードセットを連載するのに使用されます。 そのような3つの例は:
1. implementations of [XML-C14N] and this specification do not render
an XML declaration;
2. implementations of this specification only render attributes from
the "XML" namespace (e.g., xml:lang, xml:space, and xml:base) when
they are in the subset being serialized;
3. implementations of this specification do not consider the
appearance of a namespace prefix within an attribute value to be
visibly utilized.
1. [XML-C14N]とこの仕様の実装はXML宣言をレンダリングしません。 2. 連載される部分集合にそれらがあるときだけ、この仕様の実装は"XML"名前空間(xml: 例えば、lang、xml: スペース、およびxml: ベース)から属性をレンダリングします。 3. この仕様の実装は、属性値の中の名前空間接頭語の外観が明らかに利用されると考えません。
While such choices are consistent with other XML specifications and satisfy the Working Group's application requirements it is important that an XML application carefully construct its transforms such that the result is meaningful and unambiguous in its application context. In addition to this section, the Limitations of this specification, the Resolutions of [XML-C14N], and the Security Considerations of [XML-DSig] should be carefully attended to.
そのような選択が他のXML仕様と一致していて、作業部会のアプリケーション要件を満たしますが、XMLアプリケーションが慎重に変換を構成するのが、重要であるので、結果は、アプリケーション文脈で重要であって、明白です。 このセクションに加えて、この仕様のLimitations、[XML-C14N]のResolutions、および[XML-DSig]のSecurity Considerationsは慎重に気を配られるべきです。
5.1. Target Context
5.1. 目標文脈
The requirement of this specification is to satisfy applications that "require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument." Given a fragment being removed from its source instance, this specification satisfies this requirement by excluding from the fragment any context from its ancestors that is not utilized. Consequently, a signature [XML-DSig] over that fragment will remain valid in its source context, removed from the source context, and even in a new target context. However, this specification does not insulate the fragment against confused interpretation in a target context.
この仕様の要件は「先祖文脈を範囲に実用的にcanonicalized subdocumentに入れないようにするメソッドを必要とである」アプリケーションを満たすことです。 ソースインスタンスから取り除かれる断片を考えて、この仕様は、断片から先祖からのどんな利用されなかった文脈も除くことによって、この要件を満たします。 その結果、その断片の上の署名[XML-DSig]はソース文脈から取り除かれたソース関係と新しい目標関係でさえ有効なままで残るでしょう。 しかしながら、この仕様は目標文脈における混乱した解釈に対して断片を絶縁しません。
For example, if the <Foo/> element is signed in its source instance of <Bar/><Foo/></Bar> and then removed and placed in the target instance <Baz xmlns="http://example.org/bar"/><Foo/></Baz>, the signature should still be valid, but won't be if <Foo/> is interpreted as belonging to the http://example.org/bar namespace: this is dependent on how nodes are processed.
例えば、<Foo/>要素が<Bar/><Foo/></バー>のソースインスタンスで署名されて次に、取り外されて" http://example.org/bar "/><Foo/></バズ目標インスタンス<バズxmlns=>に置かれると、署名は、まだ有効であるべきですが、<Foo/>が http://example.org/bar 名前空間に属しながら解釈されるかどうかということでないでしょう: これはノードがどう処理されるかに依存しています。
This specification does not define mechanisms of removing, inserting, and "fixing up" a node-set. (For an example of this sort of specification, see the processing required of Creating the Result Infoset (section 4.5) when an [XInclude] is performed.) Instead, applications must carefully specify the XML (i.e., source, fragment,
この仕様はノードセットの取り外して、指し込んで、「修理」であるメカニズムを定義しません。 (この種類の仕様の例に関して、[XInclude]が実行されるとき、処理がResult Infoset(セクション4.5)にCreatingを要求したのを確実にしてください。) 代わりに、アプリケーションが慎重にXMLを指定しなければならない、(すなわち、ソースは断片化してください。
Boyer, et al. Informational [Page 12] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[12ページ]のRFC3741
and target) or define the node-set processing (i.e., removal, replacement, and insertion) with respect to default namespace declarations (e.g., xmlns="") and XML attributes (e.g., xml:lang, xml:space, and xml:base).
そして、「目標)、デフォルト名前空間宣言に関してノードに設定された処理(すなわち、取り外し、交換、および挿入)を定義してください、(例えば、xmlns=、」、」、)、そして、XML属性(xml: 例えば、lang、xml: スペース、およびxml: ベース)。
5.2. 'Esoteric' Node-sets
5.2. '難解な'ノードセット
Consider an application that might use this specification or [XML- C14N] to serialize a single attribute node. An implementation of either specification will not emit a namespace declaration for that single attribute node. Consequently, a "carefully constructed" transform should create a node-set containing the attribute and the relevant namespace declaration for serialization.
この仕様か[XML- C14N]を使用するかもしれないアプリケーションがただ一つの属性ノードを連載すると考えてください。 仕様の実装はそのただ一つの属性ノードのための名前空間宣言を放たないでしょう。 その結果、連載のための属性と関連名前空間宣言を含んでいて、「慎重に組み立てられた」変換はノードセットを創設するべきです。
This example is provided to caution that as one moves beyond well- formed [XML] and then well-balanced XML [XML-Fragment], it becomes increasingly difficult to create a result that "is meaningful and unambiguous in its application context."
井戸を超えた1つの移動は[XML]を形成して、次に、バランスの良いXMLを形成したとき[XML-断片]「アプリケーション文脈で重要であり明白な」結果を作成するのがますます難しくなると警告するためにこの例を提供します。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[Keywords] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」という[キーワード]ブラドナー、S.、BCP14、RFC2119、1997年3月。
[XML] Extensible Markup Language (XML) 1.0 (Second Edition).
T. Bray, E. Maler, J. Paoli, and C. M. Sperberg-
McQueen. W3C Recommendation, October 2000. Available
at http://www.w3.org/TR/2000/REC-xml-20001006
[XML]拡張マークアップ言語(XML)1.0(第2版。) T。 ロバの鳴き声、E.Maler、J.パオリ、およびC.M.Sperbergマックィーン。 2000年10月のW3C推薦。 http://www.w3.org/TR/2000/REC-xml-20001006 では、利用可能です。
[XML-C14N] Boyer, J., "Canonical XML", RFC 3076, March 2001.
Also a W3C Recommendation available at
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
2001年のJ.、「正準なXML」、RFC3076行進の[XML-C14N]ボワイエ。 http://www.w3.org/TR/2001/REC-xml-c14n-20010315 で利用可能なW3C Recommendationも
[XML-NS] Namespaces in XML. T. Bray, D. Hollander, and A.
Layman. W3C Recommendation, January 1999. Available
at http://www.w3.org/TR/1999/REC-xml-names-19990114/
[XML-ナノ秒] XMLの名前空間。 T。 ロバの鳴き声、D.オランダ人、およびA.俗人。 W3C推薦、1999年1月。 http://www.w3.org/TR/1999/REC-xml-names-19990114/ では、利用可能です。
[XML-schema] XML Schema Part 1: Structures D. Beech, M. Maloney, N.
Mendelsohn, and H. Thompson. W3C Recommendation, May
2001. Available at http://www.w3.org/TR/2001/REC-
xmlschema-2-20010502/
[XML-図式] XML図式第1部: Structures D.ぶな、M.マローニー、N.メンデルゾーン、およびH.トンプソン。 2001年5月のW3C推薦。 http://www.w3.org/TR/2001/REC- xmlschema-2-20010502/では、利用可能です。
[XPath] XML Path Language (XPath) Version 1.0. J. Clark and S.
DeRose. W3C Recommendation, November 1999. Available
at http://www.w3.org/TR/1999/REC-xpath-19991116
[XPath]XML経路言語(XPath)バージョン1.0。 J。 クラークとS.DeRose。 1999年11月のW3C推薦。 http://www.w3.org/TR/1999/REC-xpath-19991116 では、利用可能です。
Boyer, et al. Informational [Page 13] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[13ページ]のRFC3741
6.2. Informative References
6.2. 有益な参照
[URI] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998.
[URI]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[XInclude] XML Inclusions (XInclude) Version 1.0. J. Marsh, and
D. Orchad. W3C Candidate Recommendation, February
2002. Available at http://www.w3.org/TR/2002/CR-
xinclude-20020221/
[XInclude]XML包含(XInclude)バージョン1.0。 J。 沼地、およびD.Orchad。 2002年2月のW3C候補推薦。 http://www.w3.org/TR/2002/CR- xinclude-20020221/では、利用可能です。
[XML-DSig] Eastlake, D., Reagle, J. and D. Solo, "XML-Signature
Syntax and Processing", RFC 3275, March 2002.
Available at http://www.w3.org/TR/2002/REC-xmldsig-
core-20020212/
[XML-DSig] イーストレーク、D.、Reagle、J.、D.独奏、および「XML-署名構文と処理」(RFC3275)は2002を行進させます。 http://www.w3.org/TR/2002/REC-xmldsig- コア-20020212/では、利用可能です。
[XML-Enc] XML Encryption Syntax and Processing. D. Eastlake,
and J. Reagle. W3C Candidate Recommendation, March
2002. Available at http://www.w3.org/TR/2002/CR-
xmlenc-core-20020304/
[XML-Enc]XML暗号化構文と処理。 D。 イーストレーク、およびJ.Reagle。 2002年3月のW3C候補推薦。 http://www.w3.org/TR/2002/CR- xmlencコア20020304/では、利用可能です。
[XML-Fragment] XML Fragment Interchange. P. Grosso, and D.
Veillard. W3C Candidate Recommendation, February
2001. Available at http://www.w3.org/TR/2001/CR-xml-
fragment-20010212
[XML-断片]XMLは置き換えを断片化します。 P。 グロッソ、およびD.Veillard。 2001年2月のW3C候補推薦。 http://www.w3.org/TR/2001/CR-xml- 断片-20010212では、利用可能です。
7. Acknowledgements (Informative)
7. 承認(有益)です。
The following people provided valuable feedback that improved the quality of this specification:
以下の人々はこの仕様の品質を改良した有益なフィードバックを提供しました:
* Merlin Hughes, Baltimore
* Thomas Maslen, DSTC
* Paul Denning, MITRE
* Christian Geuer-Pollmann, University Siegen
* Bob Atkinson, Microsoft
* マーリン・ヒューズ、ボルチモア*トーマスMaslen、DSTC*ポール・デニング、斜め継ぎ*クリスチャンGeuer-ポルマン、大学のジーゲン*ボブ・アトキンソン、マイクロソフト
Boyer, et al. Informational [Page 14] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[14ページ]のRFC3741
Authors' Addresses
作者のアドレス
John Boyer PureEdge Solutions Inc. 4396 West Saanich Rd. Victoria, BC, Canada V8Z 3E9
ジョンボワイエPureEdgeソリューションInc.4396の西サーニッチ通り 紀元前、9歳のカナダV8Z3Eビクトリア
Phone: +1-888-517-2675 EMail: jboyer@PureEdge.com
以下に電話をしてください。 +1-888-517-2675 メールしてください: jboyer@PureEdge.com
Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ155ビーバー通りMA01757ミルフォード(米国)
Phone: +1-508-634-2066 (h)
+1-508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
以下に電話をしてください。 +1-508-634-2066 (h) +1-508-786-7554 (w) メールしてください: Donald.Eastlake@motorola.com
Joseph M. Reagle Jr., W3C Massachusetts Institute of Technology Laboratory for Computer Science NE43-350, 545 Technology Square Cambridge, MA 02139
ジョゼフM.Reagle Jr.、W3Cマサチューセッツ工科大学コンピュータ科学研究所NE43-350、545技術の正方形のケンブリッジ、MA 02139
Phone: +1-617-258-7621 EMail: reagle@mit.edu
以下に電話をしてください。 +1-617-258-7621 メールしてください: reagle@mit.edu
Boyer, et al. Informational [Page 15] RFC 3741 Exclusive XML Canonicalization March 2004
ボワイエ、他 2004年のXML Canonicalization行進のときに排他的な情報[15ページ]のRFC3741
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Boyer, et al. Informational [Page 16]
ボワイエ、他 情報[16ページ]
一覧
スポンサーリンク
