RFC2803 日本語訳

Network Working Group                                         H. Maruyama
Request for Comments: 2803                                      K. Tamura
Category: Informational                                        N. Uramoto
                                                                      IBM
                                                               April 2000

コメントを求めるワーキンググループH.丸山の要求をネットワークでつないでください: 2803年のK.田村カテゴリ: 情報のN.浦本IBM2000年4月

                    Digest Values for DOM (DOMHASH)

DOMのために値を読みこなしてください。(DOMHASH)

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 (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

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

1. 序論…2 2. 計算を読みこなしてください…3 2.1. 概要…3 2.2. 名前空間問題…4 2.3. コードとの定義は断片化します…5 2.3.1. テキストノード…5 2.3.2. 処理命令ノード…6 2.3.3. Attrノード…6 2.3.4. 要素ノード…7 2.3.5. ノードを記録してください…9 3. 議論…9 4. セキュリティ問題…9つの参照箇所…10人の作者のアドレス…10 完全な著作権宣言文…11

Maruyama, et al.             Informational                      [Page 1]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[1ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

1. Introduction

1. 序論

   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のためのデジタル署名の基礎として1つがあります。 通常、デジタル署名アルゴリズムは、署名の前に署名している内容を論じ尽くすのを必要とします。 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.

ダイジェスト値を定義する1つの方法はダイジェストアルゴリズムのための入力として表面ストリングをみなすことです。 しかしながら、このアプローチには、いくつかの欠点があります。 内部のDOM構造が表されるかもしれない同じくらいは結ぶかもしれません。厳密にXML仕様に従っても、表面としての異なった道は結びます。 余白の処理、文字符号化の品揃え、実体参照(すなわち、アンパーサンドの使用)などは表面ストリングの世代に影響力を持っています。 表面ストリング世代の実装が異なるなら、ハッシュ値は異なっているでしょう、同じ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番目の例に示されるように論理的なコンテンツを変えないで選ばれた状態で任意である場合があります。

Maruyama, et al.             Informational                      [Page 2]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[2ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

    <?xml version="1.0"?>
    <root xmlns:edi='http://ecommerce.org/schema'>
        <edi:order>
            :
        </edi:order>
    </root>

<?xmlバージョン= 「1インチ?」><根の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インチ?」><根の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は、名前空間接頭語の選択がダイジェスト値に影響しないように、設計されています。 上記の例では、両方の「根」要素は同じダイジェスト値を得るでしょう。

2. Digest Calculation

2. ダイジェスト計算

2.1. Overview

2.1. 概要

   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

- テキスト--ProcessingInstruction--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.

コメントノードとDocument Type Definitions(DTD)はダイジェスト値の計算に参加しません。 これはDOMがこれらのためにデータ構造を作成するためにconformantプロセッサを必要としないからです。 DOMHASHは、どんなXMLプロセッサconformantでもDOMかSAX[SAX]仕様にそれを計算できるように設計されています。

   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ツリーの各レベルで再帰的に定義されるので、関連部分だけが、木の少量を変えるとき、再計算する必要があります。

Maruyama, et al.             Informational                      [Page 3]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[3ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

   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.

以下に、私たちはこれらのタイプのためにダイジェストの厳密な定義を与えます。 私たちは、Javaコード断片がDOM APIとJDK1.1Platform Core 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]にあることです。 テキストノードの系列が中間で少しも要素ノードなしであれば、これらのテキストノードは、それらを連結することによって、1つに合併されています。 ゼロ・レングステキストノードはいつも無視されます。

   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.

いくつかのレガシー文字符号化(ISO2022JPなどの)がユニコードに翻訳する際にあるあいまいさを持っています。 これは再び、XMLプロセッサに依存しています。 このドキュメントの範囲の外にそのようなプロセッサの依存の処理があります。

2.2. Namespace Considerations

2.2. 名前空間問題

   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.

名前空間接頭語への依存を避けるなら、私たちは、計算を読みこなすのに「拡張名前」を使用します。 要素名か属性名が明白な名前空間接頭語かデフォルト名前空間によって資格があるなら、名前のLocalPartはダイジェスト計算の前に名前空間(Namespace仕様[NAM]に基づき定義される名前空間名)のURIとコロンによってprependedされます。 以下の例、資格があったデフォルトで、名前「オーダー」は明白な適切な名前である間、" http://ecommerce.org/schema:order "に広げられて、「本: タイトル」がダイジェスト計算の前に「つぼ:loc.gov:本: タイトル」に広げられるということです。

   <?xml version="1.0"?>

<?xmlバージョン= 「1インチ?」>。

   <root xmlns='http://ecommerce.org/schema'
            xmlns:book='urn:loc.gov:books'>
       <order>
          <book:title> ... </book:title>
           :
       </order>
   </root>

<根のxmlnsは''xmlns: ='つぼ:loc.gov:本を予約してください'という http://ecommerce.org/schema ><オーダー><の本: タイトル>…'と等しいです。 </本: タイトル>: </オーダー></根の>。

Maruyama, et al.             Informational                      [Page 4]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[4ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

   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です」:、」 + LocalPart

   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()メソッド(上で定義されるように拡張名前を返す)がElementと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つの属性は、ダイジェスト値を持たないで、またしたがって、「根」要素のダイジェスト価値の計算に参加しないでしょう。

2.3. Definition with Code Fragments

2.3. コード断片との定義

   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].

以下での定義におけるコード断片は、Nodeの実装のクラスにはそれらがあると仮定します。 したがって、明白なオブジェクト参照のないメソッド呼び出しはNode自身のためのものです。 例えば、getData()はそれがTextノードであるなら現在のノードに関するテキストデータを返します。 パラメタ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.

計算はノードのタイプの代理をする4バイトの整数で始まるべきです、TEXT_NODEやELEMENT_NODEのように。

2.3.1. Text Nodes

2.3.1. テキストノード

   The hash value of a Text node is computed on the four byte header
   followed by the UTF-16BE encoded text string.

Textノードのハッシュ値はコード化されたテキストが結ぶUTF-16BEによって続かれた4バイトのヘッダーの上に計算されます。

   - TEXT_NODE (3) in 32 bit network-byte-ordered integer
   - Text data in UTF-16BE stream (variable length)

- 32ビットの注文されたネットワークバイト整数におけるTEXT_NODE(3)--UTF-16BEのテキストデータは流れます。(可変長)

Maruyama, et al.             Informational                      [Page 5]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[5ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

   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();
   }

公共のバイト[]getDigest(ストリングdigestAlgorithm)MessageDigest MdはMessageDigest.getInstance(digestAlgorithm)と等しいです; md.update((バイト)0); md.update((バイト)0); md.update((バイト)0); md.update((バイト)3); md.update(getData().getBytes("UnicodeBigUnmarked")); リターンmd.digest()

   Here, MessageDigest is in the package java.security.*, one of the
   built-in packages of JDK 1.1.

ここで、MessageDigestはjava.security*、パッケージの中にJDK1.1の内蔵のパッケージの1つです。

2.3.2. ProcessingInstruction Nodes

2.3.2. ProcessingInstructionノード

   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 "?>".

ProcessingInstruction(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)

- 32ビットの注文されたネットワークバイト整数(UTF-16BEストリーム(可変長)におけるPI目標)におけるPROCESSING_INSTRUCTION_NODE(7)、0×00、0×00、--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();
   }

公共のバイト[]getDigest(ストリング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(); }

2.3.3. Attr Nodes

2.3.3. Attrノード

   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

Attrノードのダイジェスト値は同様にPIノードと定義されます、私たちが拡張属性名と属性値の間の分離符を必要とするのを除いて。 UTF-16BEの'0×0000'値がXMLドキュメントでどこにも許容されていないので、それは明白な分離符として機能できます。 それは資格があるかもしれないので、属性名として拡張名前を使用しなければなりません。 属性がaであるならそれに注意してください。

Maruyama, et al.             Informational                      [Page 6]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[6ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

   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.

名前空間宣言(属性名は"xmlns"であるか接頭語は"xmlns"である)、ダイジェスト値は未定義です、そして、getDigest()メソッドはヌルを返すべきです。

   - 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)

- 32におけるATTRIBUTE_NODE(2)は注文されたネットワークバイト整数に噛み付きました--UTF-16BEストリーム(可変長)における属性名を広げます--、0×00、0×00、--Attributeが中で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();
   }

公共のバイト[]getDigest(ストリング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(); }

2.3.4. Element Nodes

2.3.4. 要素ノード

   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.

まず最初に、名前空間宣言以外のすべての属性を集めなければなりません。 このリストは拡張属性名(ユニコード文字コード・ポイントに基づいている)によって辞書編集に分類されます。 どんな代理のキャラクタもかかわらないとき、これは昇順にUTF-16BEに関するソーティングが拡張属性名をコード化したのと同じです、Javaにストリング比較オペレータString.compareTo()を使用して。

   - 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

- 32におけるELEMENT_NODE(1)は注文されたネットワークバイト整数に噛み付きました--UTF-16BEストリーム(可変長)における要素名を広げます--、0×00、0×00、非名前空間の宣言属性のダイジェスト値の--注文されたバイトをネットワークでつないでいる32噛み付いている符号のない整数における多くの非名前空間の宣言属性--系列、分類された辞書編集は属性名を広げました--32における多くの子供ノード(Commentノードを除いた)が噛み付きました。

Maruyama, et al.             Informational                      [Page 7]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[7ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

     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)

注文されたバイトをネットワークでつないでいる符号のない整数--Commentノード(可変長)以外のそれぞれの子供ノードのダイジェスト値の系列(子供テキストの系列は1つのテキストに合併されています。 ゼロ・レングステキストとCommentノードは子供にみなされません。)

   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();
   }

公共のバイト[] 最もgetDigestです(ストリングdigestAlgorithm)。{ MessageDigest MdはMessageDigest.getInstance(digestAlgorithm)と等しいです。 ByteArrayOutputStreamバオは新しいByteArrayOutputStream()と等しいです。 DataOutputStream dosは新しいDataOutputStream(バオ)と等しいです。 dos.writeInt(ELEMENT_NODE); これが保存される//はバイトオーダーdos.write(getExpandedName().getBytes("UnicodeBigUnmarked"))をネットワークでつなぎます。 dos.write((バイト)0)。 dos.write((バイト)0)。 //は名前空間宣言NamedNodeMap nnm=this.getAttributes()以外のすべての属性を集めます。 int len=nnm.getLength()//は、nnmで"xmlns"か「xmlns: foo」を見つけて、それを省略します。 …dos.writeInt(len)。 これが分類されるネットワークバイトオーダー//が分類する広げられるのによる属性辞書編集が結果と考える//が命名する//。 ... //が、'Attr[] aattr'がAttributeインスタンスを分類したと仮定する、(int i=0。 i<len。 + +) i dos.write(aattr[i].getDigest(digestAlgorithm))。 ノードnはthis.getFirstChild()と等しいです。 //は、隣接しているTextsが合併されていて、そこの//が0長さのTextでなく、//コメントノードが取り除かれると仮定します。lenはthis.getChildNodes().getLength()と等しいです。 dos.writeInt(len)。 これが保存されるネットワークバイトオーダーがゆったり過ごす//(n!=ヌル)、dos.write(n.getDigest(digestAlgorithm))。 nはn.getNextSibling()と等しいです。 dos.close()。 md.update、(baos.toByteArray())。 md.digest()を返してください。 }

Maruyama, et al.             Informational                      [Page 8]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[8ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

2.3.5. Document Nodes

2.3.5. ドキュメントノード

   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ノードには、根のElementノードの前後に、PIノードがあるかもしれません。 Documentノードのダイジェスト値はプレ根のPIノード、根のElementノード、およびポスト根の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ビットの注文されたネットワークバイト整数におけるDOCUMENT_NODE(9)--注文されたバイトをネットワークでつないでいる32噛み付いている符号のない整数における多くの子供ノード(CommentとDocumentTypeノードを除いた)--Comment以外のそれぞれの子供ノードと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

公共のバイト[]getDigest(ストリングdigestAlgorithm)、MessageDigest MdはMessageDigest.getInstance(digestAlgorithm)と等しいです; ByteArrayOutputStreamバオは新しいByteArrayOutputStream()と等しいです; DataOutputStream dosは新しいDataOutputStream(バオ); dos.writeInt(DOCUMENT_NODE); //とネットワークバイトオーダーで保存されていた状態で等しいです。

         // 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();
     }

//は、CommentとDocumentTypeノードが取り外されると仮定します、そして、この//ノードには、ElementノードとPIノードしかありません。lenはthis.getChildNodes().getLength()と等しいです。 dos.writeInt(len)。 //、これはネットワークバイトオーダーNode n=this.getFirstChild()に保存されます。 (n!=ヌル)dos.write(n.getDigest(digestAlgorithm)); n=n.getNextSibling();dos.close()である間。 md.update、(baos.toByteArray())。 md.digest()を返してください。 }

3. Discussion

3. 議論

     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.

DOMとSAX仕様へのconformantであるどんなXMLプロセッサでも効率的に上で説明された定義は実装することができます。 参照実装は要求に応じて利用可能です。

4. Security Considerations

4. セキュリティ問題

     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.

デジタル署名、他のセキュリティ、および保全用途の基礎としてDOMHASHが使用されると予想されます。 そのような用途のための適切さが使用されるハッシュアルゴリズムのセキュリティによるということです、そして、DOMモデルの部分でチェックするのが必要である基本的な特性の包含はDOMHASHによるダイジェストで盛込まれました。

Maruyama, et al.             Informational                      [Page 9]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[9ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

References

参照

   [DOM]   "Document Object Model (DOM), Level 1 Specification", October
         1998, http://www.w3.org/TR/REC-DOM-Level-1/

1998年10月の[DOM]「レベル1 文書オブジェクト・モデル(DOM)、仕様」、 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メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。

   [NAM]   Tim Bray, Dave Hollander, Andrew Layman, "Namespaces in XML",
         http://www.w3.org/TR/1999/REC-xml-names-19990114.

[NAM] ティムBray、デーヴHollander、アンドリューLayman、「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]デヴィッドMegginson、「SAX1.0:」 「XMLのための簡単なAPI」( http://www.megginson.com/SAX/ )は1998がそうするかもしれません。

   [SHA]   (US) National Institute of Standards and Technology, "Federal
         Information Processing Standards Publication 180-1: Secure Hash
         Standard", 17 April 1995.

[SHA](米国)米国商務省標準技術局、「連邦政府の情報処理規格公表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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。

   [UTF16] Hoffman, P., Yergeau, F., "UTF-16, an encoding of ISO 10646",
         RFC 2781, February 2000.

[UTF16] 2000年2月のホフマン、P.、Yergeau、F.、「UTF-16、ISO10646のコード化」RFC2781。

   [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] ティムBray、ジーン・パオリ、C.M.スペルバー-マックィーン、「拡張マークアップ言語(XML)1インチ、 http://www.w3.org/TR/1998/REC-xml- 19980210」

Authors' Addresses

作者のアドレス

   Hiroshi Maruyama,
   IBM Research, Tokyo Research Laboratory

Hiroshi丸山、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

Naohiko浦本、IBMの研究、東京研究所

   EMail: uramoto@jp.ibm.com

メール: uramoto@jp.ibm.com

Maruyama, et al.             Informational                     [Page 10]

RFC 2803            Digest Values for DOM (DOMHASH)           April 2000

丸山、他 情報[10ページ]のRFC2803は2000年4月にドム(DOMHASH)のために値を読みこなします。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Maruyama, et al.             Informational                     [Page 11]

丸山、他 情報[11ページ]