Network Working Group M. Mealling
Request for Comments: 3405 VeriSign
BCP: 65 October 2002
Category: Best Current Practice
Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA
Assignment Procedures
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others.
（RFC 3401）：この文書は、完全に「包括DDDSダイナミックな委譲発見システム（DDDS）第一部」に指定されている直列に第五です。他の人を読まず、このシリーズでは、任意のドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. URI Resolution vs URN Resolution . . . . . . . . . . . . . . 2
3. Registration Policies . . . . . . . . . . . . . . . . . . . 3
3.1 URI.ARPA Registration . . . . . . . . . . . . . . . . . . . 3
3.1.1 Only Schemes in the IETF Tree Allowed . . . . . . . . . . . 3
3.1.2 Scheme Registration Takes Precedence . . . . . . . . . . . . 3
3.1.3 NAPTR Registration May Accompany Scheme Registration . . . . 3
3.1.4 Registration or Changes after Scheme Registration . . . . . 3
3.2 URN.ARPA Registration . . . . . . . . . . . . . . . . . . . 4
3.2.1 NID Registration Takes Precedence . . . . . . . . . . . . . 4
3.2.2 NAPTR Registration May Accompany NID Registration . . . . . 4
3.2.3 Registration or Changes after Scheme Registration . . . . . 4
4. Requirements on hints . . . . . . . . . . . . . . . . . . . 4
5. Submission Procedure . . . . . . . . . . . . . . . . . . . . 5
6. Registration Template . . . . . . . . . . . . . . . . . . . 6
6.1 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2 Authority . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.3 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Example Template . . . . . . . . . . . . . . . . . . . . . . 6
8. The URN Registration in the URI.ARPA zone . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
This document defines the policies and procedures for inserting Naming Authority Pointer (NAPTR) records into the 'URI.ARPA' and 'URN.ARPA' zones for the purpose of resolving Uniform Resource Identifiers (URIs) according to "Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application" (RFC 3402) [2], which is an Application that uses the Domain Name System (DNS) based DDDS Database. All of these concepts are defined in RFC 3401 [1]. It is very important to note that it is impossible to correctly understand this document without reading RFC 3401 and the documents it specifies.
この文書では、DDDS（ダイナミックな委譲発見システム」による「URI.ARPA」と統一資源識別子を解決するために、「URN.ARPA」ゾーン（のURI）に名前付け権限ポインタ（NAPTR）レコードを挿入するためのポリシーと手順を定義します）パート4：URI解決応用」（RFC 3402）[2]は、ドメインネームシステム（DNS）ベースDDDSデータベースを使用するアプリケーションです。これらの概念の全ては、RFC 3401で定義されている[1]。正しくRFC 3401およびそれが指定する書類を読まずに、この文書を理解することは不可能であることに注意することが非常に重要です。
RFC 3403 defines a how DNS is used as a DDDS database that contains URI delegation rules (sometimes called resolution hints). That document specifies that the first step in that algorithm is to append 'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that domain-name. I.e., the first step in resolving "http://foo.com/" would be to look up a NAPTR record for the domain "http.URI.ARPA". URN resolution also follows a similar procedure but uses the 'URN.ARPA' zone as its root. This document describes the procedures for inserting a new rule into the 'URI.ARPA' and 'URN.ARPA' zones.
RFC 3403には、DNSが（時には解像度のヒントと呼ばれる）URI委任規則が含まれているDDDSデータベースとして使用される方法を定義します。その文書には、そのアルゴリズムの最初のステップは、URIスキームに「URI.ARPA」を追加し、そのドメイン名のためのNAPTRレコードを取得するためにあることを指定します。すなわち、解決するための最初のステップは、「http://foo.com/」ドメイン「http.URI.ARPA」のためのNAPTRレコードを検索することです。 URNの解像度も、同様の手順に従いますが、そのルートとして「URN.ARPA」ゾーンを使用しています。この文書では、「URI.ARPA」と「URN.ARPA」ゾーンに新しいルールを挿入するための手順を説明します。
RFC 3402 [2] defines how both URI [7] resolution and URN [6] resolution work when DNS is used as the delegation rule (or hint) database. Specifically it says that the initial instructions ('hints') for DNS-based resolution of URIs are stored as resource records in the 'URI.ARPA' DNS zone.
RFC 3402 [2]方法URI [7]の解像度とURN [6]解像度作業DNSを委譲ルール（またはヒント）データベースとして使用される両方の定義します。具体的には、URIのDNSベースの解決のための最初の命令（「ヒントは」）「URI.ARPA」DNSゾーンのリソースレコードとして格納されていることを述べています。
Since a URN is a URI scheme, a hint for resolution of the URI prefix 'urn:' will also be stored in the 'URI.ARPA' zone. This rule states that the namespace id [6] is extracted, 'URN.ARPA' is appended to the end of the namespace id, and the result is used as the key for retrieval of a subsequent NAPTR record [4].
URNは、URIスキーム、URI接頭辞の解決のためのヒントであるため、「URN：」は「URI.ARPA」ゾーンに保存されます。このルールは、[6]ネームスペースIDが名前空間IDの末尾に追加され、「URN.ARPA」を抽出することを述べて、その結果を後続のNAPTRレコードを検索するためのキーとして使用されている[4]。
The creation of a given URI scheme or URN namespace id (NID) follows the appropriate registration documents for those spaces. URI schemes follow "Registration Procedures for URL Scheme Names" (RFC 2717) [10]. URN namespace ids follow "URN Namespace Definition Mechanisms" (RFC 2611) (or updates thereto) [9].
与えられたURIスキームまたはURN名前空間ID（NID）の作成は、これらのスペースのための適切な登録書類を次の。 URIスキームは、（RFC 2717）[10] "URLスキーム名の登録手順" に従います。 URN名前空間IDは "URN名前空間定義メカニズム"（RFC 2611）（またはそれに更新）に従う[9]。
In order to be inserted into the URI.ARPA zone, the subsequent URI scheme MUST be registered under the IETF URI tree. The requirements for this tree are specified in [10].
URI.ARPAゾーンに挿入するために、後続のURIスキームはIETF URIツリーの下に登録されなければなりません。このツリーのための要件は、[10]で指定されています。
The registration of a NAPTR record for a URI scheme MUST NOT precede proper registration of that scheme and publication of a stable specification in accordance with [10]. The IESG or its designated expert will review the request for
URIスキームのNAPTRレコードの登録は、[10]に応じて安定した仕様のスキーム及び出版物の適切な登録に先行してはいけません。 IESGまたはその指定された専門家は、要求を見直します
3. to ensure that the NAPTR record for a DNS-based URI does not delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain.
3. DNSベースのURIのためのNAPTRレコードがDNS名の所有者以外の者へのURIの解決を委任していないことを確認します。この最後のルールは、指定されたURIの解決のヒントが与えられたドメインのために（不注意またはその他）のネットワークトラフィックをハイジャックしないことを保証することです。
A request for a URI.ARPA registration MAY accompany a request for a URI scheme (in accordance with [10]), in which case both requests will be reviewed simultaneously by IESG or its designated experts.
URI.ARPA登録要求は、両方の要求がIESG又はその指定の専門家によって同時に検討される場合には（[10]に従って）URIスキームのための要求を伴い得ます。
A request for a NAPTR record (or an request to change an existing NAPTR record) MAY be submitted after the URI prefix has been registered. If the specification for the URI prefix is controlled by some other party than IETF, IESG will require approval from the owner/maintainer of that specification before the registration will be accepted. This is in addition to any technical review of the NAPTR registration done by IESG or its designated experts.
URIプレフィックスが登録された後にNAPTRレコード（または既存のNAPTRレコードを変更する要求）の要求を提出することができます。 URIプレフィックスの仕様はIETFよりもいくつかの他の当事者によって制御されている場合は登録が受理される前に、IESGは、その仕様の所有者/メンテナからの承認が必要になります。これはIESGまたはその指定の専門家によって行わNAPTR登録のいずれかの技術的な見直しに加えています。
The registration of a NAPTR record for a URN NID MUST NOT precede proper registration of that NID and publication of a stable specification in accordance with [9]. This is to prevent the registration of a NAPTR record in URN.ARPA from circumventing the NID registration process.
URN NIDためのNAPTRレコードの登録は、[9]に応じて安定した仕様のNIDおよび出版物の適切な登録に先行してはいけません。これは、NIDの登録プロセスを回避からURN.ARPAでNAPTRレコードの登録を防ぐためです。
A request for a URN.ARPA registration MAY accompany a request for a NID (in accordance with [9]), in which case both requests will be reviewed at the same time.
URN.ARPA登録要求は、その場合、両方の要求が同時に検討される（[9]に従って）NID要求を伴い得ます。
A request for a NAPTR record (or an request to change an existing NAPTR record) MAY be submitted after the NID has been registered. If the specification for the NID is controlled by some other party than IETF, IESG will require approval from the owner/maintainer of that specification before the registration will be accepted. This is in addition to any technical review of the NAPTR registration done by IESG or its designated experts.
NIDが登録された後にNAPTRレコード（または既存のNAPTRレコードを変更する要求）の要求を提出することができます。 NIDのための仕様はIETFよりもいくつかの他の当事者によって制御されている場合は登録が受理される前に、IESGは、その仕様の所有者/メンテナからの承認が必要になります。これはIESGまたはその指定の専門家によって行わNAPTR登録のいずれかの技術的な見直しに加えています。
Note that this applies to all NAPTR records for a particular NID, even though a NAPTR record might affect only part of the URN space assigned to an NID
NAPTRレコードは、NIDに割り当てられたURN空間の一部のみに影響を与える可能性があるにもかかわらず、これは特定のNIDのためのすべてのNAPTRレコードに適用されることに注意してください
Delegation of a namespace can happen in two ways. In the case of most URIs, the key being delegated to is hard-coded into the identifier itself (e.g., a hostname in an HTTP URI). The syntax of where this new key is located is predetermined by the syntax of the scheme. In other cases, the new key can be part of the hint itself. This is the functional equivalent of saying, "if this rule matches then this is always the key."
名前空間の委任は、2つの方法で発生する可能性があります。最もURIの場合、鍵は、識別子自体にハードコーディングされているために委任された（例えば、HTTP URI内のホスト名）。この新しいキーが配置されている場所の構文は、スキームの構文によって予め決定されます。他の例では、新しいキーがヒント自体の一部にすることができます。これは、言うの機能的に等価である「このルールが一致した場合、これは常に鍵です。」
In order to minimize the query load on the URI.ARPA and URN.ARPA zones, it is anticipated that the resource records in those zones will have extremely long "times to live" (TTLs), perhaps measured in years.
URI.ARPAとURN.ARPAゾーンへのクエリの負荷を最小限にするためには、それらのゾーン内のリソースレコードは、おそらく年間で測定し、（TTLの）「生きるため回」非常に長いを持っていることが予想されます。
Thus, for any URI prefix or URN namespace for which the resolution hints are likely to change, the actual rule should be stored in some other (less stable) DNS zone, and within URI.ARPA or URN.ARPA a stable NAPTR record should be used to delegate queries to that less stable zone.
したがって、任意のURIプレフィックス又は解像度ヒントが変化する可能性があるれるURN名前空間のために、実際のルールは、他の（より不安定）DNSゾーンに格納する必要があり、そしてURI.ARPA又はURN.ARPA内で安定したNAPTRレコードがなければなりませんその安定性の低いゾーンにクエリーを委任するために使用されます。
For example, the 'foo' URN namespace has flexible rules for how delegation takes place. Instead of putting those rules in the URN.ARPA zone, the entry instead punts those rules off to a nameserver that has a shorter time to live. The record in URN.ARPA would look like this:
たとえば、「foo」でURN名前空間には、代表団がどのように行われるかについて柔軟なルールがあります。代わりにURN.ARPAゾーンにこれらのルールを置くのは、エントリではなく、生きるための短い時間を持っているネームサーバにオフこれらのルールをパント。 URN.ARPAのレコードは次のようになります。
foo IN NAPTR 100 10 "" "" "" urn-resolver.foo.com.
NAPTR 100 10にFOO "" "" "" urn-resolver.foo.com。
Thus, when the client starts out in the resolution process, the first step will be to query foo.URN.ARPA to find the above record, the second step is to begin asking 'urn-resolver.foo.com' for the NAPTR records that contain the resolution rules. The TTL at the root is very long. The TTL at the 'urn-resolver.foo.com' is much shorter.
したがって、クライアントは解決プロセスで実行開始すると、最初のステップは、上記のレコードを検索するfoo.URN.ARPAを照会することで、第二段階は、NAPTRレコードの「urn-resolver.foo.com」を求めて開始しますそれは、解像度のルールが含まれています。根元のTTLは、非常に長いです。 「urn-resolver.foo.com」でのTTLは、はるかに短いです。
Conversely, the 'http' URI scheme adheres to a particular syntax that specifies that the host to ask is specified in the URI in question. Since this syntax does not change, that rule can be specified in the URI.ARPA zone. The record would look like this:
逆に、「HTTP」URIスキームは、ホストが問題のURIで指定されて依頼することを指定し、特定の構文に準拠しています。この構文は変更されませんので、そのルールはURI.ARPAゾーンに指定することができます。レコードには、次のようになります。
http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" .
HTTP NAPTR 100 100 "" "" "/のhttp：\\ / \\ /（[^ \\ /：] +）/ \\ 2 / I"。
Thus, the second step of resolution is to use the domain-name found in the URI as the next key in the cycle. If, for example, that NAPTR was terminal and contains some hostname in the replacement field, then the client could contact that host in order to ask questions about this particular URI.
このように、解像度の第二段階は、サイクル内の次のキーとしてURIに見出されるドメイン名を使用することです。例えば、そのNAPTRは、端末だったと置換フィールドでのいくつかのホスト名が含まれている場合、クライアントは、この特定のURIについての質問をするために、そのホストに連絡ができます。
Using the MIME Content-Type registration mechanism [8] as a model for a successful registration mechanism, the 'URI.ARPA' and 'URN.ARPA' procedures consist of a request template submitted to an open mailing list made up of interested parties. If no objections are made within a two week period, a representative of the registration authority considers the submission to be accepted and enters that submission into the nameserver.
MIME Content-Typeの登録メカニズムを使用した[8]成功した登録メカニズムのモデルとして、「URI.ARPA」と「URN.ARPA」手続きが利害関係者で構成されたオープンなメーリングリストに提出要求テンプレートで構成されています。異議は、2週間の期間内になされない場合は、登録認定機関の代表者は、提出が受理されると見なし、ネームサーバにその提出を入力します。
o Registrations for the 'URI.ARPA' zone are sent to
'register@URI.ARPA'.
o Registrations for the 'URN.ARPA' zone are sent to 'register@URN.ARPA'.
O「URN.ARPA」ゾーンの登録は、「register@URN.ARPA」に送信されます。
The registration authority is the Internet Assigned Numbers Authority (IANA).
登録機関は、Internet Assigned Numbers Authority（IANA）です。
Objections are restricted to those that point out impacts on the zone itself or to DNS in general. Objections to the URI scheme or to the URN namespace-id are not allowed, as these should be raised in their respective forums. The logical conclusion of this is that ANY sanctioned URI scheme or URN namespace MUST be allowed to be registered if it meets the requirements specified in this document as regards times to live and general impact to the DNS.
異議は、一般的には、ゾーン自体にまたはDNSへの影響を指摘するものに限定されています。これらは、それぞれのフォーラムで提起されなければならないとして、URIスキームまたはURN名前空間-IDへの異議は、許可されていません。この論理的な結論は、いかなる認可URIスキームまたはURN名前空間がDNSに住んでいて、一般的なインパクト回に関してはこの文書で指定された要件を満たしている場合は、登録することを許可しなければならないということです。
The template to be sent to the appropriate list MUST contain the following values:
適切なリストに送信するテンプレートには、次の値を含まなければなりません：
This is the URN NID or URI scheme, which is used as the domain portion of the DNS entry. It must be valid according to the procedures specified in the URN namespace-id assignment document and any future standards for registering new URI schemes.
これは、DNSエントリのドメイン部分として使用されるURN NID又はURIスキームです。これは、URN名前空間-ID割当文書と新しいURIスキームを登録するための任意の将来の規格で指定された手順に従って、有効でなければなりません。
This is the individual or organization (entity) which has authority for registering the record. It must be an authority recognized as either the IESG or any authority defined in the URN NID [9] or URI scheme registration [10] documents.
これは、レコードを登録する権限を有する個人または組織（エンティティ）です。それはIESGまたはURN NID [9]またはURIスキームの登録[10]の文書で定義された任意の権威として認識権威である必要があります。
The actual DNS records representing the rule set for the key. The required values are Preference, Order, Flags, Services, Regex, and Replacement as defined by RFC 3404 [4].
キーに設定されたルールを表す実際のDNSレコード。必要な値は、RFC 3404によって定義されるように好ましい、注文、フラグ、サービス、正規表現、および置換されている[4]。
To: register@URN.ARPA From: joe@foo.com
To：register@URN.ARPAから：joe@foo.com
Key: foo Authority: Foo Technology, Inc as specified in RFCFOO Record: foo IN NAPTR 100 100 "" "" "" urn.foo.com.
キー：FOO機関：フー・テクノロジー株式会社RFCFOOのレコードに指定されている：NAPTR 100 100内のfoo "" "" "" urn.foo.com。
Since this document discusses the URI.ARPA and URN.ARPA zones and the URN rule that exists in the URI.ARPA zone, it makes sense for the registration template for the URN URI rule to be specified here:
この文書はURI.ARPAとURN.ARPAゾーンとURI.ARPAゾーンに存在するURNルールを説明しているので、ここで指定するURN URIルールの登録テンプレートの意味があります：
To: register@URI.ARPA
From: The IETF URN Working Group
Key: urn Authority: RFC2141 Record: urn IN NAPTR 0 0 "" "" "/^urn:([^:]+)/\\2/i" .
キー：URN機関：RFC2141レコード：NAPTR IN 0壷0 "" "" "/ ^ URN：（[^：] +）/ \\ 2 / I"。
The IANA has created the zones URN.ARPA and URI.ARPA. The hierarchical name structure, and the only names to be assigned within these zones, are the "keys" as described in Section 6.1 of this document. The administrative and operational management of these zones are to be undertaken by the IANA. The DNS records to be inserted in these zones are subject to the review process described in this document.
IANAは、ゾーンURN.ARPAとURI.ARPAを作成しました。階層名構造、およびこれらのゾーン内割り当てられる名前のみ、このドキュメントのセクション6.1で説明したように「キー」です。これらのゾーンの管理と運用管理はIANAによって行われるべきです。これらのゾーンに挿入されるDNSレコードは、このドキュメントで説明するレビュープロセスの対象となっています。
The IANA has also created two discussion lists, register@uri.arpa and register@urn.arpa, for the purposes described in this document. The IANA will manage these mailing lists.
IANAはまた、この文書に記載された目的のための2つのディスカッションリスト、register@uri.arpaとregister@urn.arpaを作成しました。 IANAは、これらのメーリングリストを管理します。
The 'uri.arpa' and 'urn.arpa' zones will be a common point of attack both for Denial of Service and for spoofing entries in order to redirect delegation paths. Any entity running nameservers that contain these zones should take appropriate action for securing an infrastructure level component of the Internet. When it becomes possible for a nameserver to reliably sign the records in its zone it should do so.
「uri.arpa」と「urn.arpa」ゾーンは、サービス拒否のためと委任パスをリダイレクトするために、なりすましのエントリの両方の攻撃の共通点となります。これらのゾーンが含まれている任意の実体実行しているネームサーバは、インターネットのインフラレベルのコンポーネントを保護するための適切な行動を取る必要があります。ネームサーバは、確実にそのゾーン内のレコードに署名することができるようになるとき、それはそうする必要があります。
The author would like to thank Ron Daniel who was originally co-author of these documents. Ron's original insite into the intricate nature of delegation rules made these procedures and the DDDS itself possible.
著者は、もともとこれらの文書の共著者だったロン・ダニエルに感謝したいと思います。委任規則の複雑な自然の中へロンのオリジナルINSITEは、これらの手順と可能なDDDS自体を作りました。
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[1] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[2] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート2：アルゴリズム"、RFC 3402、2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[3] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース"、RFC 3403、2002年10月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[4] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）第四部：統一資源識別子（URI）解像度アプリケーション"、RFC 3404、2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[5] Mealling、M.、 "ダイナミックな委譲発見システム（DDDS）パートファイブ：URI.ARPAの割り当て手順"、RFC 3405、2002年10月。
[6] Moats, R., "URN Syntax", RFC 2141, November 1998.
[6]堀、R.、 "URN構文"、RFC 2141、1998年11月。
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[8] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[8]解放され、N.、Klensin、J.およびJ.ポステル、 "多目的インターネットメール拡張（MIME）パート4：登録手順"、BCP 13、RFC 2048、1996年11月。
[9] Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, October 1998.
[9] Faltstrom、P.、Iannella、R.、Daigle氏、L.とD.バンGulik、 "URN名前空間定義メカニズム"、BCP 33、RFC 2611、1998年10月。
[10] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, January 1999.
[10] Petke、R.とI.キング、 "URLスキーム名の登録手順"、BCP 35、RFC 2717、1999年1月。
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
マイケル・メオーリングベリサイン21345 Ridgetopサークルスターリング、バージニア州20166米国
EMail: michael@neonym.net URI: http://www.verisignlabs.com
電子メール：michael@neonym.net URI：http://www.verisignlabs.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。