RFC2671 日本語訳
2671 Extension Mechanisms for DNS (EDNS0). P. Vixie. August 1999. (Format: TXT=15257 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Vixie Request for Comments: 2671 ISC Category: Standards Track August 1999
Vixieがコメントのために要求するワーキンググループP.をネットワークでつないでください: 2671年のISCカテゴリ: 標準化過程1999年8月
Extension Mechanisms for DNS (EDNS0)
DNSのための拡張機能(EDNS0)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.
ドメインネームシステムのワイヤプロトコルは、すぐ、範囲があった多くの固定分野を含むか、消耗していて、またはクライアントがサーバへの彼らの能力の広告を出すのを許容しないでしょう。 このドキュメントは、プロトコルが成長するのを許容するために後方のコンパチブルメカニズムについて説明します。
1 - Rationale and Scope
1--原理と範囲
1.1. DNS (see [RFC1035]) specifies a Message Format and within such
messages there are standard formats for encoding options, errors,
and name compression. The maximum allowable size of a DNS Message
is fixed. Many of DNS's protocol limits are too small for uses
which are or which are desired to become common. There is no way
for implementations to advertise their capabilities.
1.1. DNS([RFC1035]を見る)はMessage Formatを指定します、そして、そのようなメッセージの中に、オプション、誤り、および名前圧縮をコード化するための標準書式があります。 DNS Messageの最大の許容できるサイズは固定されています。 、または一般的になることが望まれている用途には、DNSのプロトコル限界の多くが小さ過ぎます。 彼らの能力の広告を出すために、実装のための方法は全くありません。
1.2. Existing clients will not know how to interpret the protocol
extensions detailed here. In practice, these clients will be
upgraded when they have need of a new feature, and only new
features will make use of the extensions. We must however take
account of client behaviour in the face of extra fields, and design
a fallback scheme for interoperability with these clients.
1.2. 既存のクライアントはここで詳細なプロトコル拡大を解釈する方法を知らないでしょう。 実際には、彼らに新機能の必要があると、これらのクライアントはアップグレードして、新機能だけが拡大を利用するでしょう。 私たちは、しかしながら、付加的な分野に直面してクライアントのふるまいを考慮に入れて、これらのクライアントと共に相互運用性の後退体系を設計しなければなりません。
Vixie Standards Track [Page 1] RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
Vixie規格は1999年8月にDNS(EDNS0)のためにRFC2671拡張機能を追跡します[1ページ]。
2 - Affected Protocol Elements
2--影響を受けるプロトコル要素
2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
1-bit flags. The original reserved Z bits have been allocated to
various purposes, and most of the RCODE values are now in use.
More flags and more possible RCODEs are needed.
2.1. DNS Message Headerのもの、(見る、[RFC1035、4.1、.1、)、2番目の完全な16ビットの単語は4ビットのOPCODE、4ビットのRCODE、および多くの1ビットの旗に分割されます。 元の予約されたZビットを様々な目的に割り当てました、そして、RCODE値の大部分は現在、使用中です。 より多くの旗と、より可能なRCODEsが必要です。
2.2. The first two bits of a wire format domain label are used to denote
the type of the label. [RFC1035 4.1.4] allocates two of the four
possible types and reserves the other two. Proposals for use of
the remaining types far outnumber those available. More label
types are needed.
2.2. ワイヤ形式ドメインラベルの最初の2ビットは、ラベルのタイプを指示するのに使用されます。 [RFC1035 4.1.4] 4つの可能なタイプのうちの2人を割り当てて、他の2を予約します。 残りの使用が遠くにタイプするので、提案は利用可能なそれらに数でまさります。 より多くのラベル形式が必要です。
2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
While the minimum maximum reassembly buffer size still allows a
limit of 512 octets of UDP payload, most of the hosts now connected
to the Internet are able to reassemble larger datagrams. Some
mechanism must be created to allow requestors to advertise larger
buffer sizes to responders.
2.3. UDPの上に送ると、DNS Messagesをサイズにおける512の八重奏に制限します。 最小の最大の再アセンブリバッファサイズはまだUDPペイロードの512の八重奏の限界を許容していますが、現在インターネットに接続されるホストの大部分は、より大きいデータグラムを組み立て直すことができます。要請者が大きめのバッファサイズの応答者に広告を出すのを許容するために何らかのメカニズムを作成しなければなりません。
3 - Extended Label Types
3--拡張ラベル形式
3.1. The "0 1" label type will now indicate an extended label type,
whose value is encoded in the lower six bits of the first octet of
a label. All subsequently developed label types should be encoded
using an extended label type.
3.1. 「0 1インチのラベル形式は現在、拡張ラベル形式を示すでしょう」。(ラベル形式の値はラベルの最初の八重奏の低級6ビットでコード化されます)。 すべての次に開発されたラベル形式が、拡張ラベル形式を使用することでコード化されるべきです。
3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
expansion of the extended label type code space.
3.2. 「1インチの1 1 1 1 1の拡張ラベル形式は拡張ラベル形式コードスペースの今後の拡張のために予約されるでしょう。」
4 - OPT pseudo-RR
4--疑似RRを選んでください。
4.1. One OPT pseudo-RR can be added to the additional data section of
either a request or a response. An OPT is called a pseudo-RR
because it pertains to a particular transport level message and not
to any actual DNS data. OPT RRs shall never be cached, forwarded,
or stored in or loaded from master files. The quantity of OPT
pseudo-RRs per message shall be either zero or one, but not
greater.
4.1. 要求か応答のどちらかの追加資料課に1OPT疑似RRを追加できます。 OPTは、メッセージとどんな実際のDNSデータでないことへの特定の輸送レベルにも関するので、疑似RRと呼ばれます。 OPT RRsは基本ファイルからキャッシュされるか、進められるか、保存されるか積み込むように決してならないでしょう。 1メッセージあたりのOPT疑似RRsの量は、ゼロか1つのどちらかにもかかわらず、より大きくならないでしょう。
4.2. An OPT RR has a fixed part and a variable set of options expressed
as {attribute, value} pairs. The fixed part holds some DNS meta
data and also a small collection of new protocol elements which we
expect to be so popular that it would be a waste of wire space to
encode them as {attribute, value} pairs.
4.2. OPT RRには、固定部分があります、そして、可変オプションは属性、値として組を言い表しました。 固定部分はいくつかのDNSメタデータを保持します、そして、また、私たちがそれが属性、値としてそれらをコード化するためにはワイヤスペースの浪費であるポピュラーであることを期待する新しいプロトコル要素のわずかな収集は対にされます。
Vixie Standards Track [Page 2] RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
Vixie規格は1999年8月にDNS(EDNS0)のためにRFC2671拡張機能を追跡します[2ページ]。
4.3. The fixed part of an OPT RR is structured as follows:
4.3. OPT RRの固定部分は以下の通り構造化されます:
Field Name Field Type Description
------------------------------------------------------
NAME domain name empty (root domain)
TYPE u_int16_t OPT
CLASS u_int16_t sender's UDP payload size
TTL u_int32_t extended RCODE and flags
RDLEN u_int16_t describes RDATA
RDATA octet stream {attribute,value} pairs
フィールド名分野型記述------------------------------------------------------ 空(根のドメイン)のTYPE u_int16の_t OPT CLASS u_int16_t送付者のNAMEドメイン名のUDPのペイロードサイズTTL u_int32_t拡張しているRCODEと旗のRDLEN u_int16_tがRDATA RDATA八重奏ストリームについて説明する、属性、値は対にされます。
4.4. The variable part of an OPT RR is encoded in its RDATA and is
structured as zero or more of the following:
4.4. OPT RRの可変部分は、RDATAでコード化されて、以下のゼロか以上として構造化されます:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | オプションコード| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | オプション長さ| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4: | | /オプションデータ///+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE (Assigned by IANA.)
オプションコード(IANAによって割り当てられます。)
OPTION-LENGTH Size (in octets) of OPTION-DATA.
OPTION-DATAのOPTION-LENGTH Size(八重奏における)。
OPTION-DATA Varies per OPTION-CODE.
オプションデータはオプションコード単位で異なります。
4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
field) is the number of octets of the largest UDP payload that can
be reassembled and delivered in the sender's network stack. Note
that path MTU, with or without fragmentation, may be smaller than
this.
4.5. 送付者のUDPペイロードサイズ(OPTがRR CLASS分野に保存する)は送付者のネットワークスタックで組み立て直して、提供できる中で最も大きいUDPペイロードの八重奏の数です。 経路MTUが断片化のあるなしにかかわらずこれより小さいかもしれないことに注意してください。
4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
reassembly buffer. Choosing 1280 on an Ethernet connected
requestor would be reasonable. The consequence of choosing too
large a value may be an ICMP message from an intermediate
gateway, or even a silent drop of the response message.
4.5.1. 512八重奏のUDPペイロードが576八重奏のIP再アセンブリバッファを必要とすることに注意してください。 イーサネットに関する1280を選んで、接続要請者は合理的でしょう。 大き過ぎる値を選ぶ結果は、中間ゲートウェイからのICMPメッセージ、または応答メッセージの静かな範囲でさえあるかもしれません。
4.5.2. Both requestors and responders are advised to take account of the
path's discovered MTU (if already known) when considering message
sizes.
4.5.2. メッセージサイズを考えるとき、要請者と応答者の両方が経路の発見されたMTU(既に知られるなら)を考慮に入れるようにアドバイスされます。
Vixie Standards Track [Page 3] RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
Vixie規格は1999年8月にDNS(EDNS0)のためにRFC2671拡張機能を追跡します[3ページ]。
4.5.3. The requestor's maximum payload size can change over time, and
should therefore not be cached for use beyond the transaction in
which it is advertised.
4.5.3. 要請者の最大積載量サイズは時間がたつにつれて変化できて、したがって、それが広告に掲載されているトランザクションのを超えて使用のためにキャッシュするべきではありません。
4.5.4. The responder's maximum payload size can change over time, but
can be reasonably expected to remain constant between two
sequential transactions; for example, a meaningless QUERY to
discover a responder's maximum UDP payload size, followed
immediately by an UPDATE which takes advantage of this size.
(This is considered preferrable to the outright use of TCP for
oversized requests, if there is any reason to suspect that the
responder implements EDNS, and if a request will not fit in the
default 512 payload size limit.)
4.5.4. 応答者の最大積載量サイズを時間がたつにつれて変化できますが、2つの連続したトランザクションの間で一定のままで残っていると合理的に予想できます。 例えば、応答者の最大のUDPペイロードサイズを発見する無意味なQUERYはすぐこのサイズを利用するUPDATEで続きました。 (これはTCPの特大の要求の完全な使用への「前-フェリー-可能」であると考えられます、何か応答者がEDNSを実装すると疑う理由があって、要求がデフォルトで512ペイロードサイズ限界に合わないなら。)
4.5.5. Due to transaction overhead, it is unwise to advertise an
architectural limit as a maximum UDP payload size. Just because
your stack can reassemble 64KB datagrams, don't assume that you
want to spend more than about 4KB of state memory per ongoing
transaction.
4.5.5. トランザクションオーバーヘッドのために、最大のUDPペイロードサイズとして建築限界の広告を出すのは賢明ではありません。 ただスタックが64KBのデータグラムを組み立て直すことができるので、進行中のトランザクションあたりのおよそ4KB以上の州のメモリを費やしたいと仮定しないでください。
4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
are structured as follows:
4.6. 拡張RCODEと旗(OPTがRR TTL分野に保存する)は以下の通り構造化されます:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0(MSB)+1(LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | 拡張RCODE| バージョン| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | Z| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note
that EXTENDED-RCODE value "0" indicates that an
unextended RCODE is in use (values "0" through "15").
拡張12ビットのRCODEのEXTENDED-RCODE Forms上側の8ビット。 そのEXTENDED-RCODEが評価することに注意してください、「0インチが、unextended RCODEが使用中であることを示す、(値、「0インチ、通じて、「15インチ)」
VERSION Indicates the implementation level of whoever sets
it. Full conformance with this specification is
indicated by version "0." Requestors are encouraged
to set this to the lowest implemented level capable
of expressing a transaction, to minimize the
responder and network load of discovering the
greatest common implementation level between
requestor and responder. A requestor's version
numbering strategy should ideally be a run time
configuration option.
実装が平らにするそれを設定する人なら誰でもに関するバージョンIndicates。 この仕様がある完全な順応はバージョン「0」によって示されます。 要請者が要請者と応答者の間の最大公約数実装レベルを発見する応答者とネットワーク負荷を最小にするためにトランザクションを言い表すことができるレベルであると実装される中で最も低いものにこれを設定するよう奨励されます。 要請者のバージョン付番戦略は理想的にランタイム設定オプションであるべきです。
If a responder does not implement the VERSION level
of the request, then it answers with RCODE=BADVERS.
All responses will be limited in format to the
応答者が、バージョンが要求のレベルであると実装しないなら、それにRCODE=BADVERSと共に答えます。 すべての応答が形式で有限であるために望んでいます。
Vixie Standards Track [Page 4] RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
Vixie規格は1999年8月にDNS(EDNS0)のためにRFC2671拡張機能を追跡します[4ページ]。
VERSION level of the request, but the VERSION of each
response will be the highest implementation level of
the responder. In this way a requestor will learn
the implementation level of a responder as a side
effect of every response, including error responses,
including RCODE=BADVERS.
要求のバージョンレベル、しかし、それぞれの応答のバージョンは応答者の最も高い実装レベルになるでしょう。 このように、要請者はあらゆる応答の副作用として応答者の実装レベルを学ぶでしょう、誤り応答を含んでいて、RCODE=BADVERSを含んでいて。
Z Set to zero by senders and ignored by receivers,
unless modified in a subsequent specification.
その後の仕様で変更されない場合、送付者によってゼロに設定されて、受信機によって無視されたZ。
5 - Transport Considerations
5--輸送問題
5.1. The presence of an OPT pseudo-RR in a request should be taken as an
indication that the requestor fully implements the given version of
EDNS, and can correctly understand any response that conforms to
that feature's specification.
5.1. 要求における、OPT疑似RRの存在は、要請者がEDNSの与えられたバージョンを完全に実装するという指示として取られるべきであり、正しくそのフィーチャーの仕様に従うどんな応答も理解できます。
5.2. Lack of use of these features in a request must be taken as an
indication that the requestor does not implement any part of this
specification and that the responder may make no use of any
protocol extension described here in its response.
5.2. 要請者が、この仕様のどんな部分とそれも応答者であると実装しないという指示でここ、応答でどんなプロトコル拡大の無駄についても説明するとき、要求でこれらの特徴で役に立つ不足を取らなければなりません。
5.3. Responders who do not understand these protocol extensions are
expected to send a response with RCODE NOTIMPL, FORMERR, or
SERVFAIL. Therefore use of extensions should be "probed" such that
a responder who isn't known to support them be allowed a retry with
no extensions if it responds with such an RCODE. If a responder's
capability level is cached by a requestor, a new probe should be
sent periodically to test for changes to responder capability.
5.3. これらのプロトコル拡大を理解していない応答者がRCODE NOTIMPL、FORMERR、またはSERVFAILとの応答を送ると予想されます。 したがって、拡張子の使用が「調べられた」そのようなものであるべきであるので、そのようなRCODEと共に応じるなら、再試行は拡大なしでそれらをサポートするのは知られない応答者に許されています。 要請者が応答者の能力レベルをキャッシュするなら、応答者能力への変化がないかどうかテストするために定期的に新しい探測装置を送るべきです。
6 - Security Considerations
6--セキュリティ問題
Requestor-side specification of the maximum buffer size may open a
new DNS denial of service attack if responders can be made to send
messages which are too large for intermediate gateways to forward,
thus leading to potential ICMP storms between gateways and
responders.
応答者に中間ゲートウェイが進めることができないくらい大きいメッセージを送らせることができるなら、最大のバッファサイズの要請者サイド仕様は新しいDNSサービス不能攻撃を開くかもしれません、その結果、ゲートウェイと応答者の間の潜在的ICMP嵐に通じます。
7 - IANA Considerations
7--IANA問題
The IANA has assigned RR type code 41 for OPT.
IANAはOPTのためにタイプコード41をRRに割り当てました。
It is the recommendation of this document and its working group
that IANA create a registry for EDNS Extended Label Types, for EDNS
Option Codes, and for EDNS Version Numbers.
それはIANAがEDNS Extended Label Types、EDNS Option Codes、およびEDNSバージョン民数記のために登録を作成するというこのドキュメントとそのワーキンググループの推薦です。
This document assigns label type 0b01xxxxxx as "EDNS Extended Label
Type." We request that IANA record this assignment.
「EDNSはラベル形式を広げていること」に従って、このドキュメントがラベル形式0b01xxxxxxを割り当てます。 私たちは、IANAがこの課題を記録するよう要求します。
Vixie Standards Track [Page 5] RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
Vixie規格は1999年8月にDNS(EDNS0)のためにRFC2671拡張機能を追跡します[5ページ]。
This document assigns extended label type 0bxx111111 as "Reserved
for future extended label types." We request that IANA record this
assignment.
このドキュメントは「将来の拡張ラベル形式のために、予約される」ように拡張ラベル形式0bxx111111を割り当てます。 私たちは、IANAがこの課題を記録するよう要求します。
This document assigns option code 65535 to "Reserved for future
expansion."
このドキュメントは「今後の拡張のために、予約されたこと」にオプションコード65535を割り当てます。
This document expands the RCODE space from 4 bits to 12 bits. This
will allow IANA to assign more than the 16 distinct RCODE values
allowed in [RFC1035].
このドキュメントは4ビットから12ビットにRCODEスペースを広くします。 これで、IANAは値が[RFC1035]に許容した16の異なったRCODE以上を割り当てることができるでしょう。
This document assigns EDNS Extended RCODE "16" to "BADVERS".
このドキュメントは「「BADVERS」への16インチ」をEDNS Extended RCODEに割り当てます。
IESG approval should be required to create new entries in the EDNS
Extended Label Type or EDNS Version Number registries, while any
published RFC (including Informational, Experimental, or BCP)
should be grounds for allocation of an EDNS Option Code.
IESG承認がEDNS Extended Label TypeかEDNSバージョンNumber登録で新しいエントリーを作成するのに必要であるべきです、どんな発行されたRFC(Informational、Experimental、またはBCPを含んでいる)もEDNS Option Codeの配分の根拠であるべきですが。
8 - Acknowledgements
8--承認
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
Narten were each instrumental in creating and refining this
specification.
ポールMockapetris、マーク・アンドリュース、ロバートElz、ドン・ルイス、ボブ・ハレー、ドナルド・イーストレーク、ロブAustein、マット・クロフォード、ランディ・ブッシュ、およびトーマスNartenはこの仕様を作成して、洗練する際にそれぞれ手段になっていました。
9 - References
9--参照
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
10 - Author's Address
10--作者のアドレス
Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063
通りレッドウッドシティー、ポールVixieインターネットソフトウェア共同体950Charterカリフォルニア 94063
Phone: +1 650 779 7001 EMail: vixie@isc.org
以下に電話をしてください。 +1 7001年の650 779メール: vixie@isc.org
Vixie Standards Track [Page 6] RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999
Vixie規格は1999年8月にDNS(EDNS0)のためにRFC2671拡張機能を追跡します[6ページ]。
11 - Full Copyright Statement
11--完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Vixie Standards Track [Page 7]
Vixie標準化過程[7ページ]
一覧
スポンサーリンク
