RFC3622 日本語訳
3622 A Uniform Resource Name (URN) Namespace for the Liberty AllianceProject. M. Mealling. February 2004. (Format: TXT=11432 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Mealling Request for Comments: 3622 VeriSign, Inc. Category: Informational February 2004
コメントを求める要求を荒びきにして、作業部会M.をネットワークでつないでください: 3622年のベリサインInc.カテゴリ: 情報の2004年2月
A Uniform Resource Name (URN) Namespace for
the Liberty Alliance Project
自由同盟プロジェクトのための一定のリソース名前(つぼ)名前空間
Status of this Memo
この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 (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.
このドキュメントは連邦化されたネットワークのアイデンティティのためにリバティArchitectureの中で様々な物を特定するUniform Resource Name(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.
リバティ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 Schema[7]、およびNamespaces[6]のその使用です。 これらのコンポーネントは遠くにそれらを生産した組織の生涯を遠くに住ませる識別子を必要とします。 そういうものとして、それらのコンポーネントのための仮定を固く守るURN名前空間とリバティ仕様の方針が必要です。
This namespace specification is for a formal namespace.
この名前空間仕様は正式な名前空間のためのものです。
Mealling Informational [Page 1] RFC 3622 The Liberty URN Namespace February 2004
自由つぼの名前空間2004年2月に情報[1ページ]のRFC3622を荒びきにします。
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
気付IEEE-ISTO
445 Hoes Lane
445はレーンに鍬を入れます。
Piscataway, NJ 08855-1331, USA
ピスキャタウェイ、ニュージャージー08855-1331(米国)
info@projectliberty.org
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:
リバティによって割り当てられたすべてのURNsのNamespace Specific Strings(NSS)はRFC2141[1]のセクション2.2で定義された構文に従うでしょう。 さらに、すべてのリバティURN NSSsがコロンによって区切られた象徴の左から右へのシリーズから成るでしょう。 コロンで区切られた象徴のいなくなっている正しい系列は木でノードを滑降させると対応しています。 最も少ない命名権威ノードの右には、ゼロ(一番右の葉のノードで終わる1つ以上のレベルの階層的な('階層構造'のいずれのRFC2396[2]意味でもそうしませんが)命名ノード)があるかもしれません。 詳しい情報については、セクションがNSSsの意味論で以下で「識別子課題」の権利を与えられるのを見てください。 リバティNSSsのために以下の標準のABNF[4]規則でこの構文コンベンションを捕らえます:
Liberty-NSS = 1*(subStChar) 0*(":" 1*(subStChar))
subStChar = trans / "%" HEXDIG HEXDIG
trans = ALPHA / DIGIT / other / reserved
other = "(" / ")" / "+" / "," / "-" / "." /
"=" / "@" / ";" / "$" /
"_" / "!" / "*" / "'"
reserved = "%" / "/" / "?" / "#"
「他の、または、移-/「%」HEXDIG HEXDIG移-=アルファ/ケタ/予約された1*(subStChar)0*(「:」 1*(subStChar))自由-NSS=subStChar=もう一方は」 「」 (「/」)/「+」/」、/「-」/と等しい」、」 / "=" / "@" / ";" / "$" / "_" / "!" /「」 */「'「予約された=「%」/」/」/“?"' / "#"
Mealling Informational [Page 2] RFC 3622 The Liberty URN Namespace February 2004
自由つぼの名前空間2004年2月に情報[2ページ]のRFC3622を荒びきにします。
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.
「他」のキャラクタのリストからのコロンの除外は、コロンがストリング象徴の間のデリミタとして起こることができるだけであることを意味します。 このABNF規則セットが、また、どんな有効なリバティNSSも有効なRFC2141NSSであることを保証することに注意してください。
For example:
例えば:
urn:liberty:schemas:authctx:2002:05
urn:liberty:schemas:core:2002:12
つぼ:自由:schemas: authctx: 2002:05 つぼ:自由:schemas: コア:、2002:12
Relevant ancillary documentation:
関連付属のドキュメンテーション:
Liberty Architecture Overview [3]
自由構造概観[3]
Version 1.1
バージョン1.1
Liberty Alliance Project
自由同盟プロジェクト
January 15, 2003
2003年1月15日
Identifier uniqueness considerations:
識別子ユニークさの問題:
Identifiers are assigned by the Liberty Project within its various
standards. In the process of publishing a specification all newly
minted names are checked against the record of previously assigned
names.
識別子は様々な規格の中で自由計画によって割り当てられます。 仕様を発表することの途中に、すべての新たに造幣された名前が記録に対してチェックされます。
Identifier persistence considerations:
識別子固執問題:
The assignment process guarantees that names are not reassigned
and that the binding between the name and its resource is
permanent, regardless of any standards or organizational changes.
課題の過程は名前が再選任されないで、名前とそのリソースの間の結合が永久的であることを保証します、どんな規格や組織変動にかかわらず。
Process of identifier assignment:
識別子課題の過程:
Names are assigned by the Liberty standards publication process.
名前はリバティ規格公表工程で割り当てられます。
Process of identifier resolution:
識別子解決の過程:
At this time no resolution mechanism is specified.
このとき、解決メカニズムは全く指定されません。
Rules for Lexical Equivalence:
語彙等価性のための規則:
Lexical equivalence of two Liberty namespace specific strings
(NSSs) is defined as an exact, case-sensitive string match. The
Liberty Alliance will assign names of immediately subordinate
2個のリバティの名前空間の特定のストリング(NSSs)の語彙等価性は正確で、大文字と小文字を区別するストリングマッチと定義されます。 リバティAllianceはすぐにの名前に部下を選任するでしょう。
Mealling Informational [Page 3] RFC 3622 The Liberty URN Namespace February 2004
自由つぼの名前空間2004年2月に情報[3ページ]のRFC3622を荒びきにします。
naming authorities in a case-insensitive fashion, so that there
will not be two Liberty-subordinate naming authorities whose names
differ only in case.
名前が場合だけにおいて異なる2つのリバティ下位の命名当局がないように、大文字と小文字を区別しないファッションで当局を任命します。
Conformance with URN Syntax:
つぼの構文との順応:
There are no additional characters reserved.
予約された添字が全くありません。
Validation mechanism:
合法化メカニズム:
None other than verifying with the correct Liberty specifications.
まさしく、正しいリバティと共に仕様を確かめます。
Scope:
範囲:
Global
グローバル
3. IANA Considerations
3. IANA問題
This document includes a URN Namespace registration that has been entered into the IANA registry for URN NIDs.
このドキュメントはURN NIDsのためにIANA登録に入れられたURN Namespace登録を含んでいます。
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.
この名前空間のための解決メカニズムが全くない間、名前自体はリバティ仕様の公共の実現に使用されます。 事情がリバティシステムからの物が一般的なインターネットに露出されるようになるところにあります。 これらの場合では、リバティ名前空間の使用は全体のインターネットへの一般的な相互運用性利益を提供するでしょう。 さらに、他の規格によって採用されるかもしれないリバティ仕様のサブコンポーネントがあるかもしれません、そして、その場合、URNsは以前はよくそれらのコンポーネントを特定していました、そして、他の、そして、非自由に基づいているシステムを機能アップするのに容易に仕様は使用できます。
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.
リバティURNsのための定義された解決メカニズムが全くないので、与えられた名前空間が実際に規格を固く守って、その結果、アプリケーションがそれが何を送るかが実際のURNが割り当てられることを固く守るという何らかの非検証されたソース主張を取らないように注意しているべきであるという事実を認証するのは難しいです。
Mealling Informational [Page 4] RFC 3622 The Liberty URN Namespace February 2004
自由つぼの名前空間2004年2月に情報[4ページ]のRFC3622を荒びきにします。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Moats, R., "URN Syntax", RFC 2141, May 1997.
[1]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[2]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、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] ホッジズとJ.とT.ワトソン、「リバティ構造概観」、リバティ1.1、2003年1月、<は://www.projectliberty.org/仕様/自由構造概観-v1.1.pdfをhttpします。>。
6.2. Informative References
6.2. 有益な参照
[4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[4] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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]ロバの鳴き声、T.、パオリ、J.、Sperberg-マックィーン、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>.
「XMLの名前空間」という[6]ロバの鳴き声、T.、オランダ人、D.、およびA.Laymanは1999年1月に<http://www.w3.org/TR/REC-xml名を>にW3C REC-xml挙げます。
[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] トンプソン、H.、ぶな、D.、マローニー、M.、およびN.メンデルゾーン、「XML図式第1部:」 「構造」(W3C REC-xmlschema-1)は2001、<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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
Mealling Informational [Page 5] RFC 3622 The Liberty URN Namespace February 2004
自由つぼの名前空間2004年2月に情報[5ページ]のRFC3622を荒びきにします。
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
ベリサインInc.21345屋根の頂円のヴァージニア20166ダレス(米国)を荒びきにするマイケル
Phone: +1 678 581 9656 EMail: michael@neonym.net URI: http://www.verisignlabs.com
以下に電話をしてください。 +1 9656年の678 581メール: michael@neonym.net ユリ: http://www.verisignlabs.com
Mealling Informational [Page 6] RFC 3622 The Liberty URN Namespace February 2004
自由つぼの名前空間2004年2月に情報[6ページ]のRFC3622を荒びきにします。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 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 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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Mealling Informational [Page 7]
食事情報です。[7ページ]
一覧
スポンサーリンク
