RFC3405 日本語訳

Network Working Group                                        M. Mealling
Request for Comments: 3405                                      VeriSign
BCP: 65                                                     October 2002
Category: Best Current Practice

コメントを求める要求を荒びきにして、作業部会M.をネットワークでつないでください: 3405ベリサインBCP: 10月65日の2002カテゴリ: 最も良い現在の習慣

     Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA
                         Assignment Procedures

ダイナミックな代表団発見システム(DDDS)パートFive: URI.ARPA課題手順

Status of this Memo

この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.

Copyright(C)インターネット協会(2002)。 All rights reserved。

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.

このドキュメントはそれが完全に指定されるシリーズでは、5番目に、「ダイナミックな代表団発見システム(DDDS)は1つを分ける」ということです。 「包括的なDDDS。」(RFC3401) 他のものを読まないでこのシリーズでどんなドキュメントも読んで、理解しているのが不可能であることに注意するのは非常に重要です。

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 URI解決対つぼの解決. . . . . . . . . . . . . . 2 3 IETFでの計画だけが木に追い上げる登録方針. . . . . . . . . . . . . . . . . . . 3 3.1URI.ARPA登録. . . . . . . . . . . . . . . . . . . 3 3.1.1は.33.1に先行. . . . . . . . . . . . 3 3.1.3NAPTR登録が伴うかもしれない.2枚の計画登録撮影に計画登録. . . . 3 3.1を許しました; 計画登録. . . . . 3 3.2URN.ARPA登録の後の4回の登録か変化、.43.2、.1NID登録、先行. . . . . . . . . . . . . 4 3.2.2NAPTR登録がNID登録. . . . . 4 3.2.3の登録か変化に伴うかもしれない撮影は登録. . . . . 4 4を計画します。 ヒント. . . . . . . . . . . . . . . . . . . 4 5に関する要件。 服従手順. . . . . . . . . . . . . . . . . . . . 5 6。 登録テンプレート. . . . . . . . . . . . . . . . . . . 6 6.1キー. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2権威. . . . . . . . . . . . . . . . . . . . . . . . . 6 6.3は.6 7を記録します。 例のテンプレート. . . . . . . . . . . . . . . . . . . . . . 6

Mealling                 Best Current Practice                  [Page 1]

RFC 3405          DDDS URI.ARPA Assignment Procedures       October 2002

DDDS URI.ARPA課題手順2002年10月に最も良い現在の習慣[1ページ]RFC3405を荒びきにします。

   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

8. URI.ARPAゾーン. . . . . . . . . 7 9のURN Registration。 IANA問題. . . . . . . . . . . . . . . . . . . . 7 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . 7 11。 承認. . . . . . . . . . . . . . . . . . . . . . 7 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 8 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 9 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 10

1. Introduction

1. 序論

   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.

このドキュメントは、'URI.ARPAへのNaming Authority Pointer(NAPTR)記録を''URN.ARPA'がUniform Resource Identifier(URI)を決議する目的のために帯状になる挿入して、「ダイナミックな代表団発見システム(DDDS)は4を分ける」ので、方針と手順を定義します。 「URI Resolution Application」(RFC3402)[2]。(その[2]はドメインネームシステムの(DNS)ベースのDDDS Databaseを使用するApplicationです)。 これらの概念のすべてがRFC3401[1]で定義されます。 正しくRFC3401とそれが指定するドキュメントを読まないでこのドキュメントを理解しているのが不可能であることに注意するのは非常に重要です。

   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.

RFC3403はURI代表団規則(時々解決ヒントと呼ばれる)を含むDDDSデータベースと使用されるどのようにDNSを定義するか。 そのドキュメントは、そのアルゴリズムによる第一歩が'URI.ARPA'をURI計画に追加して、そのドメイン名のためにNAPTR記録を検索することであると指定します。 すなわち、" http://foo.com/ "を決議することにおける第一歩はドメイン"http.URI.ARPA"のためのNAPTR記録を調べるだろうことです。 URN決議は、また、同様の手順に従いますが、根として'URN.ARPA'ゾーンを使用します。 このドキュメントは'URI.ARPA'と'URN.ARPA'ゾーンに新しい規則を挿入するための手順について説明します。

2. URI Resolution vs URN Resolution

2. URI解決対つぼの解決

   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.

RFC3402[2]はDNSが代表団規則(または、暗示する)データベースとして使用されるとき、URI[7]解決とURN[6]解決の両方がどう働いているかを定義します。 明確にそれは、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接頭語'つぼの解決のためのヒントです: 'また、'URI.ARPA'ゾーンでは、格納されるでしょう。 この規則は名前空間イド[6]を抜粋して、名前空間イドの終わりまで'URN.ARPA'を追加して、その後のNAPTR記録[4]の検索にキーとして結果を使用すると述べます。

Mealling                 Best Current Practice                  [Page 2]

RFC 3405          DDDS URI.ARPA Assignment Procedures       October 2002

DDDS URI.ARPA課題手順2002年10月に最も良い現在の習慣[2ページ]RFC3405を荒びきにします。

3. Registration Policies

3. 登録方針

   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名前空間イド(NID)の創造はそれらの空間のための適切な登録用書類に従います。 URI計画は「URL計画名のための登録手順」(RFC2717)[10]に続きます。 URN名前空間イドは「つぼの名前空間定義メカニズム」(RFC2611)(または、それに加えてアップデート)[9]に続きます。

3.1 URI.ARPA Registration

3.1 URI.ARPA登録

3.1.1 Only Schemes in the IETF Tree Allowed

3.1.1 許容されたIETF木での計画だけ

   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ゾーンに挿入されるために、IETF URI木の下にその後のURI計画を登録しなければなりません。 この木のための要件は[10]で指定されます。

3.1.2 Scheme Registration Takes Precedence

3.1.2 計画登録は優先します。

   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

[10]によると、URI計画のためのNAPTR記録の登録はその計画の適切な登録と安定した仕様の公表に先行してはいけません。 意志が要求を再検討するIESGかその指定された専門家

      1.  correctness and technical soundness

1. 正当性と技術的な健全さ

      2.  consistency with the published URI specification, and

そして2. 広められたURI仕様がある一貫性。

      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. NAPTRがDNSベースのURIのために記録するのを保証するのがDNS名の所有者以外のパーティーへURIの解決を代表として派遣しません。 この最後の規則は与えられたURIの解決ヒントが与えられたドメインにネットワークトラフィックをハイジャックしないのを(うっかりかそうでない)保障することです。

3.1.3 NAPTR Registration May Accompany Scheme Registration

3.1.3 NAPTR登録は計画登録に伴うかもしれません。

   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登録を求める要求はURI計画を求める要求に伴うかもしれません。([10])によると、その場合、両方の要求は同時に、IESGかその指定された専門家によって再検討されるでしょう。

3.1.4 Registration or Changes after Scheme Registration

3.1.4 計画登録の後の登録か変化

   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登録のどんな技術審査に加えています。

Mealling                 Best Current Practice                  [Page 3]

RFC 3405          DDDS URI.ARPA Assignment Procedures       October 2002

DDDS URI.ARPA課題手順2002年10月に最も良い現在の習慣[3ページ]RFC3405を荒びきにします。

3.2 URN.ARPA Registration

3.2 URN.ARPA登録

3.2.1 NID Registration Takes Precedence

3.2.1 NID登録は優先します。

   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.

[9]によると、URN NID MUST NOTのためのNAPTR記録の登録はそのNIDの適切な登録と安定した仕様の公表に先行します。 これは、URN.ARPAでのNAPTR記録の登録がNID登録手続を回避するのを防ぐためのものです。

3.2.2 NAPTR Registration May Accompany NID Registration

3.2.2 NAPTR登録はNID登録に伴うかもしれません。

   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登録を求める要求はNIDを求める要求に伴うかもしれません。([9])によると、その場合、両方の要求は同時に、再検討されるでしょう。

3.2.3 Registration or Changes after Scheme Registration

3.2.3 計画登録の後の登録か変化

   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

これが特定のNIDのためのすべてのNAPTR記録に適用されることに注意してください、NAPTR記録はNIDに割り当てられたURNスペースの一部だけに影響するかもしれませんが

4. Requirements on hints

4. ヒントに関する要件

   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ゾーンで質問負荷を最小にするために、それらのゾーンでのリソース記録には長年のうちに恐らく測定された「生きる回」非常に長い(TTLs)があると予期されます。

Mealling                 Best Current Practice                  [Page 4]

RFC 3405          DDDS URI.ARPA Assignment Procedures       October 2002

DDDS URI.ARPA課題手順2002年10月に最も良い現在の習慣[4ページ]RFC3405を荒びきにします。

   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.

foo IN NAPTR100 10、「「「「「「つぼ-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.

第2ステップはしたがって、第一歩がクライアントが解決の過程で始めるとき、上記の記録を見つけるためにfoo.URN.ARPAについて質問することであり、'つぼ-resolver.foo.com'に解決規則を含むNAPTR記録を求め始めることです。 根のTTLは非常に長いです。 'つぼ-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 IN NAPTR100 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.

したがって、解決の第2ステップはサイクルに次のキーとしてURIで見つけられたドメイン名を使用することです。 例えば、そのNAPTRが端末であり、交換分野に何らかのホスト名を保管しているなら、クライアントは、この特定のURIに関して質問するためにそのホストに連絡するかもしれません。

5. Submission Procedure

5. 服従手順

   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コンテントタイプ登録メカニズム[8]を使用して、'URI.ARPA'と'URN.ARPA'手順は利害関係者で作られた開いているメーリングリストに提出された要求テンプレートから成ります。 2週間の期間以内に反論を全くしないなら、登録局の代表は、服従が受け入れられると考えて、その服従をネームサーバに入れます。

       o  Registrations for the 'URI.ARPA' zone are sent to
           'register@URI.ARPA'.

o 'URI.ARPA'ゾーンのための登録証明書を' register@URI.ARPA 'に送ります。

Mealling                 Best Current Practice                  [Page 5]

RFC 3405          DDDS URI.ARPA Assignment Procedures       October 2002

DDDS URI.ARPA課題手順2002年10月に最も良い現在の習慣[5ページ]RFC3405を荒びきにします。

       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).

登録局はインターネットAssigned民数記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名前空間イドへの反論は許されていません、これらがそれらのそれぞれのフォーラムで上げられるべきであるのに従って。この論理的な結論は本書では生きる回と一般がDNSに影響を与えるあいさつとして指定された必要条件を満たすならどんな認可されたURI計画かURN名前空間にも登録させなければならないということです。

6. Registration Template

6. 登録テンプレート

   The template to be sent to the appropriate list MUST contain the
   following values:

適切なリストに送られるテンプレートは以下の値を含まなければなりません:

6.1 Key

6.1 キー

   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.

これは、URN NIDかURI計画です。(その計画はDNSエントリーのドメイン部分として使用されます)。 URN名前空間イド課題ドキュメントで指定された手順と新しいURI計画を登録するどんな将来の規格に従っても、それは有効であるに違いありません。

6.2 Authority

6.2 権威

   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] ドキュメントを定義したので認識された権威であるに違いありません。

6.3 Records

6.3 記録

   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記録はキーのためにセットしました。 必要な値は、RFC3404[4]によって定義されるようにPreferenceと、Orderと、Flagsと、Servicesと、Regexと、Replacementです。

7. Example Template

7. 例のテンプレート

   To: register@URN.ARPA
   From: joe@foo.com

To: register@URN.ARPA From: joe@foo.com

   Key: foo
   Authority: Foo Technology, Inc as specified in RFCFOO
   Record: foo     IN NAPTR 100 100 "" "" "" urn.foo.com.

キー: foo Authority: Foo Technology、RFCFOO Recordの指定されるとしてのInc: foo IN NAPTR100 100、「「「「「「urn.foo.com。」

Mealling                 Best Current Practice                  [Page 6]

RFC 3405          DDDS URI.ARPA Assignment Procedures       October 2002

DDDS URI.ARPA課題手順2002年10月に最も良い現在の習慣[6ページ]RFC3405を荒びきにします。

8. The URN Registration in the URI.ARPA zone

8. URI.ARPAゾーンのURN Registration

   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

To: register@URI.ARPA From: IETFつぼの作業部会

         Key: urn
         Authority: RFC2141
         Record: urn     IN NAPTR 0 0 "" "" "/^urn:([^:]+)/\\2/i" .

キー: つぼのAuthority: RFC2141は記録します: つぼIN NAPTR0 0、「「「「「/^つぼ:、[^:、]、+) /\\2/i」、」

9. IANA Considerations

9. IANA問題

   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 、およびレジスタ@urn.arpaを作成しました。 IANAはこれらのメーリングリストを管理するでしょう。

10. Security Considerations

10. セキュリティ問題

   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'ゾーンは、代表団経路を向け直すためにサービス妨害とスプーフィングエントリーのための攻撃の一般的なポイントになるでしょう。 これらのゾーンを含むどんな実体走行ネームサーバも、インターネットのインフラストラクチャレベルコンポーネントを固定するために適切な行動を取るべきです。 ネームサーバがゾーンで記録に確かにサインするのが可能になると、それはそうするべきです。

11. Acknowledgements

11. 承認

   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.

作者は元々これらのドキュメントの共同作者であったロンダニエルに感謝したがっています。 代表団規則の複雑な本質へのロンのオリジナルの「不-サイト」はこれらの手順とDDDS自身を可能にしました。

Mealling                 Best Current Practice                  [Page 7]

RFC 3405          DDDS URI.ARPA Assignment Procedures       October 2002

DDDS URI.ARPA課題手順2002年10月に最も良い現在の習慣[7ページ]RFC3405を荒びきにします。

12. References

12. 参照

   [1]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         One: The Comprehensive DDDS", RFC 3401, October 2002.

[1] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は1つを分けます」。 「包括的なDDDS」、2002年10月のRFC3401。

   [2]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Two: The Algorithm", RFC 3402, October 2002.

[2] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は2を分けます」。 「アルゴリズム」、RFC3402、2002年10月。

   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Three: The Domain Name System (DNS) Database", RFC 3403,
         October 2002.

[3] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、2002年10月。

   [4]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Four: The Uniform Resource Identifiers (URI) Resolution
         Application", RFC 3404, October 2002.

[4] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は4を分けます」。 「Uniform Resource Identifier(URI)解決アプリケーション」、RFC3404、2002年10月。

   [5]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.

[5] 食事、M.、「ダイナミックな代表団発見システム(DDDS)は5を分けます」。 「URI.ARPA課題手順」、RFC3405、2002年10月。

   [6]   Moats, R., "URN Syntax", RFC 2141, November 1998.

[6] モウツ、R.、「つぼの構文」、RFC2141、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、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、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を分けます」。 「登録手順」、BCP13、RFC2048、1996年11月。

   [9]   Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, "URN
         Namespace Definition Mechanisms", BCP 33, RFC 2611, October
         1998.

[9] Gulik、「つぼの名前空間定義メカニズム」をFaltstrom、P.、Iannella、R.、Daigle、L.、およびD.はバンに積みます、BCP33、RFC2611、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計画名のための登録手順」BCP35、1999年1月のRFC2717。

Mealling                 Best Current Practice                  [Page 8]

RFC 3405          DDDS URI.ARPA Assignment Procedures       October 2002

DDDS URI.ARPA課題手順2002年10月に最も良い現在の習慣[8ページ]RFC3405を荒びきにします。

13. Author's Address

13. 作者のアドレス

   Michael Mealling
   VeriSign
   21345 Ridgetop Circle
   Sterling, VA  20166
   US

ベリサイン21345屋根の頂円の英貨、ヴァージニア20166米国を荒びきにするマイケル

   EMail: michael@neonym.net
   URI:  http://www.verisignlabs.com

メール: michael@neonym.net ユリ: http://www.verisignlabs.com

Mealling                 Best Current Practice                  [Page 9]

RFC 3405          DDDS URI.ARPA Assignment Procedures       October 2002

DDDS URI.ARPA課題手順2002年10月に最も良い現在の習慣[9ページ]RFC3405を荒びきにします。

14. Full Copyright Statement

14. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。

Mealling                 Best Current Practice                 [Page 10]

最も良い現在の習慣を荒びきにします。[10ページ]