この文書はRFC3597の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                      A. Gustafsson
Request for Comments: 3597                                  Nominum Inc.
Category: Standards Track                                 September 2003


           Handling of Unknown DNS Resource Record (RR) Types
            未知のDNS資源レコード(RR)タイプの取り扱い

Status of this Memo
この文書の状態


   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.
   この文書はインターネット共同体のためのインターネット標準化作業中のプ
   ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
   態とこのプロトコル状態は「インターネット公式プロトコル標準」(STD
   1)の現在の版を参照してください。このメモの配布は無制限です。

Copyright Notice
著作権表示

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

Abstract
概要

   Extending the Domain Name System (DNS) with new Resource Record (RR)
   types currently requires changes to name server software.  This
   document specifies the changes necessary to allow future DNS
   implementations to handle new RR types transparently.
   新しい資源レコード(RR)タイプでドメインネームシステム(DNS)を
   拡張するには現在ネームサーバソフトウェアに対する変更を必要とします。
   この文書は未来のDNS実装が透過的に新しい資源レコードタイプを処理す
   ることを許すために必要な変更を指定します。

1.  Introduction
1.  はじめに

   The DNS is designed to be extensible to support new services through
   the introduction of new resource record (RR) types.  In practice,
   deploying a new RR type currently requires changes to the name server
   software not only at the authoritative DNS server that is providing
   the new information and the client making use of it, but also at all
   slave servers for the zone containing it, and in some cases also at
   caching name servers and forwarders used by the client.
   DNSは新しい資源レコード(RR)タイプの導入を通して新しいサービス
   をサポートするように拡張可能であるように意図されます。実際は、現在新
   しい資源レコード (RR) タイプを配置することは、新しい情報を供給してい
   る正式DNSサーバーとそれを利用しているクライアントのネームサーバソ
   フトウェアに対する変更だけでなく、それを含んでいるゾーンの全スレーブ
   サーバと、ある場合にはクライアントが使用するキャッシュネームサーバと
   フォワーダの変更も必要とします。

   Because the deployment of new server software is slow and expensive,
   the potential of the DNS in supporting new services has never been
   fully realized.  This memo proposes changes to name servers and to
   procedures for defining new RR types aimed at simplifying the future
   deployment of new RR types.
   新しいサーバーソフトウェアの展開は時間とコストがかかるので、新しいサー
   ビスに対応するためのDNSの潜在能力は一度も完全に実感されたことがあ
   りません。この文書は新しい資源レコードタイプを定義する際の、ネームサー
   バと処理に対する変更を変更し、新しい資源レコードタイプの将来の実装を
   単純化することを提案します。

   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].
   この文書のキーワードは"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
   NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
   [RFC 2119]で記述されるように解釈されるはずです。

2.  Definition
2.  定義

   An "RR of unknown type" is an RR whose RDATA format is not known to
   the DNS implementation at hand, and whose type is not an assigned
   QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor
   within the range reserved in that section for assignment only to
   QTYPEs and Meta-TYPEs.  Such an RR cannot be converted to a type-
   specific text format, compressed, or otherwise handled in a type-
   specific way.
   「未知タイプの資源レコード」は使用しているDNS実装がその資源データ
   フォーマットを知らない資源レコードで、そしてそのタイプは[RFC 2929]
   (3.1章)でQタイプやメタタイプに指定された物ではなく、Qタイプやメ
   タタイプだけに割り当てるとして予約された範囲のタイプでもないものです。
   このような資源レコードはタイプ固有のテキストフォーマットや圧縮やタイ
   プ固有の扱いをすることができません。

   In the case of a type whose RDATA format is class specific, an RR is
   considered to be of unknown type when the RDATA format for that
   combination of type and class is not known.
   資源データフォーマットがクラス固有であるタイプの場合に、そのタイプと
   クラスの組合せに対する資源データフォーマットがわからない時、資源レコー
   ドが、未知タイプと考えられます。

3.  Transparency
3.  透過性

   To enable new RR types to be deployed without server changes, name
   servers and resolvers MUST handle RRs of unknown type transparently.
   That is, they must treat the RDATA section of such RRs as
   unstructured binary data, storing and transmitting it without change
   [RFC1123].
   新しい資源レコードタイプをサーバの変更なしで動作させることができるよ
   うにするために、ネームサーバとリゾルバが透過的に未知のタイプの資源レ
   コードを処理しなくてはなりません(MUST)。すなわち、そのような資源レコー
   ドの資源データ部を構造なしのバイナリデータかのように変更なしで扱い、
   変更なしで保存と転送をします[RFC1123]。

   To ensure the correct operation of equality comparison (section 6)
   and of the DNSSEC canonical form (section 7) when an RR type is known
   to some but not all of the servers involved, servers MUST also
   exactly preserve the RDATA of RRs of known type, except for changes
   due to compression or decompression where allowed by section 4 of
   this memo.  In particular, the character case of domain names that
   are not subject to compression MUST be preserved.
   同一性比較(6章)とDNSSEC正規化形式の正しい運用を確実にするため
   に、資源レコードタイプが関係サーバの一部が理解し他が理解しないときに、
   この文書の4章が許す場合の圧縮と解凍を除き、サーバは正確に未知タイプ
   の資源レコードの資源データを保存します(MUST)。特に、圧縮の適用を受け
   ていないドメイン名の文字大文字小文字は維持されるに違いありません(MUST)。

4.  Domain Name Compression
4.  ドメイン名圧縮

   RRs containing compression pointers in the RDATA part cannot be
   treated transparently, as the compression pointers are only
   meaningful within the context of a DNS message.  Transparently
   copying the RDATA into a new DNS message would cause the compression
   pointers to point at the corresponding location in the new message,
   which now contains unrelated data.  This would cause the compressed
   name to be corrupted.
   資源データ部で圧縮ポインタを含んでいる資源レコードは、圧縮ポインタが
   DNSメッセージの文脈の中でだけ意味を持つので、透過的に扱うことがで
   きません。透過的に資源データを新しいDNSメッセージにコピーすること
   は圧縮ポインタを新しいメッセージの対応する位置にポイントさせ、そして
   これは無関係なデータを含んでいます。これは圧縮された名前を破壊するで
   しょう。

   To avoid such corruption, servers MUST NOT compress domain names
   embedded in the RDATA of types that are class-specific or not well-
   known.  This requirement was stated in [RFC1123] without defining the
   term "well-known"; it is hereby specified that only the RR types
   defined in [RFC1035] are to be considered "well-known".
   このような破壊を避けるために、サーバはクラス固有か、あるいは既知タイ
   プでない資源データに埋め込みのドメイン名を圧縮してはなりません(MUST
   NOT)。この必要条件は「既知」という用語を定義しないで[RFC1123]で述べ
   られました;ただ[RFC1035]で定義された資源レコードタイプだけが「既知」
   と思われるはずであることはここに明示されます。

   The specifications of a few existing RR types have explicitly allowed
   compression contrary to this specification: [RFC2163] specified that
   compression applies to the PX RR, and [RFC2535] allowed compression
   in SIG RRs and NXT RRs records.  Since this specification disallows
   compression in these cases, it is an update to [RFC2163] (section 4)
   and [RFC2535] (sections 4.1.7 and 5.2).
   いくつかの既存の資源レコードタイプの仕様書は明示的にこの仕様書と反対
   に圧縮を許しました:[RFC2163]がPX資源rネコードに圧縮が適用されると明
   示しました、そして[RFC2535]が署名資源レコードとNXT資源レコードで
   圧縮を許しました。この仕様書がこれらの場合の圧縮を拒否するので、これ
   は[RFC2163](4章)と[RFC2535](4.1.7章と5.2章)の更新です。

   Receiving servers MUST decompress domain names in RRs of well-known
   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
   NXT, NAPTR, and SRV (although the current specification of the SRV RR
   in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
   servers following that earlier specification are still in use).
   受信サーバが既知の資源レコードのドメイン名を解凍しなければならず(MUST)、
   RPとAFSDBとRTと署名とPXとNXTとNAPTRとSRVタイプ
   の資源レコードの解凍をすべきです(SHOULD)([RFC2782]でのサービス資源レ
   コードの現在の仕様書が圧縮を禁止し、[RFC2052]がそれを要請し、そしてあ
   るサーバが以前の指定に従っているサーバが使用中である事に対応します)。

   Future specifications for new RR types that contain domain names
   within their RDATA MUST NOT allow the use of name compression for
   those names, and SHOULD explicitly state that the embedded domain
   names MUST NOT be compressed.
   ドメイン名を資源データに含む新しい資源レコードタイプの将来の仕様が、
   それらの名前の名前圧縮の使用を許してはならなくて(MUST NOT)、そして明
   示的に埋め込みのドメイン名が圧縮されてはならない(MUST NOT)と述べるべ
   きです(SHOULD)。

   As noted in [RFC1123], the owner name of an RR is always eligible for
   compression.
   [RFC1123]で述べたように、資源レコードの所有者名は常に圧縮できます。

5.  Text Representation
5.  テキスト表現

   In the "type" field of a master file line, an unknown RR type is
   represented by the word "TYPE" immediately followed by the decimal RR
   type number, with no intervening whitespace.  In the "class" field,
   an unknown class is similarly represented as the word "CLASS"
   immediately followed by the decimal class number.
   マスターファイル行の「タイプ」フィールドで、未知の資源レコードタイプ
   が単語「TYPE」と空白なしで直後に続く10進数の資源レコードタイプ番号
   で表現されます。「クラス」フィールドで、未知のクラスが、単語「CLASS」
   と直後に続く10進数のクラス番号で表現されます。

   This convention allows types and classes to be distinguished from
   each other and from TTL values, allowing the "[<TTL>] [<class>]
   <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
   [RFC1035] to both be unambiguously parsed.
   この書き方はタイプとクラスがお互いとTTL値とを明確に区別でき、
   [RFC1035]の"[<TTL>] [<class>] <type> <RDATA>"と"[<class>] [<TTL>]
   <type> <RDATA>" の形式が共に明瞭に解析できます。

   The RDATA section of an RR of unknown type is represented as a
   sequence of white space separated words as follows:
   未知タイプの資源レコードの資源データ部は、空白スペースの連続で区切ら
   れた以下のワードで表現されます:

      The special token \# (a backslash immediately followed by a hash
      sign), which identifies the RDATA as having the generic encoding
      defined herein rather than a traditional type-specific encoding.
      特別なトークン\#(バックスラッシュに続くハッシュサイン)、これは資
      源データが伝統的なタイプ固有表現ではなく、一般的なコーディングで定
      義される事を示します。

      An unsigned decimal integer specifying the RDATA length in octets.
      オクテット単位で資源データ長さを指定する符号なしの10進整数。

      Zero or more words of hexadecimal data encoding the actual RDATA
      field, each containing an even number of hexadecimal digits.
      偶数個の16進数を含む、実際の資源データフィールドをコード化する、
      ゼロ以上の16進データ。

   If the RDATA is of zero length, the text representation contains only
   the \# token and the single zero representing the length.
   もし資源データ長がゼロなら、テキスト表現は\#の印と長さを表しているひ
   とつのゼロだけを含んでいます。

   An implementation MAY also choose to represent some RRs of known type
   using the above generic representations for the type, class and/or
   RDATA, which carries the benefit of making the resulting master file
   portable to servers where these types are unknown.  Using the generic
   representation for the RDATA of an RR of known type can also be
   useful in the case of an RR type where the text format varies
   depending on a version, protocol, or similar field (or several)
   embedded in the RDATA when such a field has a value for which no text
   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
   0.
   実装がある既知の資源レコードタイプ表現に上記の一般的なタイプやクラス
   や資源データの表現を使うかもしれません(MAY)、これは結果のマスターファ
   イルを、そのタイプを知らないサーバに持っていけるようにします。既知タ
   イプの資源レコードの資源データで一般的な表現を使うことは、テキスト
   フォーマットがバージョンやプロトコルやテキストフォーマットが未知の資
   源データに埋め込みの類似フィールド(あるいはいくつか)に依存する場合、
   例えば、VERSIONが0以外のLOC資源レコード[RFC1876]で、の資源レコー
   ドタイプで有用です。

   Even though an RR of known type represented in the \# format is
   effectively treated as an unknown type for the purpose of parsing the
   RDATA text representation, all further processing by the server MUST
   treat it as a known type and take into account any applicable type-
   specific rules regarding compression, canonicalization, etc.
   \#フォーマットで表される既知のタイプの資源レコードが資源データテキス
   ト表現を解析する目的で未知のタイプとして取り扱われるけれども、サーバ
   による以降の処理がそれを既知のタイプと扱い、そして圧縮や正規化などに
   関してどんな適用可能なタイプ固有の規則を考慮に入れなくてはなりません
   (MUST)。

   The following are examples of RRs represented in this manner,
   illustrating various combinations of generic and type-specific
   encodings for the different fields of the master file format:
   以下はこの方法で表される資源レコードの例で、マスターファイル形式の異
   なるフィールドの一般的とタイプ固有のコード化の種々な例示です:

      a.example.   CLASS32     TYPE731         \# 6 abcd (
                                               ef 01 23 45 )
      b.example.   HS          TYPE62347       \# 0
      e.example.   IN          A               \# 4 0A000001
      e.example.   CLASS1      TYPE1           10.0.0.2

6.  Equality Comparison
6.  同一性比較

   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
   to be compared for equality.  Two RRs of the same unknown type are
   considered equal when their RDATA is bitwise equal.  To ensure that
   the outcome of the comparison is identical whether the RR is known to
   the server or not, specifications for new RR types MUST NOT specify
   type-specific comparison rules.
   ある特定のDNSプロトコル、特にダイナミック更新[RFC2136]が、資源レコー
   ドの同一性の比較を要求します。同じ未知のタイプの2つの資源レコードは、
   その資源データがビット単位で同じ時に同じであると思われます。資源レコー
   ドをサーバが知っているか否かにかかわらず、比較の結果が同一であること
   を保証するために、新しい資源レコードタイプの仕様書がタイプ固有の比較
   規則を指定してはなりません(MUST NOT)。

   This implies that embedded domain names, being included in the
   overall bitwise comparison, are compared in a case-sensitive manner.
   これは、埋込みドメイン名は全体的なビット単位比較に含められて、大文字
   小文字の違いを識別する方法で比較されることを意味します。

   As a result, when a new RR type contains one or more embedded domain
   names, it is possible to have multiple RRs owned by the same name
   that differ only in the character case of the embedded domain
   name(s).  This is similar to the existing possibility of multiple TXT
   records differing only in character case, and not expected to cause
   any problems in practice.
   結果として、新しい資源レコードタイプが1つ以上の埋め込みのドメイン名
   を含んでいる時、埋め込みのドメイン名の大文字小文字だけが違う同じ所有
   者名の多数の資源レコードを持つことは可能です。これは大文字小文字だけ
   が違っている多数のTXTレコードに類似し、そして実際は問題を起こさな
   いことを期待しています。

7.  DNSSEC Canonical Form and Ordering
7.  DNSSEC正規形式と順序

   DNSSEC defines a canonical form and ordering for RRs [RFC2535]
   (section 8.1).  In that canonical form, domain names embedded in the
   RDATA are converted to lower case.
   DNSSECは資源レコード[RFC2535](8.1章)のために正規形式と順序
   を定義します。その正規形式で、資源データの埋め込みのドメイン名が小文
   字に変換されます。

   The downcasing is necessary to ensure the correctness of DNSSEC
   signatures when case distinctions in domain names are lost due to
   compression, but since it requires knowledge of the presence and
   position of embedded domain names, it cannot be applied to unknown
   types.
   ドメイン名の大文字小文字の区別が圧縮の際に失われる時、小文字にするこ
   とはDNSSEC署名の正当性を保証するために必要ですが、それは存在と
   埋め込みのドメイン名の位置の知識を必要とするので、未知のタイプに適用
   することができません。

   To ensure continued consistency of the canonical form of RR types
   where compression is allowed, and for continued interoperability with
   existing implementations that already implement the [RFC2535]
   canonical form and apply it to their known RR types, the canonical
   form remains unchanged for all RR types whose whose initial
   publication as an RFC was prior to the initial publication of this
   specification as an RFC (RFC 3597).
   圧縮が許される資源レコードタイプの正規形式の継続的な一貫性を保証する
   のと、すでに[RFC2535]正規形式を実装し既知の資源レコードに適用する既存
   の実装との継続的な互換性のために、この仕様のRFCとしての最初の版
   (RFC3597)より以前に、RFCとしての最初の版が出ている資源レ
   コードタイプの正規形式は変更しないままとしします。

   As a courtesy to implementors, it is hereby noted that the complete
   set of such previously published RR types that contain embedded
   domain names, and whose DNSSEC canonical form therefore involves
   downcasing according to the DNS rules for character comparisons,
   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
   DNAME, and A6.
   実装者のために、以前に公表された資源レコードタイプで、埋め込みドメイ
   ン名を持ち、そのDNSSEC正規形式がDNSの文字比較規則にしたがっ
   て小文字化が必要なものの完全なリストは、NSとMDとMFとCNAME
   とSOAとMBとMGとMRとPTRとHINFOとMINFOとMXとH
   INFOとRPとAFSDBとRTとSIGとPXとNXTとNAPTRと
   KXとSRVとDNAMEとA6です。

   This document specifies that for all other RR types (whether treated
   as unknown types or treated as known types according to an RR type
   definition RFC more recent than RFC 3597), the canonical form is such
   that no downcasing of embedded domain names takes place, and
   otherwise identical to the canonical form specified in [RFC2535]
   section 8.1.
   この文書は、(未知のタイプとして扱われるか、あるいはRFC3597以
   降の資源レコードタイプ定義RFCに従って既知タイプとして扱われるか否
   かにかかわらず)、すべての他の資源レコードタイプに対して、埋め込みド
   メイン名の小文字かがなく他は[RFC2535]の8.1章と同じ正規形式、指定を
   行います。

   Note that the owner name is always set to lower case according to the
   DNS rules for character comparisons, regardless of the RR type.
   所有者名が常に文字比較の際に、資源レコードタイプにかかわらず、DNS
   規則に従って小文字に設定されることに注意してください。

   The DNSSEC canonical RR ordering is as specified in [RFC2535] section
   8.3, where the octet sequence is the canonical form as revised by
   this specification.
   DNSSEC正規資源レコード順序は[RFC2535]8.3章で指定され、ここで
   のオクテット列はこの仕様書によって修正される正規形式です。

8.  Additional Section Processing
8.  追加セクション処理

   Unknown RR types cause no additional section processing.  Future RR
   type specifications MAY specify type-specific additional section
   processing rules, but any such processing MUST be optional as it can
   only be performed by servers for which the RR type in case is known.
   未知の資源レコードタイプが追加セクション処理を起こしません。未来の資
   源レコードタイプ仕様書がタイプ固有の追加セクション処理規則を指定する
   かもしれませんが(MAY)、このような処理は資源レコードタイプを知っている
   サーバによってしか行えないので、任意使用に違いありません(MUST)。

9.  IANA Considerations
9.  IANAの考慮

   This document does not require any IANA actions.
   この文書はIANAの行動を必要としません。

10.  Security Considerations
10.  セキュリティの考察

   This specification is not believed to cause any new security
   problems, nor to solve any existing ones.
   この仕様書は新しいセキュリティ問題を起こすと信じられず、既存の問題を
   解決するとも信じられない。

11.  Normative References
11.  参照する参考文献


   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
               Facilities", STD 13, RFC 1034, November 1987.

   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
               Specifications", STD 13, RFC 1035, November 1987.

   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
               Application and Support", STD 3, RFC 1123, October 1989.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2535]   Eastlake, D., "Domain Name System Security Extensions",
               RFC 2535, March 1999.

   [RFC2163]   Allocchio, C., "Using the Internet DNS to Distribute
               MIXER Conformant Global Address Mapping (MCGAM)", RFC
               2163, January 1998.

   [RFC2929]   Eastlake, D., Brunner-Williams, E. and B. Manning,
               "Domain Name System (DNS) IANA Considerations", BCP 42,
               RFC 2929, September 2000.

12.  Informative References
12.  有益な参考文献

   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
               Means for Expressing Location Information in the Domain
               Name System", RFC 1876, January 1996.

   [RFC2052]   Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
               the location of services (DNS SRV)", RFC 2052, October
               1996.

   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
               RFC 2136, April 1997.

   [RFC2782]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
               specifying the location of services (DNS SRV)", RFC 2782,
               February 2000.

13.  Intellectual Property Statement
13.  知的所有権宣言

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.
   この文書に記述された実装や技術に関して主張される知的財産や他の権利の
   正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
   可能かの範囲について、IETFは何の立場もとりません;この様な権利を
   認識する調査をしたとは述べません。IETF標準手続きと標準関連文書で
   の権利に関しての手順の情報はBCP11を見てください。出版に利用する
   権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書
   の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの
   結果はIETF事務局で得られます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.
   IETFは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
   バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
   めます。どうかIETF専務に情報を伝えてください。

14.  Author's Address
14.  著者のアドレス

   Andreas Gustafsson
   Nominum, Inc.
   2385 Bay Rd
   Redwood City, CA 94063
   USA

   Phone: +1 650 381 6004
   EMail: gson@nominum.com


15.  Full Copyright Statement
15.  著作権表示全文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.
   著作権(C)インターネット学会(2003)。すべての権利は保留される。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
   この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
   を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
   版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
   ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
   や他のインターネット組織は著作権表示や参照を削除されるような変更がで
   きません、インターネット標準を開発する場合はインターネット標準化プロ
   セスで定義された著作権の手順に従われます。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.
   上に与えられた限定された許可は永久で、インターネット学会やその後継者
   や譲渡者によって無効にされません。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So