RFC2611 日本語訳

Network Working Group                                          L. Daigle
Request for Comments: 2611                      Thinking Cat Enterprises
BCP: 33                                                     D. van Gulik
Category: Best Current Practice                      ISIS/CEO, JRC Ispra
                                                             R. Iannella
                                                            DSTC Pty Ltd
                                                            P. Faltstrom
                                                           Tele2/Swipnet
                                                               June 1999

Daigleがコメントのために要求するワーキンググループL.をネットワークでつないでください: 2611の考え深い猫エンタープライズBCP: 33 D. Gulik Categoryをバンに積んでください: 最も良い現在のPracticeイシス/最高経営責任者、JRCイスプラR.Iannella DSTC Pty Ltd P.Faltstrom Tele2/Swipnet1999年6月

                  URN Namespace Definition Mechanisms

つぼの名前空間定義メカニズム

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 (1999).  All Rights Reserved.

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

Abstract

要約

   The URN WG has defined a syntax for Uniform Resource Names (URNs)
   [RFC2141], as well as some proposed mechanisms for their resolution
   and use in Internet applications ([RFC2168, RFC2169]). The whole
   rests on the concept of individual "namespaces" within the URN
   structure.  Apart from  proof-of-concept namespaces, the use of
   existing identifiers in URNs has been discussed ([RFC2288]), and this
   document lays out general definitions of and mechanisms for
   establishing URN "namespaces".

URN WGはUniform Resource Names(URNs)[RFC2141]のために構文を定義しました、彼らの解決のためのいくつかの提案されたメカニズムとインターネットアプリケーションにおける使用と同様に([RFC2168、RFC2169])。 全体がURN構造の中で個々の「名前空間」の概念にかかっています。 概念の証拠名前空間は別として、URNsにおける既存の識別子の使用について議論しました、そして、([RFC2288])このドキュメントはURN「名前空間」を設立するための一般的な定義とメカニズムを広げます。

1.0 Introduction

1.0 序論

   Uniform Resource Names (URNs) are resource identifiers with the
   specific requirements for enabling location independent
   identification of a resource, as well as longevity of reference.
   There are 2 assumptions that are key to this document:

一定のResource Names(URNs)はリソースの可能な位置の独立している識別のための決められた一定の要求があるリソース識別子です、参照の寿命と同様に。 このドキュメントに主要な2仮定があります:

   Assumption #1:

仮定#1:

      Assignment of a URN is a managed process.

URNの課題は管理された過程です。

      I.e., not all strings that conform to URN syntax are necessarily
      valid URNs.  A URN is assigned according to the rules of a
      particular namespace (in terms of syntax, semantics, and process).

すなわち、URN構文に一致しているというわけではないすべてのストリングが必ず有効なURNsです。 特定の名前空間(構文、意味論、および過程による)の規則に従って、URNは割り当てられます。

Daigle, et al.           Best Current Practice                  [Page 1]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[1ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

   Assumption #2:

仮定#2:

      The space of URN namespaces is managed.

URN名前空間のスペースは管理されます。

      I.e., not all syntactically correct URN namespaces (per the URN
      syntax definition)  are valid URN namespaces.  A URN namespace
      must have a recognized definition in order to be valid.

すなわち、すべてのシンタクス上正しいURN名前空間(URN構文定義あたりの)が有効なURN名前空間であるというわけではありません。 URN名前空間には、有効になるように、認識された定義がなければなりません。

   The purpose of this document is to outline a mechanism and provide a
   template for explicit namespace definition, along with the mechanism
   for associating an identifier (called a "Namespace ID", or NID) which
   is registered with the Internet Assigned Numbers Authority, IANA.

このドキュメントの目的は、明白な名前空間定義にメカニズムについて概説して、テンプレートを提供することです、インターネットAssigned民数記Authorityに登録される識別子(「Namespace ID」、またはNIDと呼ばれる)を関連づけるためのメカニズムと共に、IANA。

   Note that this document restricts itself to the description of
   processes for the creation of URN namespaces.  If "resolution" of any
   so-created URN identifiers is desired, a separate process of
   registration in a global NID directory, such as that provided by the
   NAPTR system [RFC2168], is necessary.  See [NAPTR-REG] for
   information on obtaining registration in the NAPTR global NID
   directory.

このドキュメントがそれ自体をURN名前空間の創造のための過程の記述に制限することに注意してください。 どんなしたがって、作成されたURN識別子の「解決」も望まれているなら、NAPTRシステム[RFC2168]によって提供されたそれなどのグローバルなNIDディレクトリの登録の別々の過程が必要です。 NAPTRのグローバルなNIDディレクトリにおける登録を得ることの情報に関して[NAPTR-REG]を見てください。

2.0 What is a URN Namespace?

2.0 URN Namespaceは何ですか?

   For the purposes of URNs, a "namespace" is a collection of uniquely-
   assigned identifiers.  A URN namespace itself has an identifier in
   order to

URNsの目的のために、「名前空間」は唯一割り当てられた識別子の収集です。 URN名前空間自体には、識別子があります。

      - ensure global uniqueness of URNs
      - (where desired) provide a cue for the structure of the
        identifier

- URNsのグローバルなユニークさ--識別子の構造に手がかりを供給するのを(必要であるところ)確実にしてください。

   For example, ISBNs and ISSNs are both collections of identifiers used
   in the traditional publishing world; while there may be some number
   (or numbers) that is both a valid ISBN identifier and ISSN
   identifier, using different designators for the two collections
   ensures that no two URNs will be the same for different resources.

例えば、ISBNsとISSNsは伝統的な出版界で使用される識別子の両方の収集です。 有効なISBN識別子とISSN識別子の両方、2つの収集に異なった指示子を使用するのがいいえ、2URNsがそうになるのを確実にするということである何らかの数(または、数)が異なったリソースのために同じようにあるかもしれませんが。

   The development of an identifier structure, and thereby a collection
   of identifiers, is a process that is inherently dependent on the
   requirements of the community defining the identifier, how they will
   be assigned, and the uses to which they will be put.  All of these
   issues are specific to the individual community seeking to define a
   namespace (e.g., publishing community, association of booksellers,
   protocol developers, etc); they are beyond the scope of the IETF URN
   work.

識別子構造の開発、およびその結果、識別子の収集は本来識別子を定義する共同体、それらがどう割り当てられるだろうか、そして、およびそれらが置かれる用途の要件に依存する過程です。 これらの問題のすべてが名前空間(例えば、出版共同体、本屋の協会、プロトコル開発者など)を定義しようとする個々の共同体に特定です。 彼らはIETF URN仕事の範囲を超えています。

Daigle, et al.           Best Current Practice                  [Page 2]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[2ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

   This document outlines the processes by which a collection of
   identifiers satisfying certain constraints (uniqueness of assignment,
   etc) can become a bona fide URN namespace by obtaining a NID.  In a
   nutshell, a template for the definition of the namespace is completed
   for deposit with IANA, and a NID is assigned.  The details of the
   process and possibilities for NID strings are outlined below; first,
   a template for the definition is provided.

このドキュメントはある規制(課題などのユニークさ)を満たす識別子の収集がNIDを入手することによって誠実なURN名前空間になることができる過程について概説します。 殻では、名前空間の定義のためのテンプレートはIANAとの預金で完成します、そして、NIDは割り当てられます。 NIDストリングのための過程と可能性の詳細は以下に概説されています。 まず最初に、定義のためのテンプレートを提供します。

3.0 URN Namespace Definition Template

3.0 つぼの名前空間定義テンプレート

   Definition of a URN namespace is accomplished by completing the
   following information template.  Apart from providing a mechanism for
   disclosing structure of the URN namespace, this information is
   designed to be useful for

URN名前空間の定義は、以下の情報テンプレートを完成することによって、実行されます。 URN名前空間の構造を明らかにするこの情報が設計されているのでメカニズムを提供すること役に立つは別として

      - entities seeking to have a URN assigned in a namespace (if
        applicable)
      - entities seeking to provide URN resolvers for a namespace (if
        applicable)

- 名前空間(適切であるなら)でURNを割り当てようとする実体--URNレゾルバを名前空間に提供しようとする実体(適切であるなら)

   This is particularly important for communities evaluating the
   possibility of using a portion of an existing URN namespace rather
   than creating their own.

それら自身のを作成するよりむしろ既存のURN名前空間の部分を使用する可能性を評価する共同体には、これは特に重要です。

   Information in the template is as follows:

テンプレートの情報は以下の通りです:

   Namespace ID:
      Assigned by IANA.  In some contexts, a particular one may be
      requested (see below).

名前空間ID: IANAによって割り当てられます。 いくつかの文脈では、特定の要求されているかもしれません(以下を見てください)。

   Registration Information:

レジスト情報:

      This is information to identify the particular version of
      registration information:

これはレジスト情報の特定のバージョンを特定する情報です:

      - registration version number: starting with 1, incrementing by 1
        with each new version
      - registration date: date submitted to the IANA, using the format
            YYYY-MM-DD
        as outlined in [ISO8601].

- 登録バージョン番号: 1から始まるそれぞれの新しいバージョンがある1による増加--登録日付: [ISO8601]に概説されているように形式YYYY MM DDを使用して、日付はIANAに提出されました。

   Declared registrant of the namespace:

名前空間の宣言している記入者:

      Required: Name and e-mail address.
      Recommended:  Affiliation, address, etc.

必要: 名前とEメールアドレス。 お勧め: 提携、アドレスなど

Daigle, et al.           Best Current Practice                  [Page 3]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[3ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

   Declaration of syntactic structure:

統語構造の宣言:

      This section should outline any structural features of identifiers
      in this namespace.  At the very least, this description may be
      used to introduce terminology used in other sections.  This
      structure may also be used for determining realistic
      caching/shortcuts approaches; suitable caveats should be provided.
      If there are any specific character encoding rules (e.g., which
      character should always be used for single-quotes), these should
      be listed here.

このセクションはこの名前空間における、識別子に関するどんな構造上の特色についても概説するべきです。 少なくとも、この記述は、他のセクションで使用される用語を紹介するのに使用されるかもしれません。 また、この構造は現実的なキャッシュ/近道のアプローチを決定するのに使用されるかもしれません。 適当な警告を提供するべきです。 何か特定のキャラクタ符号化規則があれば(例えば、どのキャラクタがシングル・クォーテション・マークにいつも使用されるべきですか)、これらはここに記載されるべきです。

      Answers might include, but are not limited to:

含むかもしれませんが、答えは制限されません:

      - the structure is opaque (no exposition) - a regular expression
        for parsing the identifier into components, including naming
        authorities

- コンポーネント、包含に識別子を分析するための正規表現が当局を任命して、構造は不明瞭です(博覧会がありません)。

   Relevant ancillary documentation:

関連付属のドキュメンテーション:

      This section should list any RFCs, standards, or other published
      documentation that defines or explains all or part of the
      namespace structure.

このセクションはいずれもRFCs、規格、または名前空間構造のすべてか一部が定義するか、またはわかる他の発行されたドキュメンテーションを記載するべきです。

      Answers might include, but are not limited to:

含むかもしれませんが、答えは制限されません:

      - RFCs outlining syntax of the namespace
      - Other of the defining community's (e.g., ISO) documents
        outlining syntax of the identifiers in the namespace
      - Explanatory material introducing the namespace

- 名前空間の構文について概説するRFCs--名前空間における識別子の構文について概説する定義共同体のもの他(例えば、ISO)のドキュメント--名前空間を導入する説明資料

   Identifier uniqueness considerations:
   This section should address the requirement that URN identifiers be
   assigned uniquely -- they are assigned to at most one resource, and
   are not reassigned.

識別子ユニークさの問題: このセクションはURN識別子が唯一割り当てられるという要件を記述するべきです--それらは、高々1つのリソースしか割り当てられないで、また再選任されません。

   (Note that the definition of "resource" is fairly broad; for example,
   information on "Today's Weather" might be considered a single
   resource, although the content is dynamic.)

(「リソース」の定義がかなり広いことに注意してください; 例えば、「今日は風化すること」の情報がただ一つのリソースであると考えられるかもしれません、内容はダイナミックですが。)

   Possible answers include, but are not limited to:

含んでいますが、可能な答えは制限されません:

      - exposition of the structure of the identifiers, and partitioning
        of the space of identifiers amongst assignment authorities which
        are individually responsible for respecting uniqueness rules
      - identifiers are assigned sequentially
      - information is withheld; the namespace is opaque

- 個別に識別子が連続して割り当てられるという情報が差し控えられるというユニークさの規則を尊敬するのに原因となる識別子の構造の博覧会、および課題当局の識別子のスペースの仕切り。 名前空間は不透明です。

Daigle, et al.           Best Current Practice                  [Page 4]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[4ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

   Identifier persistence considerations:

識別子固執問題:

      Although non-reassignment of URN identifiers ensures that a URN
      will persist in identifying a particular resource even after the
      "lifetime of the resource", some consideration should be given to
      the persistence of the usability of the URN.  This is particularly
      important in the case of URN namespaces providing global
      resolution.

URN識別子の非再割当ては、URNが「リソースの生涯」の後にさえ特定のリソースを特定するのに固執するのを確実にしますが、URNのユーザビリティの固執に対して何らかの考慮を払うべきです。 これはグローバルな解決を提供するURN名前空間の場合で特に重要です。

      Possible answers include, but are not limited to:

含んでいますが、可能な答えは制限されません:

      - quality of service considerations

- サービスの質問題

   Process of identifier assignment:

識別子課題の過程:

      This section should detail the mechanisms and/or authorities for
      assigning URNs to resources.  It should make clear whether
      assignment is completely open, or if limited, how to become an
      assigner of identifiers, and/or get one assigned by existing
      assignment authorities.  Answers could include, but are not
      limited to:

このセクションは、URNsをリソースに割り当てるためにメカニズム、そして/または、当局について詳述するべきです。 課題が完全に開いているか、または制限されるなら、それは明らかにされるべきです、識別子の指定人になる、そして/または、既存の課題当局に1つを割り当てさせる方法。 含むことができましたが、答えは制限されません:

      - assignment is completely open, following a particular algorithm
      - assignment is delegated to authorities recognized by a
        particular organization (e.g., the Digital Object Identifier
        Foundation controls the DOI assignment space and its delegation)
      - assignment is completely closed (e.g., for a private
        organization)

- 課題は完全に開いています、特定のアルゴリズムに従って--特定の組織によって見分けられた当局へ課題を代表として派遣します(例えば、Digital Object Identifier財団はDOI課題スペースとその代表団を制御します)--課題は完全に終えられます。(例えば、民間のための)

   Process for identifier resolution:

識別子解決には、処理してください:

      If a namespace is intended to be accessible for global resolution,
      it must be registerd in an RDS (Resolution Discovery System, see
      [RFC2276]) such as NAPTR.  Resolution then proceeds according to
      standard URI resolution processes, and the mechanisms of the RDS.
      What this section should outline is the requirements for becoming
      a recognized resolver of URNs in this namespace (and being so-
      listed in the RDS registry).

名前空間がグローバルな解決にアクセスしやすいことを意図するなら、それはNAPTRなどのRDS(解決ディスカバリーSystem、[RFC2276]を見る)のregisterdであるに違いありません。 そして、標準のURI解決の過程、およびRDSのメカニズムによると、解決は続きます。 このセクションが概説するべきであることは、この名前空間でURNsの認識されたレゾルバになるための要件(そのようにRDS登録に記載されていて)です。

      Answers may include, but are not limited to:

含むかもしれませんが、答えは制限されません:

      - the namespace is not listed with an RDS; this is not relevant
      - resolution mirroring is completely open, with a mechanism for
        updating an appropriate RDS
      - resolution is controlled by entities to which assignment has
        been delegated

- 名前空間はRDSと共に記載されていません。 これは関連していません--解決ミラーリングは完全に開いています、適切なRDSをアップデートするためのメカニズムで--解決は課題が代表として派遣された実体によって制御されます。

Daigle, et al.           Best Current Practice                  [Page 5]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[5ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

   Rules for Lexical Equivalence:

語彙等価性のための規則:

      If there are particular algorithms for determining equivalence
      between two identifiers in the underlying namespace (hence, in the
      URN string itself), rules can be provided here.

2つの識別子の間には、基本的な名前空間(したがってURNストリング自体で)に等価性を決定するための特定のアルゴリズムがあれば、規則をここに提供できます。

      Some examples include:

いくつかの例は:

      - equivalence between hyphenated and non-hyphenated groupings in
        the identifier string
      - equivalence between single-quotes and double-quotes
      - Namespace-defined equivalences between specific characters, such
        as "character X with or without diacritic marks".

- 識別子ストリングにおけるハイフンを入れられて非ハイフンを入れられた組分けの間の等価性--シングル・クォーテション・マークと二重引用符の間の等価性--「区別的発音符マークのあるなしにかかわらずキャラクタX」などの特定のキャラクタの間の名前空間で定義された等価性。

      Note that these are not normative statements for any kind of best
      practice for handling equivalences between characters; they are
      statements limited to reflecting the namespace's own rules.

これらがキャラクタの間の取り扱いの等価性のためのどんな種類の最も良い習慣のための規範的陳述でないことにも注意してください。 それらは名前空間の自己の規則を反映するのに制限された声明です。

   Conformance with URN Syntax:

つぼの構文との順応:

      This section should outline any special considerations required
      for conforming with the URN syntax.  This is particularly
      applicable in the case of legacy naming systems that are used in
      the context of URNs.

このセクションはURN構文に従うのに必要である特別な問題について概説するべきです。 これはURNsの文脈で使用される遺産命名システムの場合で特に適切です。

      For example, if a namespace is used in contexts other than URNs,
      it may make use of characters that are reserved in the URN syntax.
      This section should flag any such characters, and outline
      necessary mappings to conform to URN syntax.  Normally, this will
      be handled by hex encoding the symbol.

例えば、名前空間がURNs以外の文脈で使用されるなら、それはURN構文で予約されるキャラクタを利用するかもしれません。 このセクションは、どんなそのようなキャラクタにも旗を揚げさせて、URN構文に従うために必要なマッピングについて概説するべきです。 通常、これはシンボルをコード化する十六進法によって扱われるでしょう。

      For example, see the section on SICIs in [RFC2288].

例えば、[RFC2288]のSICIsの上のセクションを見てください。

   Validation mechanism:

合法化メカニズム:

      Apart from attempting resolution of a URN, a URN namespace may
      provide mechanism for "validating" a URN -- i.e., determining
      whether a given string is currently a validly-assigned URN.  For
      example, even if an ISBN URN namespace is created, it is not clear
      that all ISBNs will translate directly into "assigned URNs".

URNの解決を試みることは別として、URN名前空間はURNが「有効にする」であるのにメカニズムを提供するかもしれません--すなわち、現在与えられたストリングが確実に割り当てられたURNであるかどうか決定します。 例えば、ISBN URN名前空間が作成されても、すべてのISBNsが直接「割り当てられたURNs」に翻訳するのは、明確ではありません。

      A validation mechanims might be:

合法化mechanimsは以下の通りです。

      - a syntax grammar
      - an on-line service
      - an off-line service

- 構文文法--パソコン通信--オフラインサービス

Daigle, et al.           Best Current Practice                  [Page 6]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[6ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

   Scope:

範囲:

      This section should outline the scope of the use of the
      identifiers in this namespace.  Apart from considerations of
      private vs. public namespaces, this section is critical in
      evaluating the applicability of a requested NID.  For example, a
      namespace claiming to deal in "social security numbers" should
      have a global scope and address all social security number
      structures (unlikely).  On the other hand, at a national level, it
      is reasonable to propose a URN namespace for "this nation's social
      security numbers".

このセクションはこの名前空間における識別子の使用の範囲について概説するべきです。 公共の名前空間に対して個人的の問題は別として、このセクションは要求されたNIDの適用性を評価するのにおいて重要です。 例えば、「社会保険番号」を扱うと主張する名前空間は、グローバルな範囲を持って、すべての社会保険番号構造(ありそうもない)を記述するべきです。 他方では、全国レベルでは、「この国の社会保険番号」のためにURN名前空間を提案するのは妥当です。

4.0 URN Namespace Registration, Update, and NID Assignment Process

4.0のつぼの名前空間登録、アップデート、およびNID課題の過程

   Different levels of disclosure are expected/defined for namespaces.
   According to the level of open-forum  discussion surrounding the
   disclosure, a URN namespace may be assigned or may request a
   particular identifier.  The [RFC2434] document suggests the need to
   specify update mechanisms for registrations -- who is given the
   authority to do so, from time to time, and what are the processes.
   Since URNs are meant to be persistently useful, few (if any) changes
   should be made to the structural interpretation of URN strings (e.g.,
   adding or removing rules for lexical equivalence that might affect
   the interpretation of URN IDs already assigned).  However, it may be
   important to introduce clarifications, expand the list of authorized
   URN assigners, etc, over the natural course of a namespace's
   lifetime.  Specific processes are outlined below.

公開の異なったレベルは、名前空間のために予想されるか、または定義されます。 公開を囲むオープン・フォーラム議論のレベルによると、URN名前空間は、割り当てられるか、または特定の識別子を要求するかもしれません。 [RFC2434]ドキュメントは登録証明書(時々そうする権威は与えられている)と過程であることのためにアップデートメカニズムを指定する必要性を示します。 URNsが持続して役に立つことが意味されるので、わずかな(もしあれば)変更しかURNストリング(例えば、既に割り当てられたURN IDの解釈に影響するかもしれない語彙等価性のために、規則を加えるか、または取り除く)の構造的な解釈にするべきではありません。 しかしながら、明確化を導入して、認可されたURN指定人のリストを広げるのなどは重要であるかもしれません、名前空間の生涯の本来の過程の上で。 特定の過程は以下に概説されています。

   There are 3 categories of URN namespaces defined here, distinguished
   by expected level of service and required procedures for
   registration.  Furthermore, registration maintenance procedures vary
   slightly from one category to another.

登録のための予想水準のサービスと必要な手順によってここで定義されて、顕著なURN名前空間の3つのカテゴリがあります。 その上、登録保守手順は1つのカテゴリから別のものにわずかに変わります。

      I.   Experimental: These are not explicitly registered with IANA.
           They take the form

I. 実験的: これらは明らかにIANAに登録されません。 彼らは形を取ります。

                                      X-<NID>

X、-、<NID>。

           No provision is made for avoiding collision of experimental
           NIDs; they are intended for use within internal or limited
           experimental contexts.

実験的なNIDsの衝突を避けるのに備えます。 彼らは内部の、または、限られた実験関係の中の使用のために意図します。

           As there is no registration, no registration maintenance
           procedures are needed.

登録が全くなくて、登録保守手順は全く必要ではありません。

      II.  Informal:  These are registered with IANA and are assigned a
           number sequence as an identifier, in the format:

II。 非公式: これらはIANAに示されて、識別子として形式で数順を割り当てられます:

Daigle, et al.           Best Current Practice                  [Page 7]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[7ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

                                  "urn-" <number>

「つぼ」<番号>。

           where <number> is chosen by the IANA on a First Come First
           Served basis (see [RFC2434]).

<番号>がFirst Come First ServedベースのIANAによって選ばれている([RFC2434]を見てください)ところ。

           Registrants should send a copy of the registration template
           (see section 3.0), duly completed, to the

記入者は正しく完成した登録テンプレート(セクション3.0を見る)のaコピーを送るはずです。

                               urn-nid@apps.ietf.org

urn-nid@apps.ietf.org

           mailing and allow for a 2 week discussion period for
           clarifying the expression of the registration information and
           suggestions for improvements to the namespace proposal.

郵送して、名前空間提案への改良のためのレジスト情報と提案の表現をはっきりさせるために2週間の議論の期間を考慮します。

           After suggestions for clarification of the registration
           information have been incorporated, the template may be
           submitted to:
                                  iana@iana.org

レジスト情報の明確化のための提案が法人組織になった後に、以下のことのためにテンプレートを提出するかもしれません。 iana@iana.org

           for assignment of a NID.

NIDの課題のために。

           The only restrictions on <number> are that it consist
           strictly of digits and that it not cause the NID to exceed
           length limitations outlined in the URN syntax ([RFC2168]).

<番号>における唯一の制限はケタから厳密に成って、NIDにURN構文([RFC2168])で概説された長さの制限を超えさせないということです。

           Registrations may be updated by the original registrant, or
           an entity designated by the registrant, by updating the
           registration template, submitting it to the discussion list
           for a further 2 week discussion period, and finally
           resubmitting it to IANA, as described above.

登録者本人、または記入者によって指定された実体で登録証明書をアップデートするかもしれません、登録テンプレートをアップデートすることによって、一層の2週間の議論の期間、議論リストにそれを提出して、最終的にIANAにそれを再提出して、上で説明されるように。

      III. Formal:  These are processed through an RFC review process.
           The RFC need not be standards-track.  The template defined in
           section 3.0 may be included as part of an RFC defining some
           other aspect of the namespace, or it may be put forward as an
           RFC in its own right.  The proposed template should be sent
           to the

III。 正式: これらはRFC吟味の過程で処理されます。 RFCは標準化過程である必要はありません。 セクション3.0で定義されたテンプレートが名前空間のある他の局面を定義するRFCの一部として含まれるかもしれませんか、またはそれはRFCとしてそれ自体で進められるかもしれません。 提案されたテンプレートを送るべきです。

                               urn-nid@apps.ietf.org

urn-nid@apps.ietf.org

           mailing list to allow for a 2 week discussion period  for
           clarifying the expression of the registration information,
           before the IESG progresses the document to RFC status.

IESGの前でレジスト情報の表現をはっきりさせるための2週間の議論の期間、許容するメーリングリストはRFC状態にドキュメントを進行します。

           A particular NID string is requested, and is assigned by IETF
           consensus (as defined in [RFC2434]), with the additional
           constraints that the NID string must

特定のNIDストリングは、要求されていて、IETFコンセンサスによって割り当てられます([RFC2434]で定義されるように)、NIDストリングがそうしなければならないという追加規制で

Daigle, et al.           Best Current Practice                  [Page 8]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[8ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

               - not be an already-registered NID
               - not start with "x-" (see Type I above)
               - not start with "urn-" (see Type II above)
               - not start with "XY-", where XY is any combination of 2
                 ASCII letters  (see NOTE, below)
               - be more than 2 letters long

- 「つぼ」(Type IIが上であることを見ます)(XYが2個のASCII手紙のあらゆる組み合わせである(注意を見てください、下)"XY"での始めでない)で既に登録されたNID(「x」(Type Iが上であることを見る)との始めでない)が始めでなかったなら、長い間、2個以上の手紙になってください。

           NOTE: ALL two-letter combinations, and two-letter
           combinations followed by "-" and any sequence of valid NID
           characters,  are reserved for potential use as countrycode-
           based  NIDs for eventual national registrations of URN
           namespaces.   The definition and scoping of rules for
           allocation of responsibility for such namespaces is beyond
           the scope of this document.

以下に注意してください。 countrycodeがつぼの名前空間の最後の国家の登録証明書のためのNIDsを基礎づけて、すべての2文字の組み合わせ、「-」があとに続いた2文字の組み合わせ、および有効なNIDキャラクタのどんな系列も潜在的使用のために控えられます。 そのような名前空間への責任の配分のための規則を定義と見ることはこのドキュメントの範囲を超えています。

           Registrations may be updated by updating the RFC through
           standard IETF RFC update mechanisms.  Thus, proposals for
           updates may be made by the original authors, other IETF
           participants, or the IESG.  In any case, the proposed updated
           template must be circulated on the urn-nid discussion list,
           allowing for a 2 week review period.

標準のIETF RFCアップデートメカニズムを通してRFCをアップデートすることによって、登録証明書をアップデートするかもしれません。その結果、原作者、他のIETF関係者、またはIESGがアップデートのための提案をするかもしれません。 どのような場合でも、提案されたアップデートされたテンプレートはつぼ-nid議論リストを循環しなければなりません、2週間のレビューのために以上を許容して。

   URN namespace registrations will be posted in the anonymous FTP
   directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-
   namespaces/".

URN名前空間登録証明書は「 ftp://ftp.isi.edu/in-notes/iana/assignments/URN- 名前空間/」という公開FTPディレクトリに掲示されるでしょう。

5.0 Example

5.0 例

   The following example is provided for the purposes of illustration of
   the URN NID template described in section 3.0.  Although it is based
   on a hypothetical "generic Internet namespace" that has been
   discussed informally within the URN WG, there are still technical and
   infrastructural issues that would have to be resolved before such a
   namespace could be properly and completely described.

セクション3.0で説明されたURN NIDテンプレートのイラストの目的に以下の例を提供します。 URN WGの中で非公式に議論した仮定している「一般的なインターネット名前空間」に基づいていますが、そのような名前空間について適切に、そして完全に説明できる前に解決されなければならない技術的でインフラストラクチャの問題がまだあります。

   Namespace ID:
      To be assigned

名前空間ID: 割り当てられるために

   Registration Information:

レジスト情報:

      Version 1
      Date: <when submitted>

バージョン1日付: <、いつが>を提出したか。

   Declared registrant of the namespace:

名前空間の宣言している記入者:

      Required: Name and e-mail address.
      Recommended:  Affiliation, address, etc.

必要: 名前とEメールアドレス。 お勧め: 提携、アドレスなど

Daigle, et al.           Best Current Practice                  [Page 9]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[9ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

   Declared registrant of the namespace:

名前空間の宣言している記入者:

      Name:           T. Cat
      E-mail:         leslie@thinkingcat.com
      Affiliation:    Thinking Cat Enterprises
      Address:        1 ThinkingCat Way
                      Trupville, NewCountry

以下を命名してください。 T。 猫メール: leslie@thinkingcat.com 提携: 考え深い猫エンタープライズアドレス: 1ThinkingCatの道のTrupville、NewCountry

   Declaration of structure:

構造の宣言:

      The identifier structure is as follows:

識別子構造は以下の通りです:

      URN:<assigned number>:<FQDN>:<assigned US-ASCII string>

URN: <は数の>を割り当てました: <FQDN>: <は米国-ASCIIストリング>を割り当てました。

      where FQDN is a fully-qualified domain name, and the assigned
      string is conformant to URN syntax requirements.

FQDNが完全修飾ドメイン名であり、割り当てられたストリングがURN構文要件へのconformantであるところ。

   Relevant ancillary documentation:

関連付属のドキュメンテーション:

      Definition of domain names, found in:

以下で見つけられたドメイン名の定義

      P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
      RFC1035, November 1987.

P.Mockapetris、「ドメイン名--、実現AND仕様、」、RFC1035、11月1987日

   Identifier uniqueness considerations:
      Uniqueness is guaranteed as long as the assigned string is never
      reassigned for a given FQDN, and that the FQDN is never
      reassigned.

識別子ユニークさの問題: ユニークさは割り当てられたストリングが与えられたFQDN、およびそれのために決して再選任されない限り、FQDNが決して再選任されないのが保証されます。

      N.B.:  operationally, there is nothing that prevents a domain name
      from being reassigned;  indeed, it is not an uncommon occurrence.
      This is one of the reasons that this example makes a poor URN
      namespace in practice, and is therefore not seriously being
      proposed as it stands.
   Identifier persistence considerations:

N.B.: 操作上、何もドメイン名が再選任されるのを防ぐものがありません。 本当に、それはまれな出来事ではありません。 これはこの例が実際には貧しいURN名前空間を作って、したがって、立つように真剣に提案されていない理由の1つです。 識別子固執問題:

      Persistence of identifiers is dependent upon suitable delegation
      of resolution at the level of "FQDN"s, and persistence of FQDN
      assignment.

識別子の固執がレベルで解決の適当な代表団に依存している、「FQDN、「s、およびFQDN課題の固執。」

      Same note as above.

上記の同じ注意。

Daigle, et al.           Best Current Practice                 [Page 10]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[10ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

   Process of identifier assignment:

識別子課題の過程:

      Assignment of these URNs delegated to individual domain name
      holders (for FQDNs).  The holder of the FQDN registration is
      required to maintain an entry (or delegate it) in the NAPTR RDS.
      Within each of these delegated name partitions, the string may be
      assigned per local requirements.

これらのURNsの課題は個々のドメイン名所有者(FQDNsのための)に委任しました。 FQDN登録の所有者はNAPTR RDSでエントリー(それを代表として派遣する)を維持しなければなりません。 それぞれのこれらの代表として派遣された名前パーティションの中では、ストリングは地方の要件単位で割り当てられるかもしれません。

      e.g.  urn:<assigned number>:thinkingcat.com:001203

例えば、つぼ: <規定番号>:thinkingcat.com:001203

   Process for identifier resolution:

識別子解決には、処理してください:

      Domain name holders are responsible for operating or delegating
      resolution servers for the FQDN in which they have assigned URNs.

ドメイン名所有者はそれらがURNsを割り当てたFQDNのために解決サーバを操作するか、または代表として派遣するのに責任があります。

   Rules for Lexical Equivalence:

語彙等価性のための規則:

      FQDNs are case-insensitive.  Thus, the portion of the URN

FQDNsは大文字と小文字を区別しないです。 その結果、URNの一部

              urn:<assigned number>:<FQDN>:

つぼ: <規定番号>: <FQDN>:

      is case-insenstive for matches.  The remainder of the identifier
      must be considered case-sensitve.

ケース-insenstiveはマッチのためのものですか? ケース-sensitveであると識別子の残りを考えなければなりません。

   Conformance with URN Syntax:

つぼの構文との順応:

      No special considerations.

特別な問題がありません。

   Validation mechanism:

合法化メカニズム:

      None specified.

なにも指定しませんでした。

   Scope:

範囲:

      Global.

グローバル。

6.0 Security Considerations

6.0 セキュリティ問題

   This document largely focuses on providing mechanisms for the
   declaration of public information.  Nominally, these declarations
   should be of relatively low security profile, however there is always
   the danger of "spoofing" and providing mis-information.  Information
   in these declarations should be taken as advisory.

このドキュメントは、主に公開情報の宣言にメカニズムを提供するのは焦点を合わせます。 名目上は、これらの宣言は比較的少ないセキュリティプロフィールのものであるはずです、いつも危険がどんなにそこに誤伝を「だまし」て、提供するのがあっても。 これらの宣言における情報は状況報告としてみなされるべきです。

Daigle, et al.           Best Current Practice                 [Page 11]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[11ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

7.0 References

7.0の参照箇所

   [RFC2168]   Daniel, R. and M. Mealling, "Resolution of Uniform
               Resource Identifiers using the Domain Name System", RFC
               2168, June 1997.

[RFC2168] ダニエルとR.とM.食事、「ドメインネームシステムを使用するUniform Resource Identifierの決議」、RFC2168、1997年6月。

   [RFC2169]   Daniel, R., "A Trivial Convention for using HTTP in URN
               Resolution", RFC 2169, June 1997.

[RFC2169]ダニエル、R.、「つぼの解決にHTTPを使用するための些細なコンベンション」、RFC2169、1997年6月。

   [ISO8601]   ISO 8601 : 1988 (E), "Data elements and interchange
               formats - Information interchange - Representation of
               dates and times"

[ISO8601]ISO8601: 1988(E)、「データ要素と置き換え形式--情報交換--日付と回の表現」

   [RFC2288]   Lynch, C., Preston, C. and R. Daniel, "Using Existing
               Bibliographic Identifiers as Uniform Resource Names", RFC
               2288, February 1998.

[RFC2288] リンチとC.とプレストンとC.とR.ダニエル、「一定のリソース名として既存の図書目録の識別子を使用します」、RFC2288、1998年2月。

   [NAPTR-REG] Mealling, M., "Assignment Procedures for NAPTR DNS URI
               Resolution", Work in Progress.

[NAPTR-REG] 食事、M.、「NAPTR DNS URI解決のための課題手順」が進行中で働いています。

   [RFC2141]   Moats, R., "URN Syntax", RFC 2141, May 1997.

[RFC2141]モウツ(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。

   [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
               October 1998.

[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [RFC1737]   Sollins, K. and L. Masinter, "Functional Requirements for
               Uniform Resource Names", RFC 1737, December 1994.

[RFC1737] SollinsとK.とL.Masinter、「一定のリソース名のための機能条件書」、RFC1737、1994年12月。

   [RFC2276]   Sollins, K., "Architectural Principles of Uniform
               Resource Name Resolution", RFC 2276, January 1998.

[RFC2276]Sollins、1998年1月のK.、「一定のリソース名前解決の建築プリンシプルズ」RFC2276。

Daigle, et al.           Best Current Practice                 [Page 12]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[12ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

8.0 Authors' Addresses

8.0 作者のアドレス

   Leslie L. Daigle
   Thinking Cat Enterprises

猫計画を考えるレスリーL.Daigle

   EMail:  leslie@thinkingcat.com

メール: leslie@thinkingcat.com

   Dirk-Willem van Gulik
   ISIS/STA/CEO - TP 270
   Joint Research Centre Ispra
   21020 Ispra (Va)
   Italy.

DirkウィレムバンGulikイシス/STA/最高経営責任者--TP270共同研究センターイスプラ21020イスプラ(Va)イタリア。

   Phone: +39 332 78 9549 or 5044
   Fax:   +39 332 78 9185
   EMail:  Dirk.vanGulik@jrc.it

以下に電話をしてください。 +39 332 78 9549か5044Fax: +39 332 78 9185はメールされます: Dirk.vanGulik@jrc.it

   Renato Iannella
   DSTC Pty Ltd
   Gehrmann Labs, The Uni of Queensland
   AUSTRALIA, 4072

レナートIannella DSTC Pty Ltd Gehrmann研究室、クイーンズランドオーストラリアのUni、4072

   Phone:  +61 7 3365 4310
   Fax:    +61 7 3365 4311
   EMail:  renato@dstc.edu.au

以下に電話をしてください。 +61 7 3365 4310、Fax: +61 7 3365 4311はメールされます: renato@dstc.edu.au

   Patrik Faltstrom
   Tele2/Swipnet
   Borgarfjordsgatan 16
   P.O. Box 62
   S-164 94 Kista
   SWEDEN

パトリクFaltstrom Tele2/Swipnet Borgarfjordsgatan16私書箱62秒間-164 94Kistaスウェーデン

   Phone:  +46-5626 4000
   Fax:    +46-5626 4200
   EMail:  paf@swip.net

以下に電話をしてください。 +46-5626 4000Fax: +46-5626 4200はメールされます: paf@swip.net

Daigle, et al.           Best Current Practice                 [Page 13]

RFC 2611          URN Namespace Definition Mechanisms          June 1999

Daigle、他 最も良い現在の練習の[13ページ]RFC2611つぼの名前空間定義メカニズム1999年6月

9.0  Full Copyright Statement

9.0 完全な著作権宣言文

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

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

Daigle, et al.           Best Current Practice                 [Page 14]

Daigle、他 最も良い現在の習慣[14ページ]