Network Working Group H. Maruyama
Request for Comments: 2803 K. Tamura
Category: Informational N. Uramoto
IBM
April 2000
Digest Values for DOM (DOMHASH)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This definition can be used for XML digital signature as well efficient replication of XML objects.
このメモは関係なく、XMLの表面ストリング変化のXMLオブジェクトのダイジェスト（ハッシュ）値の明確かつ明白な定義を規定します。この定義は、XMLデジタル署名並びにXMLオブジェクトの効率的な複製のために使用することができます。
Table of Contents
目次
1. Introduction............................................2
2. Digest Calculation......................................3
2.1. Overview..............................................3
2.2. Namespace Considerations..............................4
2.3. Definition with Code Fragments........................5
2.3.1. Text Nodes..........................................5
2.3.2. Processing Instruction Nodes........................6
2.3.3. Attr Nodes..........................................6
2.3.4. Element Nodes.......................................7
2.3.5. Document Nodes......................................9
3. Discussion..............................................9
4. Security Considerations.................................9
References................................................10
Authors' Addresses........................................10
Full Copyright Statement..................................11
The purpose of this document is to give a clear and unambiguous definition of digest (hash) values of the XML objects [XML]. Two subtrees are considered identical if their hash values are the same, and different if their hash values are different.
この文書の目的は、ダイジェスト（ハッシュ）XMLオブジェクト[XML]の値の明確かつ明白な定義を与えることです。そのハッシュ値が異なる場合、そのハッシュ値が同じであり、異なる場合、2つのサブツリーは同一とみなされます。
There are at least two usage scenarios of DOMHASH. One is as a basis for digital signatures for XML. Digital signature algorithms normally require hashing a signed content before signing. DOMHASH provides a concrete definition of the hash value calculation.
DOMHASHの少なくとも2つの使用シナリオがあります。一つは、XMLのデジタル署名のための基礎としてあります。デジタル署名アルゴリズムは通常、署名する前に署名したコンテンツをハッシングが必要です。 DOMHASHは、ハッシュ値計算の具体的な定義を提供します。
The other is to use DOMHASH when synchronizing two DOM structures [DOM]. Suppose that a server program generates a DOM structure which is to be rendered by clients. If the server makes frequent small changes on a large DOM tree, it is desirable that only the modified parts are sent over to the client. A client can initiate a request by sending the root hash value of the structure in the cache memory. If it matches with the root hash value of the current server structure, nothing needs be sent. If not, then the server compares the client hash with the older versions in the server's cache. If it finds one that matches the client's version of the structure, then it locates differences with the current version by recursively comparing the hash values of each node. This way, the client can receive only an updated portion of a large structure without requesting the whole thing.
他には、2つのDOM構造[DOM]を同期するときにDOMHASHを使用することです。サーバプログラムがクライアントによってレンダリングされるDOM構造を生成するとします。サーバーは、大規模なDOMツリーに頻繁に小さな変更を行った場合、唯一の変更部分がクライアントにオーバー送信されることが望ましいです。クライアントは、キャッシュメモリに構造のルートハッシュ値を送信することにより、要求を開始することができます。それは現在のサーバー構成のルートハッシュ値と一致した場合、何も送信されないことが必要。そうでない場合、サーバーは、サーバーのキャッシュに古いバージョンのクライアントハッシュを比較します。それは構造のクライアントのバージョンに一致するものを見つけた場合、それは再帰的に各ノードのハッシュ値を比較することにより、現在のバージョンとの違いを見つけます。この方法では、クライアントは、全体のことを要求することなく、大きな構造の更新部分のみを受け取ることができます。
One way of defining digest values is to take a surface string as the input for a digest algorithm. However, this approach has several drawbacks. The same internal DOM structure may be represented in may different ways as surface strings even if they strictly conform to the XML specification. Treatment of white spaces, selection of character encodings, entity references (i.e., use of ampersands), and so on have impact on the generation of a surface string. If the implementations of surface string generation are different, the hash values would be different, resulting in unvalidatable digital signatures and unsuccessful detection of identical DOM structures. Therefore, it is desirable that digest of DOM is defined in the DOM terms -- that is, as an unambiguous algorithm operating on a DOM tree. This is the approach we take in this specification.
ダイジェスト値を定義する一つの方法は、ダイジェストアルゴリズムの入力として表面文字列を取ることです。しかし、このアプローチにはいくつかの欠点があります。彼らは厳密にはXML仕様に準拠していても同じ内部DOM構造は、表面の文字列として5月の異なる方法で表すことができます。ホワイトスペースの治療、文字コードの選択、エンティティ参照（すなわち、アンパサンドの使用）など表面列の生成に影響を与えます。表面列生成の実装が異なる場合、ハッシュ値はunvalidatableデジタル署名と同一のDOM構造の失敗検出をもたらす、異なるであろう。つまり、DOMツリー上で動作する明確なアルゴリズムとして - したがって、DOMのダイジェストは、DOMの用語で定義されていることが望ましいです。これは、私たちがこの仕様で取るアプローチです。
Introduction of namespace is another source of variation of surface string because different namespace prefixes can be used for representing the same namespace URI [URI]. In the following example, the namespace prefix "edi" is bound to the URI "http://ecommerce.org/schema" but this prefix can be arbitrary chosen without changing the logical contents as shown in the second example.
異なる名前空間接頭辞が同じ名前空間URI [URI]を表すために使用することができるので、名前空間の導入は、表面ストリングの変化の別の供給源です。次の例では、名前空間接頭辞「EDIは、」URI「http://ecommerce.org/schema」に結合されているが、この接頭辞は、実施例2に示すように、論理的内容を変更することなく、選択された任意とすることができます。
<?xml version="1.0"?> <root xmlns:edi='http://ecommerce.org/schema'> <edi:order> : </edi:order> </root>
<？xmlのバージョン= "1.0"> <ルートのxmlns：EDI = 'のhttp：//ecommerce.org/schema'> <EDI：オーダー>：</ EDI：オーダー> </ルート>
<?xml version="1.0"?> <root xmlns:ec='http://ecommerce.org/schema'> <ec:order> : </ec:order> </root>
<？xmlのバージョン= "1.0"> <ルートのxmlns：EC = 'のhttp：//ecommerce.org/schema'> <EC：オーダー>：</ EC：オーダー> </ルート>
The DOMHASH defined in this document is designed so that the choice of the namespace prefix does not affect the digest value. In the above example, both the "root" elements will get the same digest value.
名前空間接頭辞の選択は、ダイジェスト値に影響を与えないように、この文書で定義されたDOMHASHが設計されています。上記の例では、両方の「ルート」要素には同一のダイジェスト値を取得します。
Hash values are defined on the DOM type Node. We consider the following five node types that are used for representing a DOM document structure:
ハッシュ値は、DOMのNode型で定義されています。私たちは、DOMドキュメント構造を表すために使用されている次の5つのノードの種類を考慮してください。
- Text - ProcessingInstruction - Attr - Element - Document
- テキスト - 処理命令 - のAttr - 要素 - ドキュメント
Comment nodes and Document Type Definitions (DTDs) do not participate in the digest value calculation. This is because DOM does not require a conformant processor to create data structures for these. DOMHASH is designed so that it can be computed with any XML processor conformant to the DOM or SAX [SAX] specification.
コメントノードと文書型定義（DTDは）ダイジェスト値の計算には関与しません。 DOMは、これらのデータ構造を作成するために準拠プロセッサを必要としないためです。それはDOMまたはSAX [SAX]仕様に準拠任意のXMLプロセッサで計算することができるようにDOMHASHに設計されています。
Nodes with the node type EntityReference must be expanded prior to digest calculation.
ノードタイプのEntityReferenceを有するノードは、ダイジェスト計算の前に展開されなければなりません。
The digest values are defined recursively on each level of the DOM tree so that only a relevant part needs to be recalculated when a small portion of the tree is changed.
唯一の関連する部分は、ツリーの小さな部分が変更されたときに再計算される必要があるように、ダイジェスト値は、DOMツリーの各レベルで再帰的に定義されています。
Below, we give the precise definitions of digest for these types. We describe the format of the data to be supplied to a hash algorithm using a figure and a simple description, followed by a Java code fragment using the DOM API and the JDK 1.1 Platform Core API only. Therefore, the semantics should be unambiguous.
以下では、これらのタイプのダイジェストの正確な定義を与えます。我々は、DOM APIを使用してJavaコード断片とJDK 1.1プラットフォームコアAPIのみ続く図及び簡単な説明を使用してハッシュアルゴリズムに供給されるデータのフォーマットを記述する。したがって、意味は明確なはずです。
As the rule of thumb, all strings are to be in UTF-16BE [UTF16]. If there is a sequence of text nodes without any element nodes in between, these text nodes are merged into one by concatenating them. A zero-length text node is always ignored.
経験則として、すべての文字列はUTF-16BE [UTF16]にあるとされています。その間の任意の要素ノードのないテキストノードのシーケンスがある場合、これらのテキスト・ノードは、それらを連結して一つにマージされます。ゼロ長のテキストノードは常に無視されます。
Note that validating and non-validating XML processors may generate different DOM trees from the same XML document, due to attribute normalization and default attributes. If DOMHASH is to be used for testing logical equivalence between two XML documents (as opposed to DOM trees), it may be necessary to normalize attributes and supply default attributes prior to DOMHASH calculation.
なお、検証及び妥当性を検証しないXMLプロセッサは、正規化し、デフォルトの属性を属性に起因する同じXMLドキュメントから別のDOMツリーを生成することができます。 DOMHASHは、2つのXML文書（DOMツリーとは対照的に）との間の論理等価性をテストするために使用される場合、前DOMHASH計算に属性と供給デフォルト属性を正規化する必要があるかもしれません。
Some legacy character encodings (such as ISO-2022-JP) have certain ambiguity in translating into Unicode. This is again dependent on XML processors. Treatment of such processor dependencies is out of scope of this document.
（例えばISO-2022-JPなど）一部のレガシー文字エンコーディングは、Unicodeに変換するには一定のあいまいさを持っています。これは、XMLプロセッサに再び依存しています。そのようなプロセッサの依存関係の処理は、この文書の範囲外です。
To avoid the dependence on the namespace prefix, we use "expanded names" to do digest calculation. If an element name or an attribute name is qualified either by a explicit namespace prefix or by a default namespace, the name's LocalPart is prepended by the URI of the namespace (the namespace name as defined in the Namespace specification [NAM]) and a colon before digest calculation. In the following example, the default qualified name "order" is expanded into "http://ecommerce.org/schema:order" while the explicit qualified name "book:title" is expanded into "urn:loc.gov:books:title" before digest calculation.
名前空間接頭辞への依存を避けるために、我々は、ダイジェスト計算を行うために、「拡大の名前」を使用します。要素名や属性名が明示的な名前空間接頭辞またはデフォルトの名前空間のいずれかによって修飾されている場合、名前のローカルパートは、名前空間のURI（名前空間仕様で定義されている名前空間名[NAM]）とコロンが先頭に追加されます前ダイジェスト計算。次の例では、デフォルトの修飾名「注文」は、明示的な修飾名ながら「http://ecommerce.org/schema:order」に展開される「ブック：タイトルは」壷」に展開されます。loc.gov：図書：タイトルは」前にダイジェスト計算。
<?xml version="1.0"?>
<？xml version = "1.0"？>
<root xmlns='http://ecommerce.org/schema' xmlns:book='urn:loc.gov:books'> <order> <book:title> ... </book:title> : </order> </root>
<ルートのxmlns = 'のhttp：//ecommerce.org/schema' のxmlns：ブック= 'URN：loc.gov：図書'> <オーダー> <ブック：タイトル> ... </書籍：タイトル>：</オーダー> </ルート>
We define an expanded name (either for element or attribute) as follows:
次のように私たちは（どちらかの要素や属性の）拡張名を定義します。
If a name is not qualified, the expanded name is the name itself.
名前が修飾されていない場合は、拡張名は名前そのものです。
If a name is qualified with the prefix "xmlns", the expanded name is undefined.
名前が接頭辞「のxmlns」で修飾されている場合は、拡張名が定義されていません。
If a name is qualified either by default or by an explicit namespace prefix, the expanded name is URI bound to the namespace + ":" + LocalPart
「：」+ローカルパート名は、デフォルトでは、明示的または名前空間接頭辞のいずれかによって修飾されている場合、拡張名は、URI名前空間+にバインドされています
In the following example code, we assume that the getExpandedName() method (which returns the expanded name as defined above) is defined in both Element and Attr interfaces of DOM.
次のコード例では、我々は、（上記で定義した拡張名を返す）GETEXPANDEDNAME（）メソッドは、DOMの両方の要素とのAttrインタフェースで定義されていると仮定する。
Note that the digest values are not defined on namespace declarations. In other words, the digest value is not defined for an attribute when
ダイジェスト値は、名前空間宣言で定義されていないことに注意してください。言い換えれば、ダイジェスト値は、属性ときのために定義されていません
- the attribute name is "xmlns", or - the namespace prefix is "xmlns".
- 属性名は「のxmlns」である、または - 名前空間接頭辞は「のxmlns」です。
In the above example, the two attributes which are namespace declarations do not have digest values and therefore will not participate in the calculation of the digest value of the "root" element.
上記の例では、名前空間宣言である2つの属性が値を消化し、従って「ルート」要素のダイジェスト値の計算に参加しない持っていません。
The code fragments in the definitions below assume that they are in implementation classes of Node. Therefore, a methods call without an explicit object reference is for the Node itself. For example, getData() returns the text data of the current node if it is a Text node. The parameter digestAlgorithm is to be replaced by an identifier of the digest algorithm, such as "MD5" [MD5] and "SHA-1" [SHA].
下記の定義でのコードフラグメントは、彼らがノードの実装クラスであることを前提としています。したがって、方法は、明示的なオブジェクト参照がノード自体のためのものであることなく呼び出します。それがテキストノードである場合、例えば、のgetData（）は、現在のノードのテキストデータを返します。パラメータdigestAlgorithmは、「MD5」[MD5]及び「SHA-1」[SHA]として、ダイジェストアルゴリズムの識別子によって置き換えられます。
The computation should begin with a four byte integer that represents the type of the node, such as TEXT_NODE or ELEMENT_NODE.
計算は、TEXT_NODEまたはELEMENT_NODEように、ノードのタイプを表す4つのバイトの整数で開始すべきです。
The hash value of a Text node is computed on the four byte header followed by the UTF-16BE encoded text string.
テキストノードのハッシュ値は、UTF-16BEエンコードされたテキスト文字列に続く4バイトのヘッダ上で計算されます。
- TEXT_NODE (3) in 32 bit network-byte-ordered integer
- Text data in UTF-16BE stream (variable length) public byte[] getDigest(String digestAlgorithm) {
MessageDigest md = MessageDigest.getInstance(digestAlgorithm);
md.update((byte)0);
md.update((byte)0);
md.update((byte)0);
md.update((byte)3);
md.update(getData().getBytes("UnicodeBigUnmarked"));
return md.digest();
}
Here, MessageDigest is in the package java.security.*, one of the built-in packages of JDK 1.1.
ここでは、するMessageDigestは、パッケージjava.securityである。*、JDK 1.1のビルトインパッケージの一つ。
A ProcessingInstruction (PI) node has two components: the target and the data. Accordingly, the hash is computed on the concatenation of both, separated by 'x0000'. PI data is from the first non white space character after the target to the character immediately preceding the "?>".
対象データ：処理命令（PI）ノードは、2つの成分を有しています。したがって、ハッシュは「X0000」で区切られた、両方の連結に計算されます。 PIデータはすぐに「？>」の前の文字に、ターゲットの後の最初の非空白文字からです。
- PROCESSING_INSTRUCTION_NODE (7) in 32 bit network-byte-ordered integer - PI target in UTF-16BE stream (variable length) - 0x00 0x00 - PI data in UTF-16BE stream (variable length)
- PROCESSING_INSTRUCTION_NODE（7）32ビットにネットワークバイト順の整数 - UTF-16BEストリームにおけるPIターゲット（可変長） - は0x00は0x00 - UTF-16BEストリームにおけるPIデータ（可変長）
public byte[] getDigest(String digestAlgorithm) {
MessageDigest md = MessageDigest.getInstance(digestAlgorithm);
md.update((byte)0);
md.update((byte)0);
md.update((byte)0);
md.update((byte)7);
md.update(getName().getBytes("UnicodeBigUnmarked"));
md.update((byte)0);
md.update((byte)0);
md.update(getData().getBytes("UnicodeBigUnmarked"));
return md.digest();
}
The digest value of Attr nodes are defined similarly to PI nodes, except that we need a separator between the expanded attribute name and the attribute value. The '0x0000' value in UTF-16BE is allowed nowhere in an XML document, so it can serve as an unambiguous separator. The expanded name must be used as the attribute name because it may be qualified. Note that if the attribute is a namespace declaration (either the attribute name is "xmlns" or its prefix is "xmlns"), the digest value is undefined and the getDigest() method should return null.
私たちは、拡張属性名と属性値の間に区切りを必要とすることを除いてはAttrノードのダイジェスト値は、PIノードと同様に定義されています。 UTF-16BEの「0000」の値は、XML文書内のどこにも許されないので、明確な区切りとしての役割を果たすことができます。それが修飾することができるので、拡張名、属性名として使用する必要があります。属性は、名前空間宣言（いずれかの属性名は「のxmlns」であるか、その接頭辞は「のxmlns」である）であれば、ダイジェスト値が定義されていないとgetDigest（）メソッドはnullを返す必要があることに注意してください。
- ATTRIBUTE_NODE (2) in 32 bit network-byte-ordered integer - Expanded attribute name in UTF-16BE stream (variable length) - 0x00 0x00 - Attribute value in UTF-16BE stream (variable length)
- は0x00 0x00の - - UTF-16BEストリーム（可変長）に拡張属性名 - 32ビットのネットワークバイト順の整数でATTRIBUTE_NODE（2）UTF-16BEストリームの属性値（可変長）
public byte[] getDigest(String digestAlgorithm) {
if (getNodeName().equals("xmlns")
|| getNodeName().startsWith("xmlns:"))
return null;
MessageDigest md = MessageDigest.getInstance(digestAlgorithm);
md.update((byte)0);
md.update((byte)0);
md.update((byte)0);
md.update((byte)2);
md.update(getExpandedName().getBytes("UnicodeBigUnmarked"));
md.update((byte)0);
md.update((byte)0);
md.update(getValue().getBytes("UnicodeBigUnmarked"));
return md.digest();
}
Element nodes are the most complex because they consist of other nodes recursively. Hash values of these component nodes are used to calculate the node's digest so that we can save computation when the structure is partially changed.
彼らは再帰的に他のノードで構成されているので、要素ノードは、最も複雑です。これらのコンポーネントのノードのハッシュ値は、構造が部分的に変化させたとき、我々は、計算を節約することができるように、ノードのダイジェストを計算するために使用されます。
First, all the attributes except for namespace declarations must be collected. This list is sorted lexicographically by the expanded attribute names (based on Unicode character code points). When no surrogate characters are involved, this is the same as sorting in ascending order in terms of the UTF-16BE encoded expanded attribute names, using the string comparison operator String.compareTo() in Java.
まず、名前空間宣言を除くすべての属性を収集する必要があります。このリストは、（Unicode文字コード・ポイントに基づいて）、拡張属性名で辞書順にソートされます。何のサロゲート文字が関与していない場合、これはJavaで文字列比較演算子String.compareTo（）を使用して、属性名を展開してエンコードUTF-16BEの面で昇順にソートと同じです。
- ELEMENT_NODE (1) in 32 bit network-byte-ordered integer - Expanded element name in UTF-16BE stream (variable length) - 0x00 0x00 - A number of non-namespace-declaration attributes in 32 bit network-byte-ordered unsigned integer - Sequence of digest values of non-namespace-declaration attributes, sorted lexicographically by expanded attribute names - A number of child nodes (except for Comment nodes) in 32bit
0x00 0x00の - - UTF-16BEストリーム（可変長）で拡張要素名 - - 32ビットのネットワークバイト順の整数でELEMENT_NODE（1）非名前空間宣言の数は、32ビットのネットワークバイト順の符号なし整数の属性 - 32ビットで（Commentノードを除く）子ノードの数 - 非名前空間宣言属性のダイジェスト値のシーケンス、拡張された属性名で辞書順にソート
network-byte-ordered unsigned integer - Sequence of digest values of each child node except for Comment nodes (variable length) (A sequence of child texts is merged to one text. A zero-length text and Comment nodes are not counted as child)
ネットワークバイト順の符号なし整数 - コメントノード（可変長）を除く各子ノードのダイジェスト値のシーケンス（子テキストのシーケンスは、1つのテキストにマージされた長さゼロのテキストやコメントノードは子としてカウントされません。）
public byte[] getDigest(String digestAlgorithm) {
MessageDigest md = MessageDigest.getInstance(digestAlgorithm);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(baos);
dos.writeInt(ELEMENT_NODE);//This is stored in network byte order
dos.write(getExpandedName().getBytes("UnicodeBigUnmarked"));
dos.write((byte)0);
dos.write((byte)0);
// Collect all attributes except for namespace declarations
NamedNodeMap nnm = this.getAttributes();
int len = nnm.getLength()
// Find "xmlns" or "xmlns:foo" in nnm and omit it.
...
dos.writeInt(len); // This is sorted in the network byte order
// Sort attributes lexicographically by expanded attribute
// names.
...
// Assume that `Attr[] aattr' has sorted Attribute instances.
for (int i = 0; i < len; i ++)
dos.write(aattr[i].getDigest(digestAlgorithm));
Node n = this.getFirstChild();
// Assume that adjoining Texts are merged,
// there is no 0-length Text, and
// comment nodes are removed.
len = this.getChildNodes().getLength();
dos.writeInt(len); // This is stored in the network byte order
while (n != null) {
dos.write(n.getDigest(digestAlgorithm));
n = n.getNextSibling();
}
dos.close();
md.update(baos.toByteArray());
return md.digest();
}
A Document node may have PI nodes before and after the root Element node. The digest value of a Document node is computed based on the sequence of the digest values of the pre-root PI nodes, the root Element node, and the post-root PI nodes in this order. Comment nodes and DocumentType nodes, if any, are ignored.
Documentノードはルート要素ノードの前と後のPIノードを有することができます。ドキュメントノードのダイジェスト値がこの順で前のルートPIノード、ルート要素ノード、および後根PIノードのダイジェスト値の配列に基づいて計算されます。コメントノードとのDocumentTypeノードは、もしあれば、無視されます。
- DOCUMENT_NODE (9) in 32 bit network-byte-ordered integer - A number of child nodes (except for Comment and DocumentType nodes) in 32bit network-byte-ordered unsigned integer - Sequence of digest values of each child node except for Comment and DocumentType nodes (variable length)
- 32ビットネットワークバイト順の符号なし整数で（コメントとのDocumentTypeノードを除く）子ノードの数 - - 32ビットのネットワークバイト順の整数でDOCUMENT_NODE（9）コメントを除き、各子ノードのダイジェスト値のシーケンスとDocumentTypeノード（可変長）
public byte[] getDigest(String digestAlgorithm) {
MessageDigest md = MessageDigest.getInstance(digestAlgorithm);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(baos);
dos.writeInt(DOCUMENT_NODE);//This is stored in network byte order
// Assume that Comment and DocumentType nodes are removed and this
// node has only an Element node and PI nodes.
len = this.getChildNodes().getLength();
dos.writeInt(len); // This is stored in the network byte order
Node n = this.getFirstChild();
while (n != null) {
dos.write(n.getDigest(digestAlgorithm));
n = n.getNextSibling();
}
dos.close();
md.update(baos.toByteArray());
return md.digest();
}
The definition described above can be efficiently implemented with
any XML processor that is conformant to either DOM and SAX
specification. Reference implementations are available on request.
DOMHASH is expected to be used as the basis for digital signatures
and other security and integrity uses. It's appropriateness for
such uses depends on the security of the hash algorithm used and
inclusion of the fundamental characteristics it is desired to check
in parts of the DOM model incorporated in the digest by DOMHASH.
References
リファレンス
[DOM] "Document Object Model (DOM), Level 1 Specification", October 1998, http://www.w3.org/TR/REC-DOM-Level-1/
[DOM] "ドキュメントオブジェクトモデル（DOM）、レベル1の仕様"、1998年10月、http://www.w3.org/TR/REC-DOM-Level-1/
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest氏、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[NAM] Tim Bray, Dave Hollander, Andrew Layman, "Namespaces in XML", http://www.w3.org/TR/1999/REC-xml-names-19990114.
[NAM]ティム・ブレイ、デイブ・ホランダー、アンドリュー素人、 "XMLで名前空間"、http://www.w3.org/TR/1999/REC-xml-names-19990114。
[SAX] David Megginson, "SAX 1.0: The Simple API for XML", http://www.megginson.com/SAX/, May 1998.
[SAX]デイビット・メギンソン、 "SAX 1.0：XMLのためのシンプルなAPI"、http://www.megginson.com/SAX/、1998年5月。
[SHA] (US) National Institute of Standards and Technology, "Federal Information Processing Standards Publication 180-1: Secure Hash Standard", 17 April 1995.
[SHA]（US）アメリカ国立標準技術研究所、「連邦情報処理規格180-1出版：セキュアハッシュ標準」、1995年4月17日。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[UTF16] Hoffman, P., Yergeau, F., "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[UTF16]ホフマン、P.、Yergeau、F.、 "UTF16、ISO 10646の符号化"、RFC 2781、2000年2月。
[XML] Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible Markup Language (XML) 1.0", http://www.w3.org/TR/1998/REC-xml-19980210
[XML]ティム・ブレイ、ジーン・パオリ、C. M. Sperber-マックイーン、 "拡張マークアップ言語（XML）1.0"、http://www.w3.org/TR/1998/REC-xml-19980210
Authors' Addresses
著者のアドレス
Hiroshi Maruyama, IBM Research, Tokyo Research Laboratory
宏丸山、IBM東京基礎研究所
EMail: maruyama@jp.ibm.com
メールアドレス：maruyama@jp.ibm.com
Kent Tamura, IBM Research, Tokyo Research Laboratory
ケント田村、IBM東京基礎研究所
EMail: kent@trl.ibm.co.jp
メールアドレス：kent@trl.ibm.co.jp
Naohiko Uramoto, IBM Research, Tokyo Research Laboratory
直彦Uramoto、IBM東京基礎研究所
EMail: uramoto@jp.ibm.com
メールアドレス：uramoto@jp.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgment
了承
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。