[要約] RFC 3597は、DNSの未知のリソースレコード（RR）タイプの処理に関するガイドラインです。その目的は、未知のRRタイプに対して互換性のある処理方法を提供することです。
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.
Copyright（c）The Internet Society（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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またはメタタイプではないRRです。そのセクションでは、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を透過的に処理する必要があります。つまり、そのようなRRのRDATAセクションを非構造化されたバイナリデータとして扱い、変更せずに保存および送信する必要があります[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標準形式（セクション7）の正しい動作を確保するには、RRタイプが一部ではなく一部ではなく一部に知られている場合、サーバーは既知のタイプの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部分に圧縮ポインターを含むRRSは透過的に処理することはできません。RDATAを新しい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".
このような破損を回避するために、サーバーはクラス固有またはよく知られていないタイプの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 RRSおよびNXT RRSレコードでの圧縮を許可することを指定しました。この仕様はこれらの場合に圧縮を許可するため、[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).
受信サーバーは、よく知られているタイプのRRでドメイン名を解凍する必要があり、タイプRP、AFSDB、RT、SIG、PX、NAPTR、およびSRVのRRを解凍する必要があります（ただし、[RFC2782]のSRV RRの現在の仕様[RFC2052]が義務付けられた[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タイプ番号が付いており、介在した空白はありません。「クラス」フィールドでは、未知のクラスも同様に「クラス」という単語として表されます。その後、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値と区別することができ、「[<ttl>] [<class>] <Type> <rdata>」と「[<class>] [<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.
特別なトークン\＃（すぐにハッシュサインが続くバックスラッシュ）。これは、従来のタイプ固有のエンコードではなく、ここで定義されている一般的なエンコードを識別します。
An unsigned decimal integer specifying the RDATA length in octets.
オクテットのrDATA長を指定する署名されていない小数整数。
Zero or more words of hexadecimal data encoding the actual RDATA field, each containing an even number of hexadecimal digits.
実際のrdataフィールドをエンコードする16進数データのゼロ以上の単語。それぞれに偶数の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タイプの場合にも役立ちます。フィールドには、テキスト形式が知られていない値があります。たとえば、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
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を比較する必要があります。同じ未知のタイプの2つのRRは、RDATAがビットごとに等しい場合、等しいと見なされます。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は、RRS [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.
ドメイン名のケースの区別が圧縮により失われた場合、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タイプの完全なセット、したがって、文字比較のDNSルールに従ってDNSルールに従ってダウンケーシングが含まれることは、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タイプ（未知のタイプとして扱われるか、RRタイプ定義RFCに従ってRFC 3597よりも最近の既知のタイプとして扱われているかにかかわらず）であることを指定しています。それ以外の場合は、[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.
DNSSEC標準的なRR順序は、[RFC2535]セクション8.3で指定されているとおりです。ここで、オクテットシーケンスはこの仕様で改訂された標準形式です。
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] Braden、R.、ed。、「インターネットホストの要件 - アプリケーションとサポート」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、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。、「インターネットDNSを使用してミキサーコンフォーマントグローバルアドレスマッピング（MCGAM）を配布する」、RFC 2163、1998年1月。
[RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000.
[RFC2929] Eastlake、D.、Brunner-Williams、E。およびB. Manning、「ドメイン名システム（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] Davis、C.、Vixie、P.、Goodwin、T。、およびI. Dickinson、「ドメイン名システムで位置情報を表現する手段」、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.、Ed。、Thomson、S.、Rekhter、Y。およびJ. Bound、「ドメイン名システムの動的更新（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。and L. Esibov、「サービスの場所（DNS SRV）を指定するためのDNS RR」、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
Andreas Gustafsson Nominum、Inc。2385 Bay Rd Redwood City、CA 94063 USA
Phone: +1 650 381 6004
EMail: gson@nominum.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。