RFC 4198 - A Uniform Resource Name (URN) Namespace for Federated Content 日本語訳

URL : https://tools.ietf.org/html/rfc4198
タイトル : RFC 4198 - フェデレーテッドコンテンツの統一リソース名（URN）名前空間
翻訳編集 : 自動生成

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

     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.

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

著作権表示

著作権（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（ユニフォームリソース名）の名前空間について説明します。連合コンテンツコレクションは、多くの場合、強力な中央集権を持っていますが、そのメンバー間の相互運用性を提供するために、共有命名、メタデータ、およびアクセス規則に依存していません。

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.

コンテンツプロバイダは、参加したり、いつでもフェデレーションを残すと同時に、複数のフェデレーションの一部であってもよいしてもよいです。コンテンツプロバイダはまた、他の人が使用するために自分のドメイン名を解放し、完全に組織としてなくなる可能性があります。また、コンテンツ識別子は、フェデレーションのメンバー全体に広がっています。これらの識別子は、使用される前に、長い期間のために、時には、様々なメディアに保存されます。彼らは権威を命名する強力なコンテンツなしの状況でうまく動作しますが、彼らはユニークかつ永続的に特定のコンテンツのリソースに接続することができないので、そのため、URLがフェデレーション内のコンテンツ識別子として不十分です。

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名前空間は、中央命名機関が必要とされていないことにより、メカニズムを提供します。プロバイダは、ユニークかつ永続的なものにURNを保証するガイドラインに独自のコンテンツに対する権限を維持命名します。

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"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" [1] RFC 2119に記載されるように解釈されるべきです。

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ヘンリエッタアベニューラCrescenta、CA 91214から3007 USA

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

連絡先：デイブテスマンEメール：tessman@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（DIGIT）RESOURCEID = 1 *（alphanum /その他/（ "％" 六角進））ラベル= alphanum / alphanum *（alphanum / " - "）alphanum toplabel = ALPHA / ALPHA *（alphanum / " - "）alphanum CCYY = 4（DIGIT）

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）/（ "1" ％のx30-32）DD =（ "0" ％のx31-39）/（％x31-32 DIGIT）/ "30" / "31" alphanum = ALPHA / DIGIT六角= DIGIT /％x41-46 /％x61-66他= "（" / "）" / "+" / "" / " - " "" / / "：" / "=" / "@" / ";" / "$" / "_" / "！" / "*" / "'"

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は、ISO 8601の基本的なフォーマット（CCYY [MM [DD]]）の日付で、URNを割り当てる組織がProviderIdで指定されたドメイン名を所有していた上の特定の日に対応しなければなりません。含まれていない場合は、MMとDDのデフォルト値は「01」です。 1〜3桁のDateIdsが予約されています。

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

RESOURCEIDが同じプロバイダから出て、同じDateIdを持つすべてのResourceIdsの中で一意でなければなりません。

Relevant ancillary documentation:

4. Examples

4.例

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

以下の実施例は、この名前空間内のURNを代表するものであり、実際のリソースを参照しなくてもよいです。

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

URN：FDC：example.com：2002：A572007のurn：FDC：example.net：200406：IVR：51089 URN：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.

通常、一般的なのURNの使用と解決に関連づけられたもの以外の追加のセキュリティの考慮事項はありません。

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の要件を満たすためにユニークで貴重なツールとなっています。

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部分を分解する必要があります。また、RFC 2169に記載された識別子解決機構[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.

この文書は、RFC 3406 [5]に準拠し、URNのNIDの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.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

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

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

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

[3]ダニエル、R.、RFC 2169、1997年6月、 "URNの解決にHTTPを使用するための些細な条約"。

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

[4]堀、R.、 "URN構文"、RFC 2141、1997年5月を。

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、 "統一リソース名（URN）名前空間定義メカニズム"、BCP 66、RFC 3406、2002年10月。

Author's Address

著者のアドレス

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

デイブ・テスマンZelestra 2314ヘンリエッタアベニューラCrescenta、カリフォルニア州91214から3007 USA

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

電話：+1 818 249 8906 Eメール：dtessman@zelestra.com

Full Copyright Statement

完全な著作権声明

著作権（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.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

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リポジトリから。

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