RFC2825 日本語訳
2825 A Tangled Web: Issues of I18N, Domain Names, and the OtherInternet protocols. IAB, L. Daigle, Ed.. May 2000. (Format: TXT=15612 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Internet Architecture Board (IAB) Request for Comments: 2825 L. Daigle, Editor Category: Informational May 2000
ネットワークワーキンググループインターネット・アーキテクチャ委員会(IAB)はコメントのために以下を要求します。 2825L.Daigle、エディタカテゴリ: 情報の2000年5月
A Tangled Web: Issues of I18N, Domain Names, and the
Other Internet protocols
もつれているウェブ: I18N、Domain Names、およびOtherインターネットプロトコルの問題
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
The goals of the work to "internationalize" Internet protocols include providing all users of the Internet with the capability of using their own language and its standard character set to express themselves, write names, and to navigate the network. This impacts the domain names visible in e-mail addresses and so many of today's URLs used to locate information on the World Wide Web, etc. However, domain names are used by Internet protocols that are used across national boundaries. These services must interoperate worldwide, or we risk isolating components of the network from each other along locale boundaries. This type of isolation could impede not only communications among people, but opportunities of the areas involved to participate effectively in e-commerce, distance learning, and other activities at an international scale, thereby retarding economic development.
そして、インターネットプロトコルを「国際化する」仕事の目標が、言い表すそれら自身の言語とその標準文字セットを使用する能力をインターネットのすべてのユーザに提供するのを含んで、名前を書いてください、ネットワークにナビゲートするために。 Eメールアドレスで目に見えるドメイン名であって今日のこれが影響を与えるWorld Wide Webなどの情報の場所を見つけるのに使用されるURLはとても多いです。 しかしながら、ドメイン名は国境の向こう側に使用されるインターネットプロトコルによって使用されます。 これらのサービスが世界中に共同利用しなければならない、さもなければ、私たちは現場境界に沿って互いからネットワークの成分を隔離する危険を冒します。 このタイプの分離は人々のコミュニケーションだけではなく、国際的なスケールで有効に電子商取引、通信教育、および他の活動に参加するためにかかわる領域の機会も妨害するかもしれません、その結果、経済開発を遅らせます。
There are several proposals for internationalizing domain names, however it it is still to be determined whether any of them will ensure this interoperability and global reach while addressing visible-name representation. Some of them obviously do not. This document does not attempt to review any specific proposals, as that is the work of the Internationalized Domain Name (IDN) Working Group of the IETF, which is tasked with evaluating them in consideration of the continued global network interoperation that is the deserved expectation of all Internet users.
しかしながら、ドメイン名、それを国際的にするための彼らのどれかが目に見える名前表現を扱っている間、この相互運用性とグローバルな範囲を確実にするか否かに関係なく、まだ断固としていることになっているといういくつかの提案があります。 それらのいくつかは明らかにそうしません。 このドキュメントは、どんな明確な提案、同じくらいすなわち、IETFのInternationalized Domain Name(IDN)作業部会の仕事も見直すのを試みません。IETFはすべてのインターネットユーザへの価値がある期待である継続的な世界的なネットワークinteroperationを考慮してそれらを評価するのに仕事を課されます。
IAB Informational [Page 1] RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
IABの情報[1ページ]のRFC2825問題: I18N、ドメイン名、およびインターネットプロトコル2000年5月
This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces.
このドキュメントはインターネット・アーキテクチャ委員会による声明です。 それはプロトコル仕様ではなく、ドメイン名の国際化が直面している構造的な問題の範囲をはっきりさせる試みです。
1. A Definition of Success
1. 成功の定義
The Internationalized Domain Names (IDN) Working Group is one component of the IETF's continuing comprehensive effort to internationalize language representation facilities in the protocols that support the global functioning of the Internet.
Internationalized Domain Names(IDN)作業部会はインターネットのグローバルな機能をサポートするプロトコルで言語表現施設を国際的にするIETFの継続する包括的な取り組みの1つのコンポーネントです。
In keeping with the principles of rough consensus, running code, architectural integrity, and in the interest of ensuring the global stability of the Internet, the IAB emphasizes that all solutions proposed to the (IDN) Working Group will have to be evaluated not only on their individual technical features, but also in terms of impact on existing standards and operations of the Internet and the total effect for end-users: solutions must not cause users to become more isolated from their global neighbors even if they appear to solve a local problem. In some cases, existing protocols have limitations on allowable characters, and in other cases implementations of protocols used in the core of the Internet (beyond individual organizations) have in practice not implemented all the requisite options of the standards.
荒いコンセンサスの原則でコードを実行する建築保全を保つ、インターネットの大局的安定を確実にすることおよびのために、IABは、(IDN)作業部会に提案されたすべてのソリューションがそれらの個々の技術的特徴で評価されるだけではなく、既存の規格に関する影響、インターネットの操作、およびエンドユーザのための全効果でも評価されなければならないと強調します: ソリューションによって、彼らが、ローカルの問題を解決するように見えても、ユーザは彼らのグローバルな隣人から、より孤立するようになってはいけません。 いくつかの場合、既存のプロトコルは許容できるキャラクタの上に制限を持っています、そして、他の場合では、インターネット(個々の組織を超えた)のコアで使用されるプロトコルの実装は実際には規格のすべての必要なオプションを実装するというわけではありませんでした。
2. Technical Challenges within the Domain Name System (DNS)
2. ドメインネームシステムの中の技術的難関(DNS)
In many technical respects, the IDN work is not different from any other effort to enable multiple character set representations in textual elements that were traditionally restricted to English language characters.
多くの技術的な点で、IDN仕事は複数の文字集合表現を可能にするいかなる他の取り組みとも英語キャラクタに伝統的に制限された原文の要素において異なっていません。
One aspect of the challenge is to decide how to represent the names users want in the DNS in a way that is clear, technically feasible, and ensures that a name always means the same thing. Several proposals have been suggested to address these issues.
挑戦の1つの局面はユーザがDNSで明確であって、技術的に可能であり、名前がいつも同じものを意味するのを確実にする方法で欲しい名前を表す方法を決めることです。 いくつかの提案が、これらの問題を扱うために示されました。
These issues are being outlined in more detail in the IDN WG's evolving draft requirements document; further discussion is deferred to the WG and its documents.
これらの問題はさらに詳細にIDN WGの発展している草稿要件ドキュメントに概説されています。 さらなる議論はWGとそのドキュメントに延期されます。
3. Integrating with Current Realities
3. 現在の現実と統合します。
Nevertheless, issues faced by the IDN working group are complex and intricately intertwined with other operational components of the Internet. A key challenge in evaluating any proposed solution is the analysis of the impact on existing critical operational standards
それにもかかわらず、IDNワーキンググループによって直面されていた問題は、複雑であり、インターネットの他の操作上のコンポーネントで複雑にからみ合います。 どんな提案されたソリューションも評価することにおける主要な挑戦は既存の重要な操作上の規格における影響の分析です。
IAB Informational [Page 2] RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
IABの情報[2ページ]のRFC2825問題: I18N、ドメイン名、およびインターネットプロトコル2000年5月
which use fully-qualified domain names [RFC1034], or simply host names [RFC1123]. Standards-changes can be effected, but the best path forward is one that takes into account current realities and (re)deployment latencies. In the Internet's global context, it is not enough to update a few isolated systems, or even most of the systems in a country or region. Deployment must be nearly universal in order to avoid the creation of "islands" of interoperation that provide users with less access to and connection from the rest of the world.
完全修飾ドメイン名[RFC1034]、または単にホスト名[RFC1123]を使用します。 規格変化は作用できますが、最も良い経路フォワードは現在の現実と(re)展開潜在を考慮に入れるものです。 インターネットの世界状況では、国か領域でいくつかの孤立系、またはシステムの大部分さえアップデートするのは十分ではありません。 展開は、他の国々からの、より少ないアクセスと接続をユーザに提供するinteroperationの「島」の作成を避けるためにほとんど普遍的でなければなりません。
These are not esoteric or ephemeral concerns. Some specific issues have already been identified as part of the IDN WG's efforts. These include (but are not limited to) the following examples.
これらは難解であるかはかない関心ではありません。 いくつかの特定の問題がIDN WGの取り組みの一部として既に特定されました。 しかし、これらが含んでいる、(制限されない、)、以下の例。
3.1 Domain Names and E-mail
3.1のドメイン名とメール
As indicated in the IDN WG's draft requirements document, the issue goes beyond standardization of DNS usage. Electronic mail has long been one of the most-used and most important applications of the Internet. Internet e-mail is also used as the bridge that permits the users of a variety of local and proprietary mail systems to communicate. The standard protocols that define its use (e.g., SMTP [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of characters allowed in the DNS specification. Certain characters are not allowed in e-mail address domain portions of these specifications. Some mailers, built to adhere to these specifications, are known to fail when on mail having non-ASCII domain names in its address -- by discarding, misrouting or damaging the mail. Thus, it's not possible to simply switch to internationalized domain names and expect global e-mail to continue to work until most of the servers in the world are upgraded.
IDN WGの草稿要件ドキュメントにみられるように、問題はDNS用法の標準化を越えます。 長い間、電子メールはインターネットの最も中古の、そして、最も重要なアプリケーションの1つです。 また、インターネット電子メールはさまざまな地方の、そして、独占であるメールシステムのユーザが交信することを許可するブリッジとして使用されます。 使用(例えば、SMTP[RFC821、RFC822]とMIME[RFC2045])を定義する標準プロトコルはDNS仕様に許容された最大限の範囲のキャラクタを可能にしません。 確信しているキャラクタはこれらの仕様のEメールアドレスドメイン部分に許容されていません。 非ASCIIドメイン名を持っているメールにあるとき、これらの仕様を固く守るために建てられた何人かの郵送者がアドレスで失敗するのが捨てることによって、知られています、メールをmisroutingするか、または破損して。 したがって、単に国際化ドメイン名に切り替わって、グローバルなメールが、世界のサーバの大部分がアップグレードするまで働き続けていると予想するのは可能ではありません。
3.2 Domain Names and Routing
3.2 ドメイン名とルート設定
At a lower level, the Routing Policy Specification Language (RPLS) [RFC2622] makes use of "named objects" -- and inherits object naming restrictions from older standards ([RFC822] for the same e-mail address restrictions, [RFC1034] for hostnames). This means that until routing registries and their protocols are updated, it is not possible to enter or retrieve network descriptions utilizing internationalized domain names.
下のレベルでは、Policy Specification Language(RPLS)[RFC2622]が利用するルート設定は「オブジェクトを命名しました」--そして、より古い規格(同じEメールアドレス制限のための[RFC822]、ホスト名のための[RFC1034])からオブジェクト命名制限を引き継ぎます。 これは、国際化ドメイン名を利用するネットワーク記述を入るか、または検索するのがルーティング登録とそれらのプロトコルをアップデートするまで可能でないことを意味します。
3.3 Domain Names and Network Management
3.3 ドメイン名とネットワークマネージメント
Also, the Simple Network Management Protocol (SNMP) uses the textual representation defined in [RFC2579]. While that specification does allow for UTF-8-based domain names, an informal survey of deployed implementations of software libraries being used to build SNMP- compliant software uncovered the fact that few (if any) implement it.
また、Simple Network Managementプロトコル(SNMP)は[RFC2579]で定義された原文の表現を使用します。 その仕様はUTF-8ベースのドメイン名を考慮しますが、SNMP対応することのソフトウェアを組立てるのに使用されるソフトウェア・ライブラリの配布している実装の非公式の調査はわずか(もしあれば)しかそれを実装しないという事実を暴露しました。
IAB Informational [Page 3] RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
IABの情報[3ページ]のRFC2825問題: I18N、ドメイン名、およびインターネットプロトコル2000年5月
This may cause inability to enter or display correct data in network management tools, if such names are internationalized domain names.
これはネットワークマネージメントツールにおける正しいデータを入力できないか、表示できないことを引き起こすかもしれません、そのような名前が国際化ドメイン名であるなら。
3.4 Domain Names and Security
3.4 ドメイン名とセキュリティ
Critical components of Internet public key technologies (PKIX, [RFC2459], IKE [RFC2409]) rely heavily on identification of servers (hostnames, or fully qualified domain names) and users (e-mail addresses). Failure to respect the character restrictions in these protocols will impact security tools built to use them -- Transport Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name two.
インターネット公開鍵技術(PKIX、[RFC2459]、IKE[RFC2409])の重要な要素は大いにサーバ(ホスト名、または完全修飾ドメイン名)とユーザ(Eメールアドレス)の識別に依存します。 これらのプロトコルにおけるキャラクタ制限を尊敬しないと、それらを使用するために築き上げられたセキュリティツールに影響を与えるでしょう--Layer Securityプロトコル(TLS、[RFC2246])、およびIPsec[RFC2401]を輸送して、2を命名してください。
Failure may not be obvious. For example, in TLS, it is common usage for a server to display a certificate containing a domain name purporting to be the domain name of the server, which the client can then match with the server name he thought he used to reach the service.
失敗は明白でないかもしれません。 例えば、TLSでは、サーバが次に、クライアントがサービスに達するのに使用したと考えたサーバー名に合わせることができるサーバのドメイン名であることを意味するドメイン名を含む証明書を表示するのは、一般的な用法です。
Unless comparison of domain names is properly defined, the client may either fail to match the domain name of a legitimate server, or match incorrectly the domain name of a server performing a man-in-the- middle attack. Either failure could enable attacks on systems that are now impossible or at least far more difficult.
ドメイン名の比較が適切に定義されない場合、クライアントが正統のサーバのドメイン名を合わせないか、または不当に中の男性を実行するサーバのドメイン名に合うかもしれない、-、-中央は攻撃されます。 失敗は現在、不可能であるか、または少なくともはるかに難しいシステムに対する攻撃を可能にするかもしれません。
4. Conclusion
4. 結論
It is therefore clear that, although there are many possible ways to assign internationalized names that are compatible with today's DNS (or a version that is easily-deployable in the near future), not all of them are compatible with the full range of necessary networking tools. When designing a solution for internationalization of domain names, the effects on the current Internet must be carefully evaluated. Some types of solutions proposed would, if put into effect immediately, cause Internet communications to fail in ways that would be hard to detect by and pose problems for those who deploy the new services, but also for those who do not; this would have the effect of cutting those who deploy them off from effective use of the Internet.
したがって、今日のDNS(または、近い将来容易に配布可能なバージョン)と互換性がある国際化している名前を割り当てる多くの可能な方法がありますが、彼らは皆、最大限の範囲の必要なネットワークツールと互換性があるというわけではないのが、明確です。 ドメイン名の国際化のためにソリューションを設計するとき、慎重に現在のインターネットへの効果を評価しなければなりません。 新種業務を配布する人のためにすぐに効果に入れるならインターネット通信が検出しにくい道に失敗することを引き起こして、問題を引き起こしますが、提案されたソリューションの何人かのタイプはそうしないそれらのためにもそうするでしょう。 これには、インターネットの有効な使用からそれらを配布する人を断ち切るという効果があるでしょう。
The IDN WG has been identified as the appropriate forum for identifying and discussing solutions for such potential interoperability issues.
IDN WGはそのような潜在的相互運用性問題のためにソリューションを特定して、議論するための適切なフォーラムとして特定されました。
Experience with deployment of other protocols has indicated that it will take years before a new protocol or enhancement is used all over the Internet. So far, the IDN WG has benefited from proposed solutions from all quarters, including organizations hoping to
他のプロトコルの展開の経験は、新しいプロトコルか増進がインターネット全体にわたって使用される前にそれが何年もかかるのを示しました。 今までのところ、組織を含んでいるのが、望んでいて、IDN WGはいたる所から提案されたソリューションの利益を得ました。
IAB Informational [Page 4] RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
IABの情報[4ページ]のRFC2825問題: I18N、ドメイン名、およびインターネットプロトコル2000年5月
provide services that address visible-name representation and registration -- continuing this process with the aim of getting a single, scalable and deployable solution to this problem is the only way to ensure the continued global interoperation that is the deserved expectation of all Internet users.
そのアドレス目に見える名前表現と登録をサービスに提供してください--単一の、そして、スケーラブルで配布可能なソリューションをこの問題に得る目的があるこのプロセスを持続させるのは、すべてのインターネットユーザへの価値がある期待である継続的なグローバルなinteroperationを確実にする唯一の方法です。
5. Security Considerations
5. セキュリティ問題
In general, assignment and use of names does not raise any special security problems. However, as noted above, some existing security mechanisms are reliant on the current specification of domain names and may not be expected to work, as is, with Internationalized domain names. Additionally, deployment of non-standard systems (e.g., in response to current pressures to address national or regional characterset representation) might result in name strings that are not globally unique, thereby opening up the possibility of "spoofing" hosts from one domain in another, as described in [RFC2826].
一般に、名前の課題と使用はどんな特別担保問題も提起しません。しかしながら、いくつかの既存のセキュリティー対策が、上で述べたように、ドメイン名の現在の仕様に頼って、働かないと予想されるかもしれません、そのままです、Internationalizedドメイン名で。 さらに、標準的でないシステム(例えば、国家の、または、地方のキャラクタセットが表現であると扱う現在の圧力に対応した)の展開はグローバルにユニークでない名前ストリングをもたらすかもしれません、その結果、ホストの別のものの1つのドメインからの「偽造する」である可能性を開けます、[RFC2826]で説明されるように。
6. Acknowledgements
6. 承認
This document is the outcome of the joint effort of the members of the IAB. Additionally, valuable remarks were provided by Randy Bush, Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.
このドキュメントはIABのメンバーの共同努力の結果です。 さらに、貴重な所見はランディ・ブッシュ、パトリクFaltstrom、テッド・ハーディー、ポール・ホフマン、およびマークKostersによって提供されました。
7. References
7. 参照
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[RFC821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1123] Braden, R., "Requirements for Internet Hosts -- Application
and Support", STD 3, RFC 1123, November 1989.
[RFC1123]ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、11月1989日
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409] ハーキンとDとD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
IAB Informational [Page 5] RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
IABの情報[5ページ]のRFC2825問題: I18N、ドメイン名、およびインターネットプロトコル2000年5月
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
[RFC2459] HousleyとR.とフォードとW.とポークとW.と一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC2459、1999年1月。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.
and M. Rose, "Textual Conventions for SMIv2", RFC 2579,
April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とM.ローズ、「SMIv2"、RFC2579、1999年4月の原文のコンベンション。」
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622,
June 1999.
[RFC2622] AlaettinogluとC.とVillamizarとC.とGerichとE.とKessensとD.とマイヤーとD.とベイツとT.とKarrenbergとD.とM.テルプストラ、「ルート設定方針仕様言語(RPSL)」、RFC2622、1999年6月。
[RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC
2826, May 2000.
[RFC2826]IAB(「ユニークなDNS根のIABの技術的なコメント」、RFC2826)は2000がそうするかもしれません。
8. Author's Address
8. 作者のアドレス
Internet Architecture Board
インターネット・アーキテクチャ委員会
EMail: iab@iab.org
メール: iab@iab.org
Membership at time this document was completed:
このドキュメントが完成した時の会員資格:
Harald Alvestrand
Ran Atkinson
Rob Austein
Brian Carpenter
Steve Bellovin
Jon Crowcroft
Leslie Daigle
Steve Deering
Tony Hain
Geoff Huston
John Klensin
Henning Schulzrinne
ハラルドAlvestrandはアトキンソンロブAusteinブライアン大工スティーブBellovinジョンクロウクロフトレスリーDaigleスティーブデアリングトニーハインジェフヒューストンジョンKlensinヘニングSchulzrinneを走らせました。
IAB Informational [Page 6] RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
IABの情報[6ページ]のRFC2825問題: I18N、ドメイン名、およびインターネットプロトコル2000年5月
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
IAB Informational [Page 7]
IAB情報です。[7ページ]
一覧
スポンサーリンク
