Network Working Group D. Tessman
Request for Comments: 4198 Zelestra
Category: Informational November 2005
Network Working Group D. Tessman
Request for Comments: 4198 Zelestra
Category: Informational November 2005
A Uniform Resource Name (URN) Namespace for Federated Content
联合内容的统一资源名称（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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（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（统一资源名称）命名空间，用于标识联合内容集合中的内容资源。联合内容集合通常没有强大的集中式权限，但依赖共享命名、元数据和访问约定来提供其成员之间的互操作性。
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在没有强大的内容命名权限的情况下工作良好，但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.
此名称空间规范适用于正式名称空间。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中的说明进行解释。
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号，邮编：91214-3007
Contact: Dave Tessman E-mail: dtessman@zelestra.com
联系人：Dave 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*(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)
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
hex = DIGIT / %x41-46 / %x61-66
other = "(" / ")" / "+" / "," / "-" / "." / ":" / "=" /
"@" / ";" / "$" / "_" / "!" / "*" / "'"
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必须是Internet域名，并且必须由创建资源并将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位的日期ID。
ResourceId MUST be unique among all ResourceIds emanating from the same provider and having the same DateId.
ResourceId在来自同一提供程序且具有相同DateId的所有ResourceId中必须是唯一的。
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只能由拥有Internet域名的组织分配。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组合标识的组织负责分配一个ResourceId，该ResourceId在其使用该日期ID分配的所有资源中是唯一的。
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.
内容提供商负责为其分配了有效ProviderId/DateId组合的URN提供URN解析服务（如果有）。
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.
内容提供商应使用RFC 2169[3]中描述的HTTP协议约定支持URN解析。ProviderId应用作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.
除了RFC 2141[4]中定义的规则外，在比较之前，将ProviderId的大小写规范化为小写。
Conformance with URN Syntax:
符合URN语法：
There are no additional characters reserved.
没有保留其他字符。
Validation mechanism:
验证机制：
None additional to resolution specified.
除指定的分辨率外，没有其他分辨率。
Scope:
范围：
Global
全球的
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
There are no additional security considerations other than those normally associated with the use and resolution of URNs in general.
除了通常与使用和解决骨灰盒相关的安全注意事项外，没有其他安全注意事项。
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需求的独特而有价值的工具。
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部分，以满足其内部内容标识需求，并建立内部治理机制，以确保创建的所有标识符都符合此命名空间的要求。还建议在由命名空间语法结构的ProviderId部分指定的HTTP服务器内提供RFC 2169[3]中描述的标识符解析机制。
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注册，并已输入URN NID的IANA注册。
Normative References
规范性引用文件
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[3] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[3] Daniel，R.，“在URN解析中使用HTTP的简单约定”，RFC 2169，1997年6月。
[4] Moats, R., "URN Syntax", RFC 2141, May 1997.
[4] 护城河，R.，“瓮语法”，RFC 21411997年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.，van 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
戴夫·泰斯曼·泽莱斯特拉美国加利福尼亚州克雷森塔市亨利埃塔大道2314号，邮编：91214-3007
Phone: +1 818 249 8906
EMail: dtessman@zelestra.com
Phone: +1 818 249 8906
EMail: dtessman@zelestra.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。