Network Working Group R. Petke
Request for Comments: 2717 UUNET Technologies
BCP: 35 I. King
Category: Best Current Practice Microsoft Corporation
November 1999
Registration Procedures for URL Scheme Names
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document defines the process by which new URL scheme names are registered.
この文書は、新しいURLスキーム名が登録されていることにより、プロセスを定義します。
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet. RFC 2396 [1] defines the general syntax and semantics of URIs, and, by inclusion, URLs. URLs are designated by including a "<scheme>:" and then a "<scheme-specific-part>". Many URL schemes are already defined, however, new schemes may need to be defined in the future in order to accommodate new Internet protocols and/or procedures.
ユニフォームリソースロケータ（URL）は、インターネットを介して利用可能であるリソースの位置のコンパクトな文字列表現です。 RFC 2396 [1] URIの一般的な構文及びセマンティクスを定義し、そして、封入により、URLを。 「<スキーム>：」とし、「<スキーム固有の部分>」のURLが含むことによって指定されています。多くのURLスキームがすでに定義されている、しかし、新しいスキームは、新しいインターネット・プロトコルおよび/または手続きに対応するために、将来的に定義する必要があるかもしれません。
A registration process is needed to ensure that the names of all such new schemes are guaranteed not to collide. Further, the registration process ensures that URL schemes intended for wide spread, public use are developed in an orderly, well-specified, and public manner.
登録プロセスはすべて、このような新しいスキームの名前が衝突しないことが保証されていることを確認するために必要とされます。さらに、登録プロセスは、普及のために意図URLスキームは、公共の使用は、秩序よく指定、および公共の方法で開発されていることを保証します。
This document defines the registration procedures to be followed when new URL schemes are created. A separate document, RFC 2718, Guidelines for URL Schemes [2], provides guidelines for the creation of new URL schemes. The primary focus of this document is on the <scheme> portion of new URL schemes, referred to as the "scheme name" throughout this document.
この文書は、新しいURLスキームを作成するときに従うべき登録手続きを定義します。別の文書、RFC 2718、URLスキームのためのガイドライン[2]は、新しいURLスキームを作成するためのガイドラインを提供します。このドキュメントの主な焦点は、この文書を通じて、「スキーム名」と呼ばれる、新しいURLスキームの<スキーム>の部分です。
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に記載されるように解釈されます。
In order to increase the efficiency and flexibility of the URL scheme name registration process, the need is recognized for multiple registration "trees". The registration requirements and specific registration procedures for each tree differ, allowing the overall registration procedure to accommodate the different natural requirements for URL schemes. For example, a scheme that will be recommended for wide support and implementation by the Internet community requires a more complete review than a scheme intended to be used for resources associated with proprietary software.
URLスキーム名の登録プロセスの効率性と柔軟性を高めるために、必要性は、複数の登録「の木」のために認識されています。各ツリーの登録要件と特定の登録手続きは、全体的な登録手続きは、URLスキームのためのさまざまな自然の要件に対応できるように、異なっています。例えば、インターネットコミュニティで幅広い支持と実装のために推奨される方式では、独自のソフトウェアに関連するリソースのために使用されることを意図したスキームよりも、より完全な見直しが必要です。
The first step in registering a new URL scheme name is to determine which registration tree the scheme should be registered in. Determination of the proper registration tree is based on the intended use for the new scheme and the desired syntax for the scheme name.
新しいURLスキーム名を登録する最初のステップは、スキームはに登録すべき登録木決定することである。適切な登録ツリーの決定は、新たなスキームとスキーム名のために必要な構文の使用目的に基づいています。
This document will discuss in detail the tree that reflects current practice, under IETF ownership and control. It will also set forth an outline to assist authors in creating new trees to address differing needs for wide acceptance and interoperability, ease of creation and use, and type and "strength" of ownership.
この文書は、IETF所有と支配の下で、詳細に現在の慣行を反映したツリーを説明します。また、広く受け入れと相互運用性、創造性と使いやすさ、および種類と所有の「強さ」のための様々なニーズに対応するために、新しいツリーを作成するには、著者を支援するために、アウトラインを述べます。
The IETF tree is intended for URL schemes of general interest to the Internet community. The tree exists for URL schemes that require a substantive review and approval process. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, URL schemes that have proven particularly useful in those contexts.
IETFツリーはインターネットコミュニティへの一般的な関心のURLスキームを対象としています。ツリーは、実質的なレビューと承認プロセスを必要とURLスキームのために存在します。特定のアプリケーションのための適用性ステートメントが時間から、それらの文脈で特に有用であることが証明され、URLスキームのための実装、およびサポートをお勧めします時間に公開されることが期待されます。
From time to time and as required by the community, the IESG may create new top-level registration trees. These trees may require significant, little or no registration, and may allow change control to rest in the hands of individuals or groups other than IETF. A new tree should only be created if no existing tree can be shown to address the set of needs of some sector of the community.
時々、コミュニティの要求に応じて、IESGは新しいトップレベル登録木を作成することができます。これらの木は、大きなほとんど、あるいはまったく登録を必要とするかもしれないし、個人またはIETF以外のグループの手の中に残りの部分に変更制御を可能にすることができます。既存のツリーは、コミュニティの一部の部門のニーズのセットに対処するために示すことができない場合、新しいツリーにのみ作成する必要があります。
All new URL schemes, regardless of registration tree, MUST conform to the generic syntax for URLs as specified in RFC 2396.
RFC 2396で指定されているすべての新しいURLスキームは、登録木にかかわらず、URLの一般的な構文に従わなければなりません。
Registration in the IETF tree requires publication of the URL scheme syntax and semantics in either an Informational or Standards Track RFC. In general, the creation of a new URL scheme requires a Standards Track RFC. An Informational RFC may be employed for registration only in the case of a URL scheme which is already in wide usage and meets other standards set forth in RFC 2718, such as "demonstrated utility" within the Internet Architecture; the IESG shall have broad discretion in determining whether an Informational RFC is suitable in any given case, and may either recommend changes to such document prior to publication, or reject it for publication. An Informational RFC purporting to describe a URL scheme shall not be published without IESG approval. This is a departure from practice for Informational RFCs as set forth in RFC 2026, for the purpose of ensuring that the registration of URL schemes shall serve the best interests of the Internet community.
IETF木への登録は、情報や標準化過程RFCのいずれかでURLスキームの構文およびセマンティクスの公表を必要とします。一般的には、新しいURLスキームの作成は、標準化過程のRFCが必要です。情報RFCは、幅広い用途で既にあり、このようなインターネットアーキテクチャ内の「有用性を実証した」としてRFC 2718に記載された他の基準を満たしているURLスキームの場合には、登録のために使用することができます。 IESGは情報RFCは、任意の所与の場合に適しているかどうかを決定する際に幅広い裁量を有するもの、及び出版物の前に、文書への変更を勧め、又は出版のためにそれを拒絶することができるいずれか。 URLスキームを記述するために主張する情報のRFCは、IESGの承認を得ずに公開してはなりません。これはURLスキームの登録はインターネットコミュニティの最善の利益に資するものとすることを確保するために、RFC 2026に記載された情報のRFCの実践からの出発です。
The NAMES of schemes registered in the IETF tree MUST NOT contain the dash (also known as the hyphen and minus sign) character ('-') USASCII value 2Dh. Use of this character can cause confusion with schemes registered in alternative trees (see section 3.3).
（「 - 」）USASCII値は2Dh IETF木に登録スキームの名前は（もハイフンとマイナス記号として知られている）ダッシュ文字を含めることはできません。この文字の使用は、代替の木（セクション3.3を参照）に登録されたスキームとの混同を引き起こす可能性があります。
An analysis of the security issues inherent in the new URL scheme is REQUIRED. (This is in accordance with the basic requirements for all IETF protocols.) URL schemes registered in the IETF tree should not introduce additional security risks into the Internet Architecture. For example, URLs should not embed information which should remain confidential, such as passwords, nor should new schemes subvert the security of existing schemes or protocols (i.e. by layering or tunneling).
新しいURLスキームに内在するセキュリティ問題の分析が必要となります。 （これは、すべてのIETFプロトコルのための基本的な要件に準拠している。）IETF木に登録したURLスキームは、インターネットアーキテクチャの中に追加のセキュリティリスクを導入してはなりません。例えば、URLは、パスワードなど、機密のままでなければならない情報を埋め込むべきではない、また新しいスキーム（すなわち積層又はトンネリングによる）は、既存のスキームまたはプロトコルのセキュリティを破壊すべきです。
The "owner" of a URL scheme name registered in the IETF tree is assumed to be the IETF itself. Modification or alteration of the specification requires the same level of processing (e.g. Informational or Standards Track RFC) as used for the initial registration. Schemes originally defined via an Informational RFC may, however, be replaced with Standards Track documents.
IETF木に登録URLのスキーム名の「所有者」IETF自体を想定しています。初期登録のために使用されるような仕様の修正または変更は処理の同じレベル（例えば、情報又は標準化過程RFC）を必要とします。もともと情報RFC経由で定義されたスキームは、しかし、標準化過程の文書に置き換えてもよいです。
While public exposure and review of a URL scheme created in an alternative tree is not required, using the IETF Internet-Draft mechanism for peer review is strongly encouraged to improve the quality of the specification. RFC publication of alternative tree URL schemes is encouraged but not required. Material may be published as an Informational RFC by sending it to the RFC Editor (please follow the instructions to RFC authors, RFC 2223 [3]).
代替の木で作成されたURLスキームの公開露出と見直しが必要とされていないが、ピアレビューのためのIETFインターネットドラフトのメカニズムを使用することを強く仕様の品質を向上することが奨励されます。代替の木のURLスキームのRFC公表は、奨励が、必須ではありません。材料はRFCエディタにそれを送信することにより、情報のRFCとして公開することができる（RFC作者への指示に従ってください、RFC 2223 [3]）。
The defining document for an alternative tree may require public exposure and/or review for schemes defined in that tree via a mechanism other than the IETF Internet-Draft mechanism.
代替ツリーの定義文書は、IETFインターネットドラフト以外の機構を経由して、そのツリーに定義されたスキームの公衆の曝露および/または見直しを必要とするかもしれません。
URL schemes created in an alternative tree must conform to the generic URL syntax, RFC 2396. The tree's defining document may set forth additional syntax and semantics requirements above and beyond those specified in RFC 2396.
代替の木で作成されたURLスキームは、一般的なURL構文に準拠する必要があり、RFC 2396ツリーの定義文書では、上記とRFC 2396で指定されたもの以外の追加の構文と意味の要件を設定することがあります。
All new URL schemes SHOULD follow the Guidelines for URL Schemes, set forth in RFC 2718 [2].
すべての新しいURLスキームはRFC 2718に記載されたURLスキームのためのガイドラインに従うべきである[2]。
An analysis of the security issues inherent in the new URL scheme is encouraged. Regardless of what security analysis is or is not performed, all descriptions of security issues must be as accurate as possible. In particular, a statement that there are "no security issues associated with this scheme" must not be confused with "the security issues associates with this scheme have not been assessed" or "the security issues associated with this scheme cannot be predicted because of <reason>".
新しいURLスキームに内在するセキュリティ問題の分析が奨励されています。かかわらず、セキュリティ分析があるか行われていないものの、セキュリティ問題のすべての記述は、可能な限り正確でなければなりません。具体的には、「このスキームに関連したセキュリティ上の問題が」存在しないという声明は「このスキームでのセキュリティ問題の仲間が評価されていない」または「のため、このスキームに関連するセキュリティ上の問題を予測することはできないと混同してはいけません<理由>」。
There is absolutely no requirement that URL schemes created in an alternative tree be secure or completely free from risks. Nevertheless, the tree's defining document must set forth the standard for security considerations, and in any event all known security risks SHOULD be identified.
代替の木で作成されたURLスキームが安全やリスクから完全に自由である必要は全くありません。それにもかかわらず、ツリーの定義文書では、セキュリティ上の配慮のための標準を定める必要があり、いずれにしても、すべての既知のセキュリティリスクが特定されるべきです。
Change control must be defined for a new tree. Change control may be vested in the IETF, or in an individual, group or other entity. The change control standard for the tree must be approved by the IESG.
変更管理は、新しいツリーを定義する必要があります。変更管理は、IETFにおいて、または個人、グループまたは他のエンティティに帰属することができます。ツリーの変更管理標準は、IESGによって承認されなければなりません。
The syntax for alternative trees shall be as follows: each tree will be identified by a unique prefix, which must be established in the same fashion as a URL scheme name in the IETF tree, except that the prefix must be defined by a Standards Track document. Scheme names in the new tree are then constructed by prepending the prefix to an identifier unique to each scheme in that tree, as prescribed by that tree's identifying document:
各ツリーは、接頭辞が標準化過程の文書で定義されなければならないことを除いて、IETFツリー内のURLのスキーム名と同じ方法で確立されなければならない独自の接頭辞によって識別されます。次のように代替の木の構文はしなければなりません。そのツリーの特定の文書で規定され、新しいツリー内のスキーム名は、その後、そのツリー内の各スキームに固有の識別子にプレフィックスを付加することによって構築されています。
<prefix>'-'<tree-specific identifier>
<プレフィックス>「 - 」<ツリー固有の識別子>
For instance, the "foo" tree would allow creation of scheme names of the form: "foo-blahblah:" and "foo-bar:", where the tree prescribes an arbitrary USASCII string following the tree's unique prefix.
「FOO-blahblah：」と「FOO-バー：」、木は木のユニークな接頭辞を次任意のUSASCII文字列を規定たとえば、「foo」という木は、フォームのスキーム名の作成が可能になります。
The first step in registering a new URL scheme in the IETF tree is to publish an IETF Internet-Draft detailing the syntax and semantics of the proposed scheme. The draft must, minimally, address all of the items covered by the template provided in section 6 of this document.
IETFツリーに新しいURLスキームを登録するための最初のステップは、提案方式のシンタックスとセマンティクスを詳述IETFインターネットドラフトを公開することです。草案は、最小限のは、このドキュメントのセクション6に設けられたテンプレートによってカバーされた項目のすべてに対処しなければなりません。
After all issues raised during a review period of no less than 4 weeks have been addressed, submit the draft to the IESG for review.
無未満4週間の審査期間中に発生したすべての問題が解決された後、レビューのためにIESGに草案を提出します。
The IESG will review the proposed new scheme and either refer the scheme to a working group (existing or new) or directly present the scheme to the IESG for a last call. In the former case, the working group is responsible for submitting a final version of the draft to the IESG for approval at such time as it has received adequate review and deliberation.
IESGは、提案された新しい手法を検討し、いずれかのワーキンググループ（既存または新規）にスキームを参照するか、直接最後の呼び出しのためにIESGにスキームを提示します。前者の場合には、ワーキンググループは、それが十分な検討と審議を受けているような時に、承認のためにIESGに草案の最終版を提出する責任があります。
Registration of URL schemes created in an alternative tree may be formal, through IETF documents, IANA registration, or other acknowledged organization; informal, through a mailing list or other publication mechanism; or nonexistent. The registration mechanism must be documented for each alternative tree, and must be consistent for all URL scheme names created in that tree.
代替の木で作成されたURLスキームの登録はIETF文書、IANA登録、または他の認知組織を通じて、正式であってもよく、メーリングリストや他の出版機構を介して、非公式。または存在しません。登録メカニズムは、各代替の木のために文書化されなければならない、そしてその木で作成されたすべてのURLのスキーム名のために一貫していなければなりません。
It is the responsibility of the creator of the tree's registration requirements to establish that the registration mechanism is workable as described; it is within the discretion of the IESG to reject the document describing a tree if it determines the registration mechanism is impractical or creates an undue burden on a party who will not accept it. (For instance, if an IANA registration mechanism is proposed, IESG might reject the tree if its mechanism would create undue liability on the part of IANA.)
説明するように登録メカニズムが実行可能であることを立証するために、ツリーの登録要件の作成者の責任です。それは登録メカニズムが非現実的であるか、それを受け入れることはありませんパーティーに過度の負担を作成し、判断した場合、ツリーを記述した文書を拒絶するIESGの裁量の範囲内です。 （IANA登録機構が提案されている場合、そのメカニズムはIANAの一部に過度の責任を作成した場合たとえば、IESGは木を拒否することがあります。）
While the template in section 6 of this document is intended to apply to URL scheme names in the IETF tree, it is also offered as a guideline for those documenting alternative trees.
このドキュメントのセクション6でテンプレートがIETFツリーのURLスキーム名に適用することを意図している間、それはまた別の木を文書化し、それらのためのガイドラインとして提供されています。
URL schemes created in the IETF tree are "owned" by the IETF itself and may be changed, as needed, by updating the RFC that describes them. Schemes described by Standards Track RFC but be replaced with new Standards Track RFCs. Informational RFCs may be replaced by new Informational RFCs or Standards Track RFCs.
IETF木で作成されたURLスキームは、IETF自身によって「所有」され、必要に応じてそれらを記述するRFCを更新することにより、変更することができます。スキームは、標準化過程RFCによって記述が、新たな標準化過程RFCに置き換えられます。情報のRFCは、新たな情報のRFCや標準化過程RFCで置き換えることができます。
URL schemes in an alternative tree that are undocumented (as allowed by that tree's rules) may be changed by their owner at any time without notifying the IETF.
（そのツリーのルールで許可されたとして）文書化されていない代替ツリー内のURLスキームはIETFに通知することなくいつでも彼らの所有者によって変更することができます。
URL schemes created in an alternative tree that have been documented by an Informational RFC, may be changed at any time by the owner, however, an updated Informational RFC which details the changes made, must be submitted to the IESG.
情報のRFCで文書化されている代替の木で作成されたURLスキームは、所有者によりいつでも変更することができる、しかし、行われた変更の詳細を更新情報RFCは、IESGに提出しなければなりません。
The owner of a URL scheme registered in an alternative tree and documented by an Informational RFC may pass responsibility for the registration to another person or agency by informing the IESG.
URLスキームの代替ツリーに登録し、情報のRFCによって文書の所有者はIESGに知らせることにより、他の人や機関への登録のための責任を渡すことができます。
The IESG may reassign responsibility for a URL scheme registered in an alternative tree and documented by an Informational RFC. The most common case of this will be to enable changes to be made to schemes where the scheme name is privately owned by the rules of its tree, and the owner of the scheme name has died, moved out of contact or is otherwise unable to make changes that are important to the community.
IESGは情報RFCによって代替ツリーに登録し、文書化URLスキームの責任を再割り当てすることができます。この最も一般的なケースは、スキーム名が私的にその木の規則によって所有され、スキーム名の所有者が死亡した、接触の外に移動したり、作ることがそうできない制度になされる変更を可能にするだろうコミュニティへの重要な変更。
The IESG may reclassify a URL scheme created in an alternative tree and documented via an Informational RFC as "historic" if it determines that the scheme is no longer in use.
それはスキームが使用されなくなったと判断していない場合IESGは、「歴史的」との情報RFCを経由して、代替の木で作成され、文書化されたURLスキームを再分類することがあります。
The following issues should be addressed when documenting a new URL scheme:
新しいURLスキームを文書化する場合は、次の問題に対処する必要があります。
URL scheme name.
URLスキーム名。
URL scheme syntax. This should be expressed in a clear and concise manner. The use of ABNF is encouraged. Please refer to RFC 2718 for guidance on designing and explaining your scheme's syntax.
URLスキームの構文。これは、明確かつ簡潔な形で表現されなければなりません。 ABNFの使用が奨励されています。設計し、スキーマの構文を説明するためのガイダンスについては、RFC 2718を参照してください。
Character encoding considerations. It is important to identify what your scheme supports in this regard. It is obvious that for interoperability, it is best if there is a means to support character sets beyond USASCII, but especially for private schemes, this may not be the case.
文字エンコーディングの考慮事項。あなたのスキームは、この点でサポートしている特定することが重要です。 USASCIIを超えて文字セットをサポートするための手段がある場合に、相互運用性のために、それがベストですが、特に民間スキームのために、このようなケースではないかもしれないことは明らかです。
Intended usage. What sort of resource is being identified? If this is not a 'resource' type of URL (e.g. mailto:), explain the action that should be initiated by the consumer of the URL. If there is a MIME type associated with this resource, please identify it.
使用目的。リソースはどのような特定されていますか？これはURLの「リソース」タイプ（例えばのmailto :)でない場合は、URLの消費者によって開始されなければならない行動を説明します。このリソースに関連付けられているMIMEタイプがある場合は、それを識別してください。
Applications and/or protocols which use this URL scheme name. Including references to documentation which defines the applications and/or protocols cited is especially useful.
アプリケーションおよび/または、このURLのスキーム名を使用するプロトコル。引用されたアプリケーション及び/又はプロトコルを定義するドキュメントへの参照を含むことは特に有用です。
Interoperability considerations. If you are aware of any details regarding your scheme which might impact interoperability, please identify them here. For example: proprietary or uncommon encoding method; inability to support multibyte character sets; incompatibility with types or versions of underlying protocol (if scheme is tunneled over another protocol).
相互運用性の考慮。あなたが相互運用性に影響を与えるかもしれないあなたのスキームに関するあらゆる細部を認識している場合は、ここではそれらを識別してください。例えば：プロプライエタリまたは珍しい符号化方法。マルチバイト文字セットをサポートすることができません。基礎となるプロトコルのタイプまたはバージョンの非互換性（スキームを別のプロトコルを介してトンネリングされている場合）。
Security considerations.
セキュリティの考慮事項。
Relevant publications.
関連の出版物。
Person & email address to contact for further information.
詳細のために連絡する人とEメールアドレスを入力します。
Author/Change controller.
著者/コントローラを変更します。
Applications and/or protocols which use this URL scheme name.
アプリケーションおよび/または、このURLのスキーム名を使用するプロトコル。
Information that creates or updates a registration needs to be authenticated.
登録を作成したり、更新情報が認証される必要があります。
Information concerning possible security vulnerabilities of a protocol may change over time. Consequently, claims as to the security properties of a registered URL scheme may change as well. As new vulnerabilities are discovered, information about such vulnerabilities may need to be attached to existing documentation, so that users are not misled as to the true security properties of a registered URL scheme.
プロトコルの可能なセキュリティの脆弱性に関する情報は、時間の経過とともに変化することがあります。これにより、登録されたURLスキームのセキュリティ特性として特許請求の範囲は、同様に変化してもよいです。新たな脆弱性が発見されているように、このような脆弱性に関する情報は、ユーザーが登録したURLスキームの真のセキュリティ・プロパティへと誤解されないように、既存の文書に添付する必要があるかもしれません。
If the IESG agrees to delegate the registration and change control functions of an alternative tree to a group or individual outside of the IETF, that group or individual should have sufficient security procedures in place to authenticate registration changes.
IESGは、グループまたはIETFの個々の外部に代替ツリーの登録、変更管理機能を委任することに同意する場合は、そのグループまたは個人が登録の変更を認証するための場所では十分なセキュリティ手続きが必要です。
[1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[1]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[2] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.
[2] Masinter、L.、Alvestrand、H.、Zigmond、D.とR. Petke、 "新しいURLスキームのためのガイドライン"、RFC 2718、1999年11月。
[3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[3]ポステル、J.、およびJ.レイノルズ、 "RFC作者への指示"、RFC 2223、1997年10月。
Rich Petke UUNET Technologies 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 USA
リッチPetke UUNET Technologies社5000ブリトン道路P. O.ボックス5000ヒリアード、オハイオ州43026から5000 USA
Phone: +1 614 723 4157 Fax: +1 614 723 8407 EMail: rpetke@wcom.net
電話：+1 614 723 4157ファックス：+1 614 723 8407 Eメール：rpetke@wcom.net
Ian King Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1 425-703-2293 Fax: +1 425-936-7329 EMail: iking@microsoft.com
イアン・キングマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399 USA電話：+1 425-703-2293ファックス：+1 425-936-7329電子メール：iking@microsoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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 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機能のための基金は現在、インターネット協会によって提供されます。