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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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実装が透過的に新しいRRタイプを処理することを可能にするために必要な変更を指定します。
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の可能性は完全に実現されていません。このメモは、ネームサーバへと新しいRRタイプの今後の展開を簡素化を目的とした新しいRRタイプを定義するための手順への変更を提案しています。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC 2119]に記載されているように解釈されます。
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.
「未知のタイプのRR」は、そのRDATAフォーマット手元DNS実装に知られていないRRであり、その種類、[RFC 2929]（セクション3.1）にも範囲内に指定されるように割り当てられたQTYPEまたはメタ型ではありませんのみQTYPEsとメタタイプへの割り当てのためにそのセクションで予約。そのようなRRは、タイプ固有のテキスト形式に変換、圧縮、または他の型特異的方法で処理することができません。
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.
RDATAフォーマットクラス特異的である型の場合、RRは、タイプとクラスの組合せのためにRDATAフォーマットが知られていない場合、未知の型であると考えられます。
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].
サーバーの変更、ネームサーバとリゾルバなしで展開する新しいRRタイプを有効にするには透過的に未知のタイプのRRを処理する必要があります。すなわち、それらは変更せずにそれを格納し、送信し、[RFC1123]を、非構造化バイナリ・データなどのRRのRDATA部を治療しなければなりません。
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.
RRタイプがいくつかではなく、関係するすべてのサーバに知られているときに等価比較（セクション6）およびDNSSEC標準形（セクション7）の正しい動作を保証するために、サーバは、正確に知られているタイプのRRのRDATAを保持しなければなりませんこのメモのセクション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メッセージのコンテキスト内でのみ意味があるようにRDATA部に圧縮ポインタを含むRRは、透過的に治療することができません。透過的に新しいDNSメッセージにRDATAをコピーすることは圧縮ポインタが今無関係なデータを含む新しいメッセージに対応する位置を指すように原因となります。これは、圧縮された名前が破損することが原因となります。
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".
そのような破損を避けるために、サーバは、クラス固有のか、よく知られていないタイプのRDATAに埋め込まれたドメイン名を圧縮してはなりません。この要件は、「既知の」という用語を定義することなく、[RFC1123]に記載されました。ここ[RFC1035]で定義された唯一のRRタイプは「よく知られている」と考えられるべきであることが指定されています。
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).
いくつかの既存のRRタイプの仕様は明示的にこの仕様に圧縮反して許されています[RFC2163]はその圧縮がPX RRに適用され、指定、および[RFC2535]はSIGのRRとNXTのRRレコードに圧縮を可能にしました。この仕様はこれらのケースの圧縮を禁止しているので、それは[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).
受信サーバは、周知のタイプの資源レコードのドメイン名を解凍しなければならないし、また型RPのRRを解凍すべきである、AFSDB、RT、SIG、PX、NXT、NAPTR、およびSRV（ただしにSRV RRの現在の仕様[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.
そのRDATA内のドメイン名を含む新しいRRタイプのため、将来の仕様は、それらの名前の名前圧縮の使用を許可してはならない、と明示的に埋め込まれたドメイン名が圧縮されてはならないことを明記してください。
As noted in [RFC1123], the owner name of an RR is always eligible for compression.
[RFC1123]で述べたように、RRの所有者名が常に圧縮の対象です。
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.
マスタ・ファイル・ラインの「タイプ」フィールドには、未知のRRタイプがない介在空白で、直ちに小数点RRタイプ番号が続く単語「TYPE」で表されます。 「クラス」フィールドには、未知のクラスは、同様に直ちに進クラス番号に続く単語「クラス」として表されます。
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値から区別することを可能にする "[<TTL>] [<クラス> <タイプ> <RDATA>" および「[<クラス>] [<TTL> <タイプ> <RDATA>」の両方に[RFC1035]の形態は明確に解析されます。
The RDATA section of an RR of unknown type is represented as a sequence of white space separated words as follows:
次のように未知のタイプのRRのRDATA部は、ホワイトスペースで区切られた単語のシーケンスとして表されます。
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.
本明細書で定義された一般的な符号化ではなく、伝統的な型特異的エンコーディングを有するものとしてRDATAを識別する特殊トークン\＃（直ちにハッシュ符号バックスラッシュ）。
An unsigned decimal integer specifying the RDATA length in octets.
オクテットRDATAの長さを指定する符号なし10進整数。
Zero or more words of hexadecimal data encoding the actual RDATA field, each containing an even number of hexadecimal digits.
実際のRDATAフィールドをコード進データのゼロ以上の単語、16進数の偶数をそれぞれ含みます。
If the RDATA is of zero length, the text representation contains only the \# token and the single zero representing the length.
RDATAの長さがゼロである場合、テキスト表現は、唯一の\＃トークンと長さを表す単一のゼロが含まれています。
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.
実装は、これらの型が不明であるサーバに結果のマスターファイルのポータブルを作ることの利点を運ぶタイプ、クラスおよび/またはRDATA、のために上記の一般的な表現を用いて、既知のタイプのいくつかのRRを表現するために選ぶかもしれません。既知のタイプのRRのRDATAのための一般的な表現を使用すると、テキスト形式、バージョン、プロトコル、または同様のフィールド（または複数）に応じて変化するRR型の場合に有用であり得るRDATAに埋め込まれたときに、そのようなフィールドが0以外のバージョンでないテキスト形式が知られていないされている値、例えば、LOCのRR [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.
\の＃形式で表現既知のタイプのRRが効果的RDATAのテキスト表現を解析する目的で、未知のタイプとして処理されていても、サーバーによってすべての更なる処理は、既知のタイプとして扱いとアカウントに適用可能なタイプを取る必要があります圧縮、正規化などに関する固有のルール
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:
以下は、マスタ・ファイル・フォーマットの異なるフィールドのための一般的な及び型特異エンコーディングの様々な組み合わせを示し、このように表されるRRの例です。
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
a.example。 CLASS32 TYPE731 \＃6 ABCD（EF 01 23 45）b.example。 HS TYPE62347 \＃0 e.example。 \＃4 0A000001 e.example、IN。 CLASS1 TYPE1 10.0.0.2
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]は、等しいかどうかを比較するためのRRを必要としています。彼らのRDATAはビット単位等しいときに同じ未知のタイプの2つのRRが等しいと見なされます。比較の結果は、RRがサーバに知られているかどうか、同一であることを確認するために、新しいRRタイプの仕様はタイプ固有の比較規則を指定してはなりません。
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.
新しいRRタイプは、1つまたは複数の埋め込まれたドメイン名が含まれている場合、その結果、埋め込まれたドメイン名（複数可）の文字ケースのみが異なる同じ名前が所有する複数のRRを持つことが可能です。これは、大文字と小文字のみが異なる複数のTXTレコードの既存の可能性と同様であり、実際に問題を引き起こすことが期待できません。
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）のための標準形式および順序を定義します。その標準形式で、RDATAに埋め込まれたドメイン名は小文字に変換されます。
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.
downcasingは、ドメイン名にケースの区別が圧縮により失われる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).
圧縮が許可されているRRタイプの正規の形式の継続的な整合性を確保するために、すでに[RFC2535]標準的な形式を実装し、その知られているRRタイプに適用する既存の実装との継続的な相互運用性のために、正規の形式は、すべてのRRタイプのために変わらずそのその初期発行RFCとしてRFC（RFC 3597）、本明細書の最初の出版前にありました。
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.
実装者への礼儀として、埋め込まれたドメイン名を含む、このような以前に発表されたRRタイプの完全なセット、およびそのDNSSEC正規形ので、文字比較のためのDNS規則に従ってdowncasing含まれ、RRタイプのNSで構成されていることをここに注目されますMD、MF、CNAME、SOA、MB、MG、MR、PTR、HINFO、MINFO、MX、HINFO、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.
この文書は、他のすべてのRRタイプ（不明な型として扱わまたはRFC 3597よりも新しいRRタイプ定義RFCに応じて公知の型として扱わいるかどうか）のために、正規の形式が埋め込まれたドメイン名のないdowncasingが行われないようなものであることを指定し、 [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.
所有者名は関係なく、常にRRタイプの、文字比較のための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.
オクテット配列が本明細書によって改訂されたように標準形式である[RFC2535]セクション8.3で指定されるようにDNSSEC正規RRの順序です。
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.
未知のRRタイプには、追加のセクション処理を引き起こしません。未来のRRタイプの仕様は、タイプ固有の追加セクション処理規則を指定するかもしれないが、それが唯一の場合のRRタイプが知られているサーバによって行うことができるように、そのような処理は任意でなければなりません。
This document does not require any IANA actions.
このドキュメントは、IANAのアクションを必要としません。
This specification is not believed to cause any new security problems, nor to solve any existing ones.
この仕様は、任意の新しいセキュリティ上の問題を引き起こすこと、また、既存のものを解決するために考えられません。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、R.、エド、 "インターネットホストのための要件 - 、アプリケーションとサポート"。、STD 3、RFC 1123、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)", RFC 2163, January 1998.
[RFC2163] Allocchio、C.、RFC 2163 "MIXER適合のグローバルアドレスマッピング（MCGAM）を配布するには、インターネットDNSを使用する"、1998年1月。
[RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000.
[RFC2929]イーストレーク、D.、ブルンナー - ウィリアムズ、E.およびB.マニング、 "ドメインネームシステム（DNS）IANAの考慮事項"、BCP 42、RFC 2929、2000年9月。
[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.
[RFC1876]デイビス、C.、いるVixie、P.、グッドウィン、T.およびI.ディッキンソン、 "ドメインネームシステムに位置情報を表現するための手段"、RFC 1876、1996年1月。
[RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2052] Gulbrandsenの、A.及びP.いるVixie、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2052、1996年10月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]いるVixie、P.編、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.及びL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
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の手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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専務に情報を扱ってください。
Andreas Gustafsson Nominum, Inc. 2385 Bay Rd Redwood City, CA 94063 USA
アンドレアス・グスタフソンノミナム社2385ベイRdのレッドウッドシティー、CA 94063 USA
Phone: +1 650 381 6004 EMail: gson@nominum.com
電話：+1 650 381 6004 Eメール：gson@nominum.com
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 Editor機能のための基金は現在、インターネット協会によって提供されます。