RFC 3622 - A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3622
タイトル : RFC 3622 - Liberty Alliance Projectのユニフォームリソース名（URN）名空間
翻訳編集 : 自動生成

[要約] RFC 3622は、Liberty Alliance ProjectのためのUniform Resource Name（URN）名前空間を定義しています。このRFCの目的は、Liberty Alliance Projectのリソースを一意に識別するためのURNの使用を促進することです。

Network Working Group                                        M. Mealling
Request for Comments: 3622                                VeriSign, Inc.
Category: Informational                                    February 2004

A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project

Liberty Alliance Projectのユニフォームリソース名（URN）名空間

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.

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

著作権表示

Abstract

概要

This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.

このドキュメントでは、連合ネットワークアイデンティティのLibertyアーキテクチャ内のさまざまなオブジェクトを識別するユニフォームのリソース名（URN）名前空間について説明します。

1. Introduction

1. はじめに

The Liberty Architecture seeks to provide federated network identity in such a way that enhances security, privacy and trust; thus creating a networked world across which individuals and businesses can engage in virtually any transaction without compromising the privacy and security of vital identity information.

Liberty Architectureは、セキュリティ、プライバシー、信頼を高めるような方法で、連邦ネットワークのアイデンティティを提供しようとしています。したがって、重要なアイデンティティ情報のプライバシーとセキュリティを損なうことなく、個人や企業が事実上あらゆる取引に従事できるネットワーク化された世界を作成します。

One fundamental component of this architecture is its use of XML [5], and specifically, XML Schema [7] and Namespaces [6]. These components require identifiers that will live far beyond the lifetime of the organization that produced them. As such, a URN namespace for those components that adheres to the assumptions and policies of the Liberty specification is required.

このアーキテクチャの基本的な要素の1つは、XML [5]、具体的にはXMLスキーマ[7]および名前空間[6]の使用です。これらのコンポーネントには、それらを生産した組織の寿命をはるかに超えて生きる識別子が必要です。そのため、Liberty仕様の仮定とポリシーを順守するコンポーネントのurnネームスペースが必要です。

This namespace specification is for a formal namespace.

この名前空間仕様は、正式な名前空間用です。

2. Specification Template

2. 仕様テンプレート

Namespace ID:

名前空間ID：

"liberty" requested.

「自由」が要求されました。

Registration Information:

登録情報：

Registration Version Number: 1

登録バージョン番号：1

Registration Date: 2003-04-01

登録日：2003-04-01

Declared registrant of the namespace:

名前空間の登録者を宣言する：

Liberty Alliance Project

c/o IEEE-ISTO

c/o ieee-isto

445 Hoes Lane

Piscataway, NJ 08855-1331, USA

ピスカタウェイ、ニュージャージー州08855-1331、米国

info@projectliberty.org

Declaration of structure:

構造の宣言：

The Namespace Specific Strings (NSS) of all URNs assigned by Liberty will conform to the syntax defined in section 2.2 of RFC 2141 [1]. In addition, all Liberty URN NSSs will consist of a left-to-right series of tokens delimited by colons. The left-to-right sequence of colon-delimited tokens corresponds to descending nodes in a tree. To the right of the lowest naming authority node there may be zero, one or more levels of hierarchical (although not in the RFC 2396 [2] sense of 'hierarchy') naming nodes terminating in a rightmost leaf node. See the section entitled "Identifier assignment" below for more on the semantics of NSSs. This syntax convention is captured in the following normative ABNF [4] rules for Liberty NSSs:

Libertyによって割り当てられたすべてのURNの名前空間固有の文字列（NSS）は、RFC 2141 [1]のセクション2.2で定義されている構文に適合します。さらに、すべてのLiberty URN NSSSは、コロンによって区切られた左から右へのシリーズのトークンで構成されます。コロン削除されたトークンの左から右へのシーケンスは、ツリー内の下降ノードに対応しています。最低命名機関のノードの右側には、右端の葉のノードで終了するノードの命名ノードの階層的な階層の1つまたは複数のレベルの階層があります。NSSSのセマンティクスの詳細については、以下の「識別子割り当て」というタイトルのセクションを参照してください。この構文規則は、Liberty NSSSの次の規範的ABNF [4]ルールでキャプチャされます。

      Liberty-NSS        =   1*(subStChar) 0*(":" 1*(subStChar))
      subStChar       =   trans / "%" HEXDIG HEXDIG
      trans           =   ALPHA / DIGIT / other / reserved
      other           =   "(" / ")" / "+" / "," / "-" / "." /
                          "=" / "@" / ";" / "$" /
                          "_" / "!" / "*" / "'"
      reserved        =   "%" / "/" / "?" / "#"
            The exclusion of the colon from the list of "other" characters
      means that the colon can only occur as a delimiter between string
      tokens.  Note that this ABNF rule set guarantees that any valid
      Liberty NSS is also a valid RFC 2141 NSS.

For example:

例えば：

         urn:liberty:schemas:authctx:2002:05
         urn:liberty:schemas:core:2002:12

Relevant ancillary documentation:

3. IANA Considerations

3. IANAの考慮事項

This document includes a URN Namespace registration that has been entered into the IANA registry for URN NIDs.

このドキュメントには、URN NIDのIANAレジストリに入力されたURNネームスペース登録が含まれています。

4. Community Considerations

4. コミュニティの考慮事項

While there is no resolution mechanism for this namespace, the names themselves are used in public implementations of the Liberty specifications. There are circumstances where objects from the Liberty system will become exposed to the general Internet. In these cases, the use of the Liberty namespace will provide general interoperability benefits to the Internet at large. Additionally, there may be subcomponents of the Liberty specifications that may be adopted by other standards, in which case the URNs used to identify those components and specifications can be easily used to enhance other, non-Liberty based, systems.

この名前空間には解像度のメカニズムはありませんが、名前自体はLiberty仕様の公開実装で使用されます。Libertyシステムのオブジェクトが一般的なインターネットにさらされる状況があります。これらの場合、Liberty Namespaceの使用は、インターネット全体に一般的な相互運用性の利点を提供します。さらに、他の基準で採用される可能性のあるLiberty仕様のサブコンポーネントがある場合があります。その場合、これらのコンポーネントと仕様を識別するために使用されるURNは、他の非自由ベースのシステムを強化するために簡単に使用できます。

5. Security Considerations

5. セキュリティに関する考慮事項

Since there is no defined resolution mechanism for Liberty URNs it is difficult to authenticate the fact that a given namespace actually adheres to the standard, thus applications should be careful to not take some unverified sources assertion that what it is sending adheres to what the actual URN is assigned to.

Liberty URNに定義された解像度メカニズムがないため、特定の名前空間が実際に標準を順守するという事実を認証することは困難です。に割り当てられます。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

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

[1] Moats、R。、「urn構文」、RFC 2141、1997年5月。

[2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[2] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。

[3] Hodges, J. and T. Watson, "Liberty Architecture Overview", Liberty 1.1, January 2003, <http://www.projectliberty.org/specs/liberty-architecture-overview-v1.1.pdf>.

[3] Hodges、J。and T. Watson、「Liberty Architectureの概要」、Liberty 1.1、2003年1月、<http://www.projectliberty.org/specs/liberty-architecture-overview-v1.1.pdf>。

6.2. Informative References

6.2. 参考引用

[4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[4] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。

[5] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.

[5] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C。、およびE. Maler、「拡張可能なマークアップ言語（XML）1.0（第2版）」、W3C Rec-XML、2000年10月、<http：// www。w3.org/tr/rec-xml>。

[6] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.

[6] Bray、T.、Hollander、D。and A. layman、「XMLの名前空間」、W3C Rec-Xml-Names、1999年1月、<http://www.w3.org/tr/rec-xml-names>。

[7] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.

[7] Thompson、H.、Beech、D.、Maloney、M. and N. Mendelsohn、「XML Schema Part 1：Structures」、W3C Rec-Xmlschema-1、2001年5月、<http://www.w3.org/tr/xmlschema-1/>。

7. Intellectual Property Statement

7. 知的財産声明

The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.

IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。

8. Author's Address

8. 著者の連絡先

Michael Mealling VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166 USA

Michael Mealling Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166 USA

   Phone: +1 678 581 9656
   EMail: michael@neonym.net
   URI:   http://www.verisignlabs.com

9. Full Copyright Statement

9. 完全な著作権声明

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。

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