この文書はRFC3597の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group A. Gustafsson
Request for Comments: 3597 Nominum Inc.
Category: Standards Track September 2003
Handling of Unknown DNS Resource Record (RR) Types
未知のＤＮＳ資源レコード（ＲＲ）タイプの取り扱い
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
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.
新しい資源レコード（ＲＲ）タイプでドメインネームシステム（ＤＮＳ）を
拡張するには現在ネームサーバソフトウェアに対する変更を必要とします。
この文書は未来のＤＮＳ実装が透過的に新しい資源レコードタイプを処理す
ることを許すために必要な変更を指定します。
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.
ＤＮＳは新しい資源レコード（ＲＲ）タイプの導入を通して新しいサービス
をサポートするように拡張可能であるように意図されます。実際は、現在新
しい資源レコード (RR) タイプを配置することは、新しい情報を供給してい
る正式ＤＮＳサーバーとそれを利用しているクライアントのネームサーバソ
フトウェアに対する変更だけでなく、それを含んでいるゾーンの全スレーブ
サーバと、ある場合にはクライアントが使用するキャッシュネームサーバと
フォワーダの変更も必要とします。
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.
新しいサーバーソフトウェアの展開は時間とコストがかかるので、新しいサー
ビスに対応するためのＤＮＳの潜在能力は一度も完全に実感されたことがあ
りません。この文書は新しい資源レコードタイプを定義する際の、ネームサー
バと処理に対する変更を変更し、新しい資源レコードタイプの将来の実装を
単純化することを提案します。
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.
「未知タイプの資源レコード」は使用しているＤＮＳ実装がその資源データ
フォーマットを知らない資源レコードで、そしてそのタイプは[RFC 2929]
（３.１章）でＱタイプやメタタイプに指定された物ではなく、Ｑタイプやメ
タタイプだけに割り当てるとして予約された範囲のタイプでもないものです。
このような資源レコードはタイプ固有のテキストフォーマットや圧縮やタイ
プ固有の扱いをすることができません。
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.
同一性比較（６章)とＤＮＳＳＥＣ正規化形式の正しい運用を確実にするため
に、資源レコードタイプが関係サーバの一部が理解し他が理解しないときに、
この文書の４章が許す場合の圧縮と解凍を除き、サーバは正確に未知タイプ
の資源レコードの資源データを保存します(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.
資源データ部で圧縮ポインタを含んでいる資源レコードは、圧縮ポインタが
ＤＮＳメッセージの文脈の中でだけ意味を持つので、透過的に扱うことがで
きません。透過的に資源データを新しいＤＮＳメッセージにコピーすること
は圧縮ポインタを新しいメッセージの対応する位置にポイントさせ、そして
これは無関係なデータを含んでいます。これは圧縮された名前を破壊するで
しょう。
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]が署名資源レコードとＮＸＴ資源レコードで
圧縮を許しました。この仕様書がこれらの場合の圧縮を拒否するので、これ
は[RFC2163]（４章）と[RFC2535]（４.１.７章と５.２章）の更新です。
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)、
ＲＰとＡＦＳＤＢとＲＴと署名とＰＸとＮＸＴとＮＡＰＴＲとＳＲＶタイプ
の資源レコードの解凍をすべきです(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」と空白なしで直後に続く１０進数の資源レコードタイプ番号
で表現されます。「クラス」フィールドで、未知のクラスが、単語「CLASS」
と直後に続く１０進数のクラス番号で表現されます。
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.
この書き方はタイプとクラスがお互いとＴＴＬ値とを明確に区別でき、
[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.
オクテット単位で資源データ長さを指定する符号なしの１０進整数。
Zero or more words of hexadecimal data encoding the actual RDATA
field, each containing an even number of hexadecimal digits.
偶数個の１６進数を含む、実際の資源データフィールドをコード化する、
ゼロ以上の１６進データ。
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が０以外のＬＯＣ資源レコード[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.
ある特定のＤＮＳプロトコル、特にダイナミック更新[RFC2136]が、資源レコー
ドの同一性の比較を要求します。同じ未知のタイプの２つの資源レコードは、
その資源データがビット単位で同じ時に同じであると思われます。資源レコー
ドをサーバが知っているか否かにかかわらず、比較の結果が同一であること
を保証するために、新しい資源レコードタイプの仕様書がタイプ固有の比較
規則を指定してはなりません(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.
結果として、新しい資源レコードタイプが１つ以上の埋め込みのドメイン名
を含んでいる時、埋め込みのドメイン名の大文字小文字だけが違う同じ所有
者名の多数の資源レコードを持つことは可能です。これは大文字小文字だけ
が違っている多数のＴＸＴレコードに類似し、そして実際は問題を起こさな
いことを期待しています。
7. DNSSEC Canonical Form and Ordering
7. ＤＮＳＳＥＣ正規形式と順序
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.
ＤＮＳＳＥＣは資源レコード[RFC2535]（８.１章）のために正規形式と順序
を定義します。その正規形式で、資源データの埋め込みのドメイン名が小文
字に変換されます。
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.
ドメイン名の大文字小文字の区別が圧縮の際に失われる時、小文字にするこ
とはＤＮＳＳＥＣ署名の正当性を保証するために必要ですが、それは存在と
埋め込みのドメイン名の位置の知識を必要とするので、未知のタイプに適用
することができません。
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]正規形式を実装し既知の資源レコードに適用する既存
の実装との継続的な互換性のために、この仕様のＲＦＣとしての最初の版
（ＲＦＣ３５９７）より以前に、ＲＦＣとしての最初の版が出ている資源レ
コードタイプの正規形式は変更しないままとしします。
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.
実装者のために、以前に公表された資源レコードタイプで、埋め込みドメイ
ン名を持ち、そのＤＮＳＳＥＣ正規形式がＤＮＳの文字比較規則にしたがっ
て小文字化が必要なものの完全なリストは、ＮＳとＭＤとＭＦとＣＮＡＭＥ
とＳＯＡとＭＢとＭＧとＭＲとＰＴＲとＨＩＮＦＯとＭＩＮＦＯとＭＸとＨ
ＩＮＦＯとＲＰとＡＦＳＤＢとＲＴとＳＩＧとＰＸとＮＸＴとＮＡＰＴＲと
ＫＸとＳＲＶとＤＮＡＭＥとＡ６です。
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.
この文書は、（未知のタイプとして扱われるか、あるいはＲＦＣ３５９７以
降の資源レコードタイプ定義ＲＦＣに従って既知タイプとして扱われるか否
かにかかわらず）、すべての他の資源レコードタイプに対して、埋め込みド
メイン名の小文字かがなく他は[RFC2535]の８.１章と同じ正規形式、指定を
行います。
Note that the owner name is always set to lower case according to the
DNS rules for character comparisons, regardless of the RR type.
所有者名が常に文字比較の際に、資源レコードタイプにかかわらず、ＤＮＳ
規則に従って小文字に設定されることに注意してください。
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.
ＤＮＳＳＥＣ正規資源レコード順序は[RFC2535]８.３章で指定され、ここで
のオクテット列はこの仕様書によって修正される正規形式です。
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. ＩＡＮＡの考慮
This document does not require any IANA actions.
この文書はＩＡＮＡの行動を必要としません。
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.
この文書に記述された実装や技術に関して主張される知的財産や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する調査をしたとは述べません。ＩＥＴＦ標準手続きと標準関連文書で
の権利に関しての手順の情報はＢＣＰ１１を見てください。出版に利用する
権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書
の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの
結果はＩＥＴＦ事務局で得られます。
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.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかＩＥＴＦ専務に情報を伝えてください。
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.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。