[要約] RFC 2717は、URLスキーム名の登録手続きに関する規定です。その目的は、URLスキーム名の一貫性と一意性を確保し、インターネット上でのリソースの識別を効果的に管理することです。
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
URLスキーム名の登録手順
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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は、「<scheme>：」を含むことによって指定され、次に「<スキーム固有のパート>」が含まれます。多くの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スキームの<schleme>部分にあります。
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に記載されているとおりに解釈されます。
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.
登録ツリーに関係なく、すべての新しいURLスキームは、RFC 2396で指定されている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 2718に記載されている他の基準を既に使用しているURLスキームの場合にのみ、登録に情報提供RFCが採用される場合があります。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).
IETFツリーに登録されているスキームの名前には、ダッシュ（ハイフンとマイナスサインとも呼ばれる）文字（ ' - '）USASCII値2DHを含めてはなりません。このキャラクターを使用すると、代替ツリーに登録されているスキームと混乱を引き起こす可能性があります（セクション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インターネットドラフトメカニズムを使用するためにピアレビューのために使用することは、仕様の品質を改善するために強く推奨されます。RFC代替ツリーURLスキームの公開が奨励されますが、必要ありません。資料は、RFCエディターに送信することにより、情報RFCとして公開される場合があります（RFC Authors、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 [2]に記載されているURLスキームのガイドラインに従う必要があります。
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」ツリーは、フォームのスキーム名を作成することを可能にします： "foo-blahblah：" and "foo-bar："。ツリーは、ツリーのユニークなプレフィックスに続いて任意のusascii文字列を処方します。
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登録メカニズムが提案されている場合、IESGは、そのメカニズムがIANAの一部に過度の責任をもたらす場合、ツリーを拒否する可能性があります。）
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は、新しい情報RFCSまたは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.
代替ツリーに登録され、情報情報RFCによって文書化されたURLスキームの所有者は、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は、代替ツリーで作成されたURLスキームを再分類し、情報RFCを介してスキームが使用されなくなった場合に「歴史的」として文書化される場合があります。
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.
詳細については、連絡先への個人およびメールアドレス。
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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
Rich Petke UUNET Technologies 5000 Britton Road P. O. Box 5000 Hilliard, OH 43026-5000 USA
Rich Petke Uunet Technologies 5000 Britton Road P. O. Box 5000 Hilliard、OH 43026-5000 USA
Phone: +1 614 723 4157
Fax: +1 614 723 8407
EMail: 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
Ian King Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399 USA電話：1 425-703-2293 FAX：1 425-936-7329メール：iking@microsoft.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。