RFC4198 日本語訳

Network Working Group                                         D. Tessman
Request for Comments: 4198                                      Zelestra
Category: Informational                                    November 2005

Tessmanがコメントのために要求するワーキンググループD.をネットワークでつないでください: 4198年のZelestraカテゴリ: 情報の2005年11月

     A Uniform Resource Name (URN) Namespace for Federated Content

連邦化された内容のための一定のリソース名前(つぼ)名前空間

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This document describes a URN (Uniform Resource Name) namespace for
   identifying content resources within federated content collections.
   A federated content collection often does not have a strong
   centralized authority but relies upon shared naming, metadata, and
   access conventions to provide interoperability among its members.

このドキュメントは、連邦化された満足している収集の中で満足しているリソースを特定するためにURN(一定のResource Name)名前空間について説明します。 連邦化された満足している収集は、しばしば強い集結された権威を持っているというわけではありませんが、相互運用性をメンバーに提供するために共有された命名、メタデータ、およびアクセスコンベンションを当てにします。

1.  Introduction

1. 序論

   Federated content collections are often loose constructs of both
   small and large content providers, with an active community, but
   without significant central authority.  Members are bound together by
   shared purpose and interoperate through shared naming, metadata, and
   access conventions.  Federations may also consist of other
   federations, creating complex associations and dependencies.

連邦化された満足している収集は小さいものと活動的な共同体にもかかわらず、重要な主要な権威のない同様に大きいコンテンツプロバイダーのしばしばゆるい構造物です。 メンバーは、共有された目的によって一緒に制限されていて、共有された命名、メタデータ、およびアクセスコンベンションで共同利用します。 また、複雑な協会と依存を創設して、連邦は他の連邦から成るかもしれません。

   A content provider may join or leave a federation at any time and may
   be part of more than one federation at the same time.  Content
   providers may also cease as organizations altogether, freeing their
   domain names for use by others.  In addition, content identifiers are
   spread throughout the members of a federation.  These identifiers are
   stored on various media, sometimes for long durations before being
   used.  Therefore, although they work well in situations without a
   strong content naming authority, URLs are insufficient as content
   identifiers within a federation because they cannot be uniquely and
   permanently tied to a specific content resource.

コンテンツプロバイダーは、接合するかもしれないか、いつでも、連邦を出て、同時に、1つ以上の連邦の一部であるかもしれません。 また、他のものによる使用のためにそれらのドメイン名を解放して、コンテンツプロバイダーは全体で組織としてやむかもしれません。 さらに、満足している識別子は連邦のメンバー中で広げられます。 これらの識別子は使用される前に、時々長い持続時間のために様々なメディアで格納されます。 したがって、彼らは権威を命名する強い内容なしで状況でうまくいきますが、URLは、唯一と永久に特定の満足しているリソースにそれらを結ぶことができないので、満足している識別子として連邦の中で不十分です。

Tessman                      Informational                      [Page 1]

RFC 4198          URN Namespace for Federated Content      November 2005

連邦化された満足している2005年11月のためのTessmanの情報[1ページ]のRFC4198つぼの名前空間

   This URN namespace provides a mechanism whereby a central naming
   authority is not required.  Providers maintain naming authority over
   their own content within guidelines that guarantee URNs to be unique
   and permanent.

このURN名前空間は主要な命名権威が必要とされないメカニズムを提供します。 プロバイダーは、ガイドラインの中のそれら自身の内容の上の権威をその保証URNsと命名するのがユニークであって、永久的であると主張します。

   A simple identifier resolution convention is also recommended to
   provide a consistent URN resolver interface across all providers.

また、簡単な識別子解決コンベンションがすべてのプロバイダーの向こう側に一貫したURNレゾルバインタフェースを提供することが勧められます。

   This namespace specification is for a formal namespace.

この名前空間仕様は正式な名前空間のためのものです。

2.  Terminology

2. 用語

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].

本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように解釈されることであるべきですか?

3.  Specification Template

3. 仕様テンプレート

   Namespace ID:

名前空間ID:

      "fdc"

"fdc"

   Registration Information:

レジスト情報:

      Registration Version Number: 1
      Registration Date: 2005-04-25

登録バージョン番号: 1 登録日付: 2005-04-25

   Declared registrant of the namespace:

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

      Name:       Zelestra
      Address:    2314 Henrietta Avenue
                  La Crescenta, CA 91214-3007
                  USA

以下を命名してください。 Zelestraアドレス: 2314年のヘンリエッタAvenueラクレセンタ、カリフォルニア91214-3007米国

      Contact:    Dave Tessman
      E-mail:     dtessman@zelestra.com

接触: デーヴTessmanはメールします: dtessman@zelestra.com

   Declaration of syntactic structure:

統語構造の宣言:

      The NSS has the following ABNF [2] specification:

NSSには、以下のABNF[2]仕様があります:

      NSS         = ProviderId ":" DateId ":" ResourceId
      ProviderId  = 1*(label ".") toplabel
      DateId      = (CCYY [MM [DD]]) / 1*3(DIGIT)
      ResourceId  = 1*(alphanum / other / ("%" hex hex))
      label       = alphanum / alphanum *(alphanum / "-") alphanum
      toplabel    = ALPHA / ALPHA *(alphanum / "-") alphanum
      CCYY        = 4(DIGIT)

「NSSはProviderIdと等しい」:、」 "DateId":、」 「ResourceId ProviderId=1*、(ラベル、」、」、)、toplabel DateId=(CCYY[mm[DD]])/1*3(ケタ)ResourceId=1*(alphanum/もう一方/(「%」十六進法十六進法))ラベル=alphanum / alphanum*(alphanum/「-」)alphanum toplabelはアルファ/アルファ*(alphanum/「-」)alphanum CCYY=4と等しいです。(ケタ)

Tessman                      Informational                      [Page 2]

RFC 4198          URN Namespace for Federated Content      November 2005

連邦化された満足している2005年11月のためのTessmanの情報[2ページ]のRFC4198つぼの名前空間

      MM          = ("0" %x31-39) / ("1" %x30-32)
      DD          = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"
      alphanum    = ALPHA / DIGIT
      hex         = DIGIT / %x41-46 / %x61-66
      other       = "(" / ")" / "+" / "," / "-" / "." / ":" / "=" /
                    "@" / ";" / "$" / "_" / "!" / "*" / "'"

MMが等しい、(「0インチの%x31-39) /、(「x30-32) 1インチの%DDが等しい、(「0インチの%x31-39) /、(%、x31-32ケタ)、/「30インチ/「」 =アルファ/ケタ十六進法=ケタ/%x41-46/%x61-66もう一方=「」 (「/」)/「+」/」、31インチalphanum/「-」/」」、」 / ":" / "=" / "@" / ";" / "$" / "_" / "!" / "*" / "'"

      ProviderId is the content provider's identifier.  ProviderId MUST
      be an Internet domain name and MUST be owned by the organization
      creating the resource and allocating the URN to the resource.

ProviderIdはコンテンツプロバイダーの識別子です。 ProviderIdをインターネットドメイン名でなければならなく、リソースを作成して、URNをリソースに割り当てる組織は所有しなければなりません。

      DateId is a date in ISO 8601 Basic Format (CCYY[MM[DD]]), and MUST
      correspond to a specific day on which the organization allocating
      the URN owned the domain name specified in the ProviderId.  If not
      included, the default value for MM and DD is "01".  DateIds of 1
      to 3 digits are reserved.

DateIdはISO8601Basic Format(CCYY[MM[DD]])の日付であり、URNを割り当てる組織がProviderIdで指定されたドメイン名を所有していた特定の日に対応しなければなりません。 含まれていないなら、MMとDDのためのデフォルト値は「1インチ」です。 1〜3ケタのDateIdsは予約されています。

      ResourceId MUST be unique among all ResourceIds emanating from the
      same provider and having the same DateId.

同じプロバイダーから発して、同じDateIdを持っていて、ResourceIdはすべてのResourceIdsの中でユニークであるに違いありません。

   Relevant ancillary documentation:

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

      None.

なし。

   Identifier uniqueness considerations:

識別子ユニークさの問題:

      The combination of ProviderId and DateId serves to uniquely
      identify the organization that is allocating the URN.  That
      organization is responsible for ensuring the uniqueness of the
      ResourceId.

ProviderIdとDateIdの組み合わせは、唯一URNを割り当てている組織を特定するのに役立ちます。 その組織はResourceIdのユニークさを確実にするのに責任があります。

   Identifier persistence considerations:

識別子固執問題:

      A URN of this namespace may only be allocated by an organization
      that owns an Internet domain name.  The URN identifies a date on
      which the organization owned that domain name.  The combination of
      domain name and date will serve to uniquely identify that
      organization for all time.

この名前空間のURNはインターネットドメイン名を所有している組織によって割り当てられるだけであるかもしれません。 URNは組織がそのドメイン名を所有していた日付を特定します。 ドメイン名と日付の組み合わせは、時間中に唯一その組織を特定するのに役立つでしょう。

   Process of identifier assignment:

識別子課題の過程:

     The organization identified by the ProviderId/DateId combination is
     responsible for allocating a ResourceId that is unique among all
     those that it allocates with that DateId.

ProviderId/DateId組み合わせで特定された組織はそれがそのDateIdと共に割り当てるすべてのものでユニークなResourceIdを割り当てるのに責任があります。

Tessman                      Informational                      [Page 3]

RFC 4198          URN Namespace for Federated Content      November 2005

連邦化された満足している2005年11月のためのTessmanの情報[3ページ]のRFC4198つぼの名前空間

   Process of identifier resolution:

識別子解決の過程:

     Content providers are responsible for the provision of a URN
     resolution service, if any, for URNs they have assigned with a
     valid ProviderId/DateId combination.

コンテンツプロバイダーはURN解決サービスの支給に責任があります、もしあれば、彼らが有効なProviderId/DateId組み合わせで割り当てたURNsのために。

     Content providers SHOULD support URN resolution by using the HTTP
     protocol convention described in RFC 2169 [3].  The ProviderId
     SHOULD be used as the HTTP server location.

コンテンツプロバイダーSHOULDは、RFC2169[3]で説明されたHTTPプロトコルコンベンションを使用することによって、URN解決を支持します。 ProviderId SHOULD、HTTPサーバ位置として、使用されてください。

   Rules for Lexical Equivalence:

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

      In addition to the rules defined in RFC 2141 [4], normalize the
      case of the ProviderId to lower case before comparison.

RFC2141[4]で定義された規則に加えてProviderIdに関するケースを正常にして、比較の前にケースを下ろしてください。

   Conformance with URN Syntax:

つぼの構文との順応:

      There are no additional characters reserved.

予約された添字が全くありません。

   Validation mechanism:

合法化メカニズム:

      None additional to resolution specified.

解決に追加しているなにも指定しませんでした。

   Scope:

範囲:

      Global

グローバル

4.  Examples

4. 例

   The following examples are representative of URNs in this namespace,
   but may not refer to actual resources.

以下の例は、この名前空間におけるURNsを代表しますが、実際のリソースを示さないかもしれません。

   urn:fdc:example.com:2002:A572007
   urn:fdc:example.net:200406:ivr:51089
   urn:fdc:example.org:20010527:img089322-038

つぼ:fdc:example.com:2002:A572007つぼ: fdc:example.net:200406:ivr:51089つぼ:fdc:example.org:20010527:img089322-038

5.  Security Considerations

5. セキュリティ問題

   There are no additional security considerations other than those
   normally associated with the use and resolution of URNs in general.

通常、一般に、URNsの使用と解決に関連づけられたもの以外の追加担保問題が全くありません。

6.  Namespace Considerations

6. 名前空間問題

   Distribution of naming authority, identifier flexibility, and a
   recommended URN resolution mechanism make this namespace a unique and
   valuable tool to meet the URN requirements of small content providers
   and federated content collections.

命名権威の分配、識別子の柔軟性、およびお勧めのURN解決メカニズムはこの名前空間を小さいコンテンツプロバイダーと連邦化された満足している収集に関するURN必要条件を満たすユニークで貴重なツールにします。

Tessman                      Informational                      [Page 4]

RFC 4198          URN Namespace for Federated Content      November 2005

連邦化された満足している2005年11月のためのTessmanの情報[4ページ]のRFC4198つぼの名前空間

7.  Community Considerations

7. 共同体問題

   By establishing a simple, flexible, and efficient means for smaller
   content providers to uniquely identify and publish their content,
   this namespace reduces the effort required for these providers to
   participate in federated collections.  A consistent identifier format
   and resolution mechanism also increases the ability of federations to
   accept content references from smaller providers and to aggregate
   themselves into federations of federations.  Increased participation
   and aggregation results in a larger selection of distinctive content
   that is more accessible to the community.

より小さいコンテンツプロバイダーが唯一それらの内容を特定して、発表する簡単で、フレキシブルで、効率的な手段を確立することによって、この名前空間はこれらのプロバイダーが連邦化された収集に参加するのに必要である努力を抑えます。 また、一貫した識別子形式と解決メカニズムは連邦が、より小さいプロバイダーから内容照会を受け入れて、自分たちに集められる能力を連邦の連邦に高めます。 増加する参加と集合は共同体によりアクセス可能な特有の内容の、より広い選択をもたらします。

   To make use of this namespace, a content provider should further
   decompose the ResourceId portion of the namespace syntactic structure
   to meet their internal content identification needs and establish an
   internal governance mechanism to ensure that all identifiers created
   follow the requirements of this namespace.  It is also recommended
   that the identifier resolution mechanism described in RFC 2169 [3] be
   provisioned within an HTTP server designated by the ProviderId
   portion of the namespace syntactic structure.

この名前空間を利用するなら、コンテンツプロバイダーは、識別子が作成したすべてがこの名前空間の要件に続くのを保証するために彼らの内部の満足している識別需要を満たして、内部の支配メカニズムを証明するためにさらに名前空間統語構造のResourceId部分を分解するべきです。 また、RFC2169[3]で説明された識別子解決メカニズムが名前空間統語構造のProviderId部分によって指定されたHTTPサーバの中で食糧を供給されるのも、お勧めです。

8.  IANA Considerations

8. IANA問題

   This document includes a URN NID registration that conforms to RFC
   3406 [5] and has been entered into the IANA registry of URN NIDs.

このドキュメントはRFC3406[5]に従って、URN NIDsのIANA登録に入れられたURN NID登録を含んでいます。

Normative References

引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

[2] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

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

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

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

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

Informative References

有益な参照

   [5]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
        "Uniform Resource Names (URN) Namespace Definition Mechanisms",
        BCP 66, RFC 3406, October 2002.

[5] Daigle、L.、バンGulik、D.、Iannella、R.、およびP.Faltstrom、「一定のリソースは(つぼ)名前空間定義をメカニズムと命名します」、BCP66、RFC3406、2002年10月。

Tessman                      Informational                      [Page 5]

RFC 4198          URN Namespace for Federated Content      November 2005

連邦化された満足している2005年11月のためのTessmanの情報[5ページ]のRFC4198つぼの名前空間

Author's Address

作者のアドレス

   Dave Tessman
   Zelestra
   2314 Henrietta Avenue
   La Crescenta, California 91214-3007
   USA

デーヴTessman Zelestra2314ヘンリエッタAvenueカリフォルニア91214-3007ラクレセンタ(米国)

   Phone: +1 818 249 8906
   EMail: dtessman@zelestra.com

以下に電話をしてください。 +1 8906年の818 249メール: dtessman@zelestra.com

Tessman                      Informational                      [Page 6]

RFC 4198          URN Namespace for Federated Content      November 2005

連邦化された満足している2005年11月のためのTessmanの情報[6ページ]のRFC4198つぼの名前空間

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Tessman                      Informational                      [Page 7]

Tessman情報です。[7ページ]