Network Working Group H. Van de Sompel
Request for Comments: 4452 LANL
Category: Informational T. Hammond
NPG
E. Neylon
Manifest Solutions
S. Weibel
OCLC
April 2006
Network Working Group H. Van de Sompel
Request for Comments: 4452 LANL
Category: Informational T. Hammond
NPG
E. Neylon
Manifest Solutions
S. Weibel
OCLC
April 2006
The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces
在公共名称空间中具有标识符的信息资产的“info”URI方案
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces. Namespaces participating in the "info" URI scheme are regulated by an "info" Registry mechanism.
本文档为在公共名称空间中具有标识符的信息资产定义了“信息”统一资源标识符（URI）方案。参与“info”URI方案的名称空间由“info”注册表机制管理。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Information Assets .........................................3
2. Application of the "info" URI Scheme ............................4
3. The "info" Registry .............................................5
3.1. Management Characteristics of the "info" Registry ..........5
3.2. Functional Characteristics of the "info" Registry ..........5
3.3. Maintenance of the "info" Registry .........................6
4. The "info" URI Scheme ...........................................6
4.1. Definition of "info" URI Syntax ............................6
4.2. Allowed Characters Under the "info" URI Scheme .............8
4.3. Examples of "info" URIs ....................................9
5. Normalization and Comparison of "info" URIs ....................10
6. Rationale ......................................................12
6.1. Why Create a New URI Scheme for Identifiers from Public
Namespaces? ...............................................12
6.2. Why Not Use an Existing URI Scheme for Identifiers
from Public Namespaces? ...................................12
6.3. Why Not Create a New URN Namespace ID for
Identifiers from Public Namespaces? .......................12
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Information Assets .........................................3
2. Application of the "info" URI Scheme ............................4
3. The "info" Registry .............................................5
3.1. Management Characteristics of the "info" Registry ..........5
3.2. Functional Characteristics of the "info" Registry ..........5
3.3. Maintenance of the "info" Registry .........................6
4. The "info" URI Scheme ...........................................6
4.1. Definition of "info" URI Syntax ............................6
4.2. Allowed Characters Under the "info" URI Scheme .............8
4.3. Examples of "info" URIs ....................................9
5. Normalization and Comparison of "info" URIs ....................10
6. Rationale ......................................................12
6.1. Why Create a New URI Scheme for Identifiers from Public
Namespaces? ...............................................12
6.2. Why Not Use an Existing URI Scheme for Identifiers
from Public Namespaces? ...................................12
6.3. Why Not Create a New URN Namespace ID for
Identifiers from Public Namespaces? .......................12
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets that have identifiers in public namespaces but are not part of the URI allocation. By "information asset" this document intends any information construct that has identity within a public namespace.
本文档为在公共名称空间中具有标识符但不属于URI分配的信息资产定义了“信息”统一资源标识符（URI）方案。通过“信息资产”，本文档打算使用在公共名称空间中具有标识的任何信息构造。
In this document, the keywords "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", "MAY NOT", and "RECOMMENDED" are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“应”、“不应”、“应”、“不应”、“可”、“不可”和“建议”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合性实施的要求级别。
There exist many information assets with identifiers in public namespaces that are not referenceable by URI schemes. Examples of such namespaces include Dewey Decimal Classifications [DEWEY], Library of Congress Control Numbers [LCCN], NISO Serial Item and Contribution Identifiers [SICI], NASA Astrophysics Data System Bibcodes [BIBCODE], and National Library of Medicine PubMed identifiers [PMID]. Other candidate namespaces include Online Computer Library Center OCLC Numbers [OCLCNUM] and NISO OpenURL Framework identifiers [OFI].
在公共名称空间中存在许多标识符不可由URI方案引用的信息资产。此类名称空间的示例包括杜威十进制分类[Dewey]、国会图书馆控制号[LCCN]、NISO序列项目和贡献标识符[SICI]、NASA天体物理数据系统Bibcodes[BIBCODE]和国家医学图书馆公共标识符[PMID]。其他候选名称空间包括在线计算机图书馆中心OCLC编号[OCLCNUM]和NISO OpenURL框架标识符[OFI]。
The "info" URI scheme facilitates the referencing of information assets that have identifiers in such public namespaces by means of URIs. When referencing an information asset by means of its "info" URI, the asset SHALL be considered a "resource" as defined in RFC 3986 [RFC3986] and SHALL enjoy the same common syntactic, semantic, and shared language benefits that the URI presentation confers. As such, the "info" URI scheme enables public namespaces that are not part of the URI allocation to be represented within the allocation. The "info" URI scheme thus provides a bridging mechanism to allow public namespaces to become part of the URI allocation.
“info”URI方案有助于通过URI引用在此类公共名称空间中具有标识符的信息资产。当通过“信息”URI引用信息资产时，该资产应被视为RFC 3986[RFC3986]中定义的“资源”，并应享有URI表示所赋予的相同的通用语法、语义和共享语言优势。因此，“info”URI方案允许在分配中表示不属于URI分配的公共名称空间。因此，“info”URI方案提供了一种桥接机制，允许公共名称空间成为URI分配的一部分。
Namespaces declared under the "info" URI scheme are regulated by an "info" Registry mechanism. The "info" Registry allows a public namespace that is not part of the URI allocation to be declared in a registration process by the organization that manages it (the Namespace Authority). The "info" Registry supports the declaration of public namespaces that are not part of the URI allocation in a manner that facilitates the construction of URIs for information assets without imposing the burdens of independent URI registration and maintenance of resource representations on the Namespace Authority. Information assets identified within a registered
在“info”URI方案下声明的名称空间由“info”注册表机制管理。“info”注册表允许管理它的组织（名称空间管理机构）在注册过程中声明不属于URI分配的公共名称空间。“info”注册表支持声明不属于URI分配的公共名称空间，其方式有助于为信息资产构建URI，而不会将独立URI注册和维护资源表示的负担强加给名称空间管理机构。在注册数据库中识别的信息资产
namespace SHALL be added or deleted according to the business processes of the Namespace Authority, and yet MAY be referenced within network applications via the "info" URI in an open, standardized way without additional action on the part of the Namespace Authority.
名称空间应根据名称空间管理机构的业务流程进行添加或删除，但可以通过“信息”URI以开放、标准化的方式在网络应用程序中引用，而无需名称空间管理机构采取额外行动。
The "info" URI scheme exists primarily for identification purposes. Implementations MUST NOT assume that an "info" URI can be dereferenced to a representation of the resource identified by the URI although Namespace Authorities MAY disclose in the registration record references to service mechanisms pertaining to identifiers from the registered namespace. Applications of the "info" URI scheme are restricted to the identification of information assets and the declaration of normalization rules for comparing identifiers of such information assets regardless of whether any services relating to such information assets are accessible via the Internet. References to such services MAY be disclosed within an "info" registration record, but these services SHALL NOT be regarded as authoritative. The "info" URI scheme does not support global resolution methods.
“info”URI方案主要用于识别目的。实现决不能假定“info”URI可以与URI标识的资源表示解除引用，尽管名称空间管理机构可以在注册记录中披露与来自注册名称空间的标识符相关的服务机制的引用。“info”URI方案的应用仅限于识别信息资产和声明用于比较此类信息资产标识符的规范化规则，而不管是否可以通过互联网访问与此类信息资产相关的任何服务。可在“信息”登记记录中披露对此类服务的引用，但这些服务不应被视为具有权威性。“info”URI方案不支持全局解析方法。
Public namespaces that are used for the identification of information assets and that are not part of the URI allocation MAY be registered as namespaces within the "info" Registry. Namespace Authorities MAY register these namespaces in the "info" Registry, thereby making these namespaces available to applications that need to reference information assets by means of a URI. Registrations of public namespaces that are not part of the URI allocation by parties other than the Namespace Authority SHALL NOT be permitted, thereby ensuring against hostile usurpation or inappropriate usage of registered service marks or the public namespaces of others.
用于标识信息资产且不属于URI分配的公共名称空间可以注册为“info”注册表中的名称空间。命名空间授权机构可以在“info”注册表中注册这些命名空间，从而使需要通过URI引用信息资产的应用程序可以使用这些命名空间。不允许名称空间管理机构以外的各方注册不属于URI分配的公共名称空间，从而防止恶意篡夺或不当使用已注册服务标记或其他方的公共名称空间。
Registration of a public namespace under the "info" Registry implies no particular functionalities of the identifiers from the registered namespace other than the identification of information assets. No resolution mechanisms can be assumed for the "info" URI scheme, though for any particular namespace there MAY exist mechanisms for resolving identifiers to network services. The definition of such services falls outside the scope of the "info" URI scheme. Registration does not define namespace-specific semantics for identifiers within a registered namespace, though allowable character sets and normalization rules are specified in Sections 4 and 5 so as to ensure that the URIs created using such identifiers are compliant with applications that use URIs.
在“info”注册表下注册公共名称空间并不意味着注册名称空间中的标识符除了标识信息资产之外没有其他特殊功能。不能为“info”URI方案假设任何解析机制，尽管对于任何特定名称空间，可能存在将标识符解析为网络服务的机制。此类服务的定义不属于“info”URI方案的范围。注册并没有为注册名称空间中的标识符定义特定于名称空间的语义，尽管第4节和第5节规定了允许的字符集和规范化规则，以确保使用此类标识符创建的URI与使用URI的应用程序兼容。
The registration of a public namespace in the "info" Registry SHALL NOT preclude further development of services associated with that namespace that MAY qualify the namespace for additional publication elsewhere within the URI allocation.
在“info”注册表中注册公共名称空间不应妨碍进一步开发与该名称空间相关的服务，这些服务可能使该名称空间有资格在URI分配的其他地方进行额外发布。
The "info" Registry provides a mechanism for the registration of public namespaces that are used for the identification of information assets and that are not part of the URI allocation.
“info”注册表提供了一种注册公共名称空间的机制，这些名称空间用于标识信息资产，不属于URI分配的一部分。
NISO [NISO], the National Information Standards Organization, will act as the Maintenance Agency for the "info" Registry and will delegate the day-to-day operation of the "info" Registry to a Registry Operator. As the Maintenance Agency, NISO will ensure that the Registry Operator operates the "info" Registry in accordance with a publicly articulated policy document established under NISO governance and made available on the "info" website, <http://info-uri.info/>. The "info" Registry policy defines a review process for candidate namespaces and provides measures of quality control and suitability for entry of namespaces.
国家信息标准组织NISO（NISO）将作为“信息”登记册的维护机构，并将“信息”登记册的日常操作委托给登记册运营商。作为维护机构，NISO将确保注册运营商按照NISO管理下制定的公开政策文件运营“信息”注册，并在“信息”网站上公布<http://info-uri.info/>. “info”注册表策略定义了候选名称空间的审查过程，并提供了质量控制措施和名称空间输入的适用性。
The "info" Registry will be managed according to policies established under the auspices of NISO. All such policies, as well as the namespace declarations in the "info" Registry, will be public.
“信息”登记处将根据NISO主持下制定的政策进行管理。所有此类策略以及“info”注册表中的命名空间声明都将是公共的。
The "info" Registry will be publicly accessible and will support discovery (by both humans and machines) of:
“信息”注册表将可公开访问，并将支持（由人和机器）发现：
o string literals identifying the namespaces for which the Registry provides a guarantee of uniqueness and persistence o names and contact information of Namespace Authorities o syntax requirements for identifiers maintained in such namespaces o normalization methodologies for identifiers maintained in such namespaces o network references to a description of service mechanisms (if any) for identifiers maintained in such namespaces o ancillary documentation
o 标识名称空间的字符串文字，注册中心为其提供唯一性和持久性保证o名称空间机构的名称和联系信息o此类名称空间中维护的标识符的语法要求o此类名称空间中维护的标识符的规范化方法o对在此类名称空间或辅助文档中维护的标识符的服务机制（如有）说明
Registry entries refer to the corresponding "namespace" and "identifier" components, which are defined in the ABNF given in Section 4.1 of this document.
注册表项指的是相应的“名称空间”和“标识符”组件，它们在本文件第4.1节给出的ABNF中定义。
The public namespaces that MAY be registered in the "info" Registry will be those of interest to the communities served by NISO, and therefore NISO is committed to act as Maintenance Authority for the "info" Registry and to assign a Registry Operator to operate it.
可能在“info”注册表中注册的公共名称空间将是NISO服务的社区感兴趣的名称空间，因此NISO承诺充当“info”注册表的维护机构，并指定一名注册表操作员来操作它。
NISO, a non-profit association accredited by the American National Standards Institute (ANSI), identifies, develops, maintains, and publishes technical standards to manage information in the digital environment. NISO standards apply technologies to the full range of information-related needs, including retrieval, re-purposing, storage, metadata, and preservation.
NISO是一个由美国国家标准协会（ANSI）认可的非营利组织，负责识别、开发、维护和发布技术标准，以管理数字环境中的信息。NISO标准将技术应用于与信息相关的所有需求，包括检索、重新定位、存储、元数据和保存。
Founded in 1939, incorporated as a not-for-profit education association in 1983, and assuming its current name the following year, NISO draws its support from the communities it serves. The leaders of over 70 organizations in the fields of publishing, libraries, IT, and media serve as its voting members. Hundreds of experts and practitioners serve on NISO committees and as officers of the association.
NISO成立于1939年，1983年成立为非营利教育协会，第二年更名为NISO，它得到了所服务社区的支持。来自出版、图书馆、IT和媒体领域的70多个组织的领导人担任其投票成员。数百名专家和从业人员在NISO委员会任职，并担任协会的官员。
NISO has been designated by ANSI to represent US interests to the International Organization for Standardization's (ISO) Technical Committee 46 on Information and Documentation.
NISO已被ANSI指定为代表美国在国际标准化组织（ISO）信息和文件技术委员会46中的利益。
The NISO headquarters office is located at 4733 Bethesda Ave., Bethesda, MD 20814, USA. (For further information, see the NISO website, <http://www.niso.org/>.)
NISO总部办公室位于美国马里兰州贝塞斯达贝塞斯达大道4733号，邮编20814。（有关更多信息，请参阅NISO网站<http://www.niso.org/>.)
The "info" URI syntax presented in this document is conformant with the generic URI syntax defined in RFC 3986 [RFC3986]. This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC 4234 [RFC4234] to define the URI. The following core ABNF productions are used by this specification as defined by Appendix B.1 of RFC 4234: ALPHA, DIGIT, HEXDIG.
本文档中的“info”URI语法与RFC 3986[RFC3986]中定义的通用URI语法一致。本规范使用RFC 4234[RFC4234]的增广巴科斯诺尔形式（ABNF）表示法来定义URI。根据RFC 4234附录B.1的定义，本规范使用了以下核心ABNF产品：α、数字、HEXDIG。
The "info" URI syntax is presented in two parts. Part A contains productions specific to the "info" URI scheme, while Part B contains generic productions from RFC 3986 [RFC3986], which are repeated here both for completeness and for reference. The following set of productions (Part A) is specific to the "info" URI scheme:
“info”URI语法分为两部分。A部分包含特定于“info”URI方案的产品，而B部分包含来自RFC 3986[RFC3986]的通用产品，为了完整性和参考，这里重复这些产品。以下一组产品（A部分）特定于“info”URI方案：
; Part A: ; productions specific to the "info" URI scheme
; A部分：；特定于“info”URI方案的产品
info-URI = info-scheme ":" info-identifier [ "#" fragment ]
info-URI = info-scheme ":" info-identifier [ "#" fragment ]
info-scheme = "info"
info-scheme = "info"
info-identifier = namespace "/" identifier
信息标识符=名称空间“/”标识符
namespace = scheme
namespace = scheme
identifier = *( pchar / "/" )
identifier = *( pchar / "/" )
; Note that "info" URIs containing dot-segments (i.e., segments
; whose full content consists of "." or "..") MAY NOT be suitable
; for use with applications that perform dot-segment normalization
; Note that "info" URIs containing dot-segments (i.e., segments
; whose full content consists of "." or "..") MAY NOT be suitable
; for use with applications that perform dot-segment normalization
This next set of productions (Part B) are generic productions reproduced from RFC 3986 [RFC3986]:
下一组产品（B部分）是从RFC 3986[RFC3986]复制的通用产品：
; Part B: ; generic productions from RFC 3986 [RFC3986]
; B部分：；RFC 3986[RFC3986]的通用产品
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
fragment = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
pct编码=“%”HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
An "info" URI has an "info-identifier" as its scheme-specific part
and MAY take an optional "fragment" component. An "info-identifier"
is constructed by appending an "identifier" component to a
"namespace" component separated by a slash "/" character. The "info"
URI scheme is supportive of hierarchical processing as indicated by
the presence of the slash "/" character, although the slash "/"
character SHOULD NOT be interpreted as a strict hierarchy delimiter.
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
An "info" URI has an "info-identifier" as its scheme-specific part
and MAY take an optional "fragment" component. An "info-identifier"
is constructed by appending an "identifier" component to a
"namespace" component separated by a slash "/" character. The "info"
URI scheme is supportive of hierarchical processing as indicated by
the presence of the slash "/" character, although the slash "/"
character SHOULD NOT be interpreted as a strict hierarchy delimiter.
Values for the "namespace" component of the "info" URI are name tokens composed of URI scheme characters only (cf. the "scheme" production). They identify the public namespace in which the (unescaped) value for the "identifier" component originates, and are registered in the "info" Registry, which guarantees their uniqueness
“info”URI的“namespace”组件的值是仅由URI模式字符组成的名称标记（参见“scheme”产品）。它们标识“identifier”组件的（unscaped）值起源于的公共名称空间，并在“info”注册表中注册，这保证了它们的唯一性
and persistence. Although the "namespace" component is case-insensitive, the canonical form is lowercase and documents that specify values for the "namespace" component SHOULD do so using lowercase letters. An implementation SHOULD accept uppercase letters as equivalent to lowercase in "namespace" names, for the sake of robustness, but SHOULD only generate lowercase "namespace" names, for consistency.
还有毅力。尽管“namespace”组件不区分大小写，但规范形式是小写的，为“namespace”组件指定值的文档应该使用小写字母。为了稳健性起见，实现应该将大写字母视为“名称空间”名称中的小写字母，但为了一致性，应该只生成小写的“名称空间”名称。
Values for the "identifier" component of the "info" URI MAY be viewed as being hierarchical strings composed of path segments built from path segment characters (cf. the "pchar" production), the segments being separated by slash "/" characters, although any semantic interpretation of the "/" character as a hierarchy delimiter MUST NOT be assumed. In their originating public namespace, the (unescaped) values for the "identifier" component identify information assets. The values for the "identifier" component MUST be %-escaped as required by this syntax. The "identifier" component SHOULD be treated as case-sensitive, although the "info" Registry MAY record the case-sensitivity of identifiers from particular registered public namespaces. The "info" Registry MAY also disclose additional normalization rules regarding the treatment of punctuation characters and the like.
“info”URI的“identifier”组件的值可被视为由路径段字符（参见“pchar”产品）构建的路径段组成的分层字符串，这些段由斜杠“/”字符分隔，尽管不能假设“/”字符作为分层定界符的任何语义解释。在它们的原始公共名称空间中，“标识符”组件的（未缩放）值标识信息资产。“标识符”组件的值必须按照此语法的要求进行转义。“identifier”组件应视为区分大小写，尽管“info”注册表可能会记录来自特定已注册公共名称空间的标识符的区分大小写。“info”注册表还可以公开关于标点符号等的处理的附加规范化规则。
Values for the "fragment" component of the "info" URI are strings composed of path segment characters (cf. the "pchar" production) plus the slash "/" character and the question mark "?" character. No semantic role is assigned to the slash "/" character and the question mark "?" character within the "fragment" component. The (unescaped) values for the "fragment" component identify secondary information assets with respect to the primary information asset, which is referenced by the "info-identifier". The values for the "fragment" component MUST be %-escaped as required by this syntax. The "fragment" component MUST be treated as being case-sensitive.
“info”URI的“fragment”组件的值是由路径段字符（参见“pchar”产品）加上斜杠“/”字符和问号“？”字符组成的字符串。没有为“片段”组件中的斜杠“/”字符和问号“？”字符分配语义角色。“片段”组件的（未缩放的）值相对于主信息资产标识辅助信息资产，主信息资产由“信息标识符”引用。“fragment”组件的值必须按照此语法的要求进行转义。“片段”组件必须视为区分大小写。
The "info" URI syntax uses the same set of allowed US-ASCII characters as specified in RFC 3986 [RFC3986] for a generic URI. An "info" URI string SHOULD be represented as a Unicode [UNICODE] string and be encoded in UTF-8 [RFC3629] form. Reserved characters as well as excluded US-ASCII characters and non-US-ASCII characters MUST be %-escaped before forming the URI. Details of the %-escape encoding can be found in RFC 3986 [RFC3986], Section 2.4.
“info”URI语法使用RFC 3986[RFC3986]中为通用URI指定的同一组允许的US-ASCII字符。“info”URI字符串应表示为Unicode[Unicode]字符串，并以UTF-8[RFC3629]形式进行编码。在形成URI之前，必须对保留字符、排除的US-ASCII字符和非US ASCII字符进行转义。转义编码的详细信息可在RFC 3986[RFC3986]第2.4节中找到。
Some examples of syntactically valid "info" URIs are given below:
下面给出了语法上有效的“info”URI的一些示例：
a) info:ddc/22/eng//004.678
a) info:ddc/22/eng//004.678
where "ddc" is the "namespace" component for a Dewey Decimal Classification [DEWEY] namespace and "22/eng//004.678" is the "identifier" component for an identifier of an information asset within that namespace.
其中，“ddc”是杜威十进制分类[Dewey]名称空间的“名称空间”组件，“22/eng//004.678”是该名称空间内信息资产标识符的“标识符”组件。
The information asset identified by the identifier "22/eng//004.678" in the namespace for (22nd Ed.) English-language Dewey Decimal Classifications is the classification
英语杜威十进制分类名称空间中标识符“22/eng//004.678”标识的信息资产为分类
"Internet"
“互联网”
b) info:lccn/2002022641
b) 资料：lccn/2002022641
where "lccn" is the "namespace" component for a Library of Congress Control Number [LCCN] namespace and "2002022641" is the "identifier" component for an identifier of an information asset within that namespace.
其中，“lccn”是国会图书馆控制编号[lccn]命名空间的“命名空间”组件，“2002022641”是该命名空间内信息资产标识符的“标识符”组件。
The information asset identified by the identifier "2002022641" in the namespace for Library of Congress Control Numbers is the metadata record
由国会图书馆控制号命名空间中的标识符“2002022641”标识的信息资产是元数据记录
"Newcomer, Eric. Understanding Web services: XML, WSDL, SOAP, and UDDI. Boston: Addison-Wesley, 2002."
“新来者，Eric。理解Web服务：XML、WSDL、SOAP和UDDI。波士顿：Addison-Wesley，2002。”
c) info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V
c) info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V
where "sici" is the "namespace" component for a Serial Item and Contribution Identifier [SICI] namespace and "0363-0277(19950315)120:5%3C%3E1.0.TX;2-V" is the "identifier" component for an identifier of an information asset in that namespace in %-escaped form, or in unescaped form "0363-0277(19950315)120:5<>1.0.TX;2-V".
其中，“sici”是序列项和贡献标识符[sici]名称空间的“名称空间”组件，“0363-0277（19950315）120:5%3C%3E1.0.TX；2-V”是该名称空间中以%转义形式或未转义形式“0363-0277（19950315）120:5<>1.0.TX；2-V”的信息资产标识符的“标识符”组件。
The information asset identified by the identifier
"0363-0277(19950315)120:5<>1.0.TX;2-V" in the namespace for Serial
Item and Contribution Identifiers is the journal issue
The information asset identified by the identifier
"0363-0277(19950315)120:5<>1.0.TX;2-V" in the namespace for Serial
Item and Contribution Identifiers is the journal issue
"Library Journal, Vol. 120, no. 5. March 15, 1995."
《图书馆期刊》，第120卷，第5期，1995年3月15日
d) <rdf:Description about="info:bibcode/2003Icar..163..263Z"/>
d) <rdf:Description about="info:bibcode/2003Icar..163..263Z"/>
where "bibcode" is the "namespace" component for a NASA Astrophysics Data System (ADS) Bibcode [BIBCODE] namespace and "2003Icar..163..263Z" is the "identifier" component for an identifier of an information asset within that namespace. This example further shows an application of an "info" URI as the subject of a Resource Description Framework (RDF) statement.
其中，“bibcode”是NASA天体物理数据系统（ADS）bibcode[bibcode]名称空间的“名称空间”组件，“2003Icar..163..263Z”是该名称空间内信息资产标识符的“标识符”组件。该示例进一步显示了“info”URI作为资源描述框架（RDF）语句主题的应用程序。
The information asset identified by the identifier "2003Icar..163..263Z" in the namespace for NASA ADS Bibcodes is the metadata record in the ADS system that describes the journal article
NASA ADS Bibcodes名称空间中标识符“2003Icar..163..263Z”标识的信息资产是ADS系统中描述期刊文章的元数据记录
"K. Zahnle, P. Schenk, H. Levison and L. Dones, Cratering rates in the outer Solar System, Icarus, 163 (2003) pp. 263-289."
“K.Zahnle，P.Schenk，H.Levison和L.Dones，《外太阳系的陨石坑形成率》，伊卡洛斯，163（2003）第263-289页。”
e) info:pmid/12376099
e) 信息：pmid/12376099
where "pmid" is the "namespace" component for a PubMed Identifier [PMID] namespace and "12376099" is the "identifier" component for an identifier of an information asset in that namespace.
其中，“pmid”是PubMed标识符[pmid]命名空间的“命名空间”组件，“12376099”是该命名空间中信息资产标识符的“标识符”组件。
The information asset identified by the identifier "12376099" in the namespace for PubMed Identifiers is the metadata record in the PubMed database that describes the journal article
PubMed标识符名称空间中由标识符“12376099”标识的信息资产是PubMed数据库中描述期刊文章的元数据记录
"Wijesuriya SD, Bristow J, Miller WL. Localization and analysis of the principal promoter for human tenascin-X. Genomics. 2002 Oct;80(4):443-52."
“Wijesuriya SD，Bristow J，Miller WL.人类tenascin-X主要启动子的定位和分析.基因组学.2002年10月；80（4）：443-52。”
In order to facilitate comparison of "info" URIs, a sequence of normalization steps SHOULD be applied as detailed below. After normalizing the URI strings, comparison of two "info" URIs is then applied on a character-by-character basis as prescribed by RFC 3986 [RFC3986], Section 6.2.1.
为了便于比较“信息”URI，应采用一系列规范化步骤，如下所述。规范化URI字符串后，按照RFC 3986[RFC3986]第6.2.1节的规定，逐字符应用两个“信息”URI的比较。
The following generic normalization steps SHOULD anyway be applied by applications processing "info" URIs:
处理“信息”URI的应用程序无论如何都应应用以下通用规范化步骤：
a) Normalize the case of the "scheme" component to be lowercase b) Normalize the case of the "namespace" component to be lowercase c) Unescape all unreserved %-escaped characters in the "namespace" and "identifier" components
a) 将“scheme”组件的大小写规范化为小写b）将“namespace”组件的大小写规范化为小写c）取消对“namespace”和“identifier”组件中所有未保留的转义字符的scape
d) Normalize the case of any %-escaped characters in the "namespace" and "identifier" components to be uppercase
d) 将“名称空间”和“标识符”组件中任何转义字符的大小写规范化为大写
Further normalization steps MAY be applied by applications to "info" URIs based on rules recorded in the "info" Registry for a registered public namespace, but such normalization steps remain outside of the scope of the "info" URI definition.
应用程序可以根据注册的公共名称空间的“info”注册表中记录的规则，对“info”URI应用进一步的规范化步骤，但此类规范化步骤仍在“info”URI定义的范围之外。
Since the "info" URI SHOULD be treated as being case-sensitive, a canonical form MAY only be arrived at by consulting the "info" Registry for possible information on the case-sensitivity for identifiers from a registered public namespace, and any case normalization step to apply. The "info" Registry MAY also disclose additional normalization rules regarding the treatment of punctuation characters and the like.
由于“info”URI应视为区分大小写，因此只有通过咨询“info”注册中心，获取有关注册公共名称空间中标识符的区分大小写的可能信息，以及要应用的任何大小写规范化步骤，才能获得规范形式。“info”注册表还可以公开关于标点符号等的处理的附加规范化规则。
In cases, however, where no single canonical form of the "identifier" component exists, it is nevertheless RECOMMENDED that a Namespace Authority nominate a preferred form, which SHOULD be used wherever possible within an "info" URI so that applications MAY have an increased chance of successful comparison of two "info" URIs.
但是，在“标识符”组件不存在单一规范形式的情况下，建议命名空间管理机构指定一种首选形式，该形式应尽可能在“信息”URI中使用，以便应用程序可以增加成功比较两个“信息”URI的机会。
Note that "info" URIs containing dot-segments (i.e., segments whose full content consists of "." or "..") MAY NOT be suitable for use with applications that perform dot-segment normalization.
请注意，包含点段（即，其完整内容由“.”或“.”组成的段）的“信息”URI可能不适合用于执行点段规范化的应用程序。
The following unnormalized forms of an "info" URI
“info”URI的以下非规范化形式
U1. INFO:PII/S0888-7543(02)96852-7
U2. info:PII/S0888754302968527
U3. info:pii/S0888%2D7543%2802%2996852%2D7
U4. info:pii/s0888-7543(02)96852-7
U1. INFO:PII/S0888-7543(02)96852-7
U2. info:PII/S0888754302968527
U3. info:pii/S0888%2D7543%2802%2996852%2D7
U4. info:pii/s0888-7543(02)96852-7
are normalized to the following respective forms
标准化为以下各自的形式
N1. info:pii/S0888-7543(02)96852-7
N2. info:pii/S0888754302968527
N3. info:pii/S0888-7543(02)96852-7
N4. info:pii/s0888-7543(02)96852-7
N1. info:pii/S0888-7543(02)96852-7
N2. info:pii/S0888754302968527
N3. info:pii/S0888-7543(02)96852-7
N4. info:pii/s0888-7543(02)96852-7
The "info" URI definition does not prescribe further normalization steps, although applications MAY apply additional normalization steps according to any rules recorded in the "info" Registry for a registered public namespace.
“info”URI定义没有规定进一步的规范化步骤，尽管应用程序可以根据“info”注册表中记录的任何规则为注册的公共名称空间应用额外的规范化步骤。
6.1. Why Create a New URI Scheme for Identifiers from Public Namespaces?
6.1. 为什么要为来自公共名称空间的标识符创建新的URI方案？
Under RFC 4395, "Guidelines and Registration Procedures for New URI Schemes" [RFC4395], it is stated in Section 2.1 "Demonstrable, New, Long-Lived Utility" that "New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes". The "info" URI scheme allows identifiers within public namespaces, used for the identification of information assets, to be referred to within the URI allocation. Once a namespace is registered in the "info" Registry, the "info" URI scheme enables an information asset with an identifier in that namespace to be referenced by means of a URI. As a result, the information asset SHALL be considered a resource as defined in RFC 3986 [RFC3986] and SHALL enjoy the same common syntactic, semantic, and shared language benefits that the URI presentation confers.
根据RFC 4395“新URI方案的指南和注册程序”[RFC4395]，第2.1节“可证明的、新的、长寿命的实用程序”中规定，“新URI方案对广泛的互联网社区应具有明确的实用程序，超出已注册的URI方案的可用功能”。“info”URI方案允许在URI分配中引用公共名称空间中用于标识信息资产的标识符。一旦在“info”注册表中注册了一个名称空间，“info”URI方案就允许通过URI引用该名称空间中具有标识符的信息资产。因此，信息资产应被视为RFC 3986[RFC3986]中定义的资源，并应享有与URI表示相同的通用语法、语义和共享语言优势。
6.2. Why Not Use an Existing URI Scheme for Identifiers from Public Namespaces?
6.2. 为什么不为公共名称空间中的标识符使用现有的URI方案呢？
Existing URI schemes are not suitable for employment as the "info" URI scheme admits of no global dereference mechanism. While examples of resource identifiers minted under other URI schemes MAY not always be dereferenceable, nevertheless there is always a common expectation that such URIs can be dereferenced by various resolution mechanisms, whether they be location-dependent or location-independent resource identifiers. The "info" URI scheme applies to a class of resource identifiers whose Namespace Authorities MAY or MAY NOT choose to disclose service mechanisms. Nevertheless, Namespace Authorities are encouraged to disclose in the "info" registration record references to any such service mechanisms in order to provide a greater utility to network applications.
现有的URI方案不适合使用，因为“info”URI方案不允许全局解引用机制。虽然在其他URI方案下生成的资源标识符的示例可能并不总是可解引用的，但是人们总是期望这样的URI可以通过各种解析机制来解引用，无论它们是位置相关的还是位置无关的资源标识符。“info”URI方案适用于一类资源标识符，这些资源标识符的名称空间权限可以选择公开服务机制，也可以不公开服务机制。然而，鼓励名称空间管理机构在“信息”注册记录中披露对任何此类服务机制的引用，以便为网络应用程序提供更大的实用性。
6.3. Why Not Create a New URN Namespace ID for Identifiers from Public Namespaces?
6.3. 为什么不为公共名称空间中的标识符创建一个新的URN名称空间ID？
RFC 2141 [RFC2141] states that "Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers". The "info" URI scheme, on the other hand, does not assert the persistence of the identifiers created under this scheme but rather of the public namespaces grandfathered under this scheme. It exists primarily to disclose the identity of information assets and to facilitate a lightweight registration mechanism for public namespaces of identifiers managed according to the policies and business models of the Namespace Authorities. The "info" URI scheme is neutral with respect to identifier persistence. Moreover, for
RFC 2141[RFC2141]指出“统一资源名称（URN）旨在用作持久的、独立于位置的资源标识符”。另一方面，“info”URI方案并不断言在此方案下创建的标识符的持久性，而是断言在此方案下派生的公共名称空间的持久性。它的存在主要是为了公开信息资产的身份，并促进根据名称空间管理机构的策略和业务模型管理的标识符的公共名称空间的轻量级注册机制。“info”URI方案与标识符持久性无关。而且,
"info" to operate as a URN Network Identifier (NID) would require that "info" be constituted as a delegated naming authority. It is not clear that a URN NID would be an appropriate choice for naming authority delegation.
作为URN网络标识符（NID）运行的“info”将要求“info”构成一个委托的命名权限。目前尚不清楚URN NID是否是命名机构委派的合适选择。
Further, the "info" URI scheme is not globally dereferenceable in contrast to the specific recommendation given in RFC 1737, "Functional Requirements for Uniform Resource Names" [RFC1737] that "It is strongly recommended that there be a mapping between the names generated by each naming authority and URLs". Individual Namespace Authorities registered in the "info" Registry MAY, however, disclose references to service mechanisms and are encouraged to do so.
此外，与RFC 1737“统一资源名称的功能要求”[RFC1737]中给出的“强烈建议每个命名机构生成的名称与URL之间存在映射”的具体建议相比，“信息”URI方案不可全局取消引用。但是，在“info”注册表中注册的各个名称空间机构可能会披露对服务机制的引用，并鼓励这样做。
An extra consideration is that the "urn" URI syntax explicitly excludes generic URI hierarchy by reserving the slash "/" character. An "info" URI, on the other hand, admits of hierarchical processing, while remaining neutral with respect to supporting actual hierarchy, and thus allows the slash "/" character (as well as more liberally allowing the ampersand "&" and tilde "~" characters). It therefore represents a lower barrier to entry for Namespace Authorities in keeping with its intention of acting as a bridging mechanism to allow public namespaces to become part of the URI allocation. In sum, an "info" URI is more widely supportive of "human transcribability" as discussed in RFC 3986 [RFC3986] than is a "urn" URI.
另外需要考虑的是，“urn”URI语法通过保留斜杠“/”字符显式排除了通用URI层次结构。另一方面，“info”URI允许分层处理，同时在支持实际层次结构方面保持中立，因此允许斜杠“/”字符（以及更自由地允许符号“&”和波浪号“~”字符）。因此，它为名称空间管理机构提供了一个较低的进入壁垒，这与其作为桥接机制的意图一致，以允许公共名称空间成为URI分配的一部分。总之，“信息”URI比“urn”URI更广泛地支持RFC 3986[RFC3986]中讨论的“人类可转录性”。
Additionally, the "urn" URI syntax does not support "fragment" components as does the "info" URI syntax for indirect identification of secondary resources.
此外，“urn”URI语法不支持“fragment”组件，间接标识辅助资源的“info”URI语法也不支持“fragment”组件。
The "info" URI scheme syntax is subject to the same security considerations as the generic URI syntax described in RFC 3986 [RFC3986].
“info”URI方案语法与RFC 3986[RFC3986]中描述的通用URI语法受相同安全考虑的约束。
While some "info" Namespace Authorities MAY choose to disclose service mechanisms, any security considerations resulting from the execution of such services fall outside the scope of this document. It is strongly recommended that the registration record of an "info" namespace include any such considerations.
虽然一些“info”名称空间管理机构可能会选择公开服务机制，但由于执行此类服务而产生的任何安全考虑都不在本文档的范围之内。强烈建议“info”命名空间的注册记录包含任何此类注意事项。
The IANA registry for URI schemes <http://www.iana.org/assignments/uri-schemes.html> SHOULD be updated to include an entry for the "info" URI scheme when the "info" URI scheme is accepted for publication as an RFC. This entry SHOULD contain the following values:
URI方案的IANA注册表<http://www.iana.org/assignments/uri-schemes.html>当“info”URI方案被接受作为RFC发布时，应更新以包括“info”URI方案的条目。此条目应包含以下值：
Scheme Name: info
计划名称:info
Description: Information Assets with Identifiers in Public Namespaces
描述：在公共名称空间中具有标识符的信息资产
Reference: RFC 4452
参考：RFC4452
The authors acknowledge the contributions of Michael Mealling, Verisign, and Patrick Hochstenbach, Ghent University.
作者感谢根特大学的迈克尔·米林（Michael Mealling）、Verisign和帕特里克·霍克斯滕巴赫（Patrick Hochstenbach）的贡献。
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[RFC1737]Sollins，K.和L.Masinter，“统一资源名称的功能要求”，RFC 1737，1994年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]Moats，R.，“瓮语法”，RFC 21411997年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 115，RFC 4395，2006年2月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 4.0.0, defined by: The Unicode Standard, Version 4.0". (Reading, MA, Addison-Wesley, 2003). ISBN 0-321-18578-1.
[UNICODE]UNICODE联盟，“UNICODE标准，版本4.0.0，定义：UNICODE标准，版本4.0”。（雷丁，马萨诸塞州，艾迪生·韦斯利，2003年）。ISBN 0-321-18578-1。
[BIBCODE] "NASA Astrophysics Data System Bibliographic Code", <http://adsdoc.harvard.edu/abs_doc/help_pages/data.html>.
[BIBCODE]“NASA天体物理数据系统书目代码”<http://adsdoc.harvard.edu/abs_doc/help_pages/data.html>.
[DEWEY] "Dewey Decimal Classification", <http://www.oclc.org/dewey/>.
[杜威]“杜威十进制分类”<http://www.oclc.org/dewey/>.
[LCCN] "Library of Congress Control Number", <http://lcweb.loc.gov/marc/lccn_structure.html>.
[LCCN]“国会图书馆控制号”<http://lcweb.loc.gov/marc/lccn_structure.html>.
[NISO] "National Information Standards Organization", <http://www.niso.org/>.
[NISO]“国家信息标准组织”<http://www.niso.org/>.
[OCLCNUM] "Online Computer Library Center OCLC Control Number", <http://www.oclc.org/bibformats/en/fixedfield/oclc.shtm>.
[OCLCNUM]“在线计算机图书馆中心OCLC控制编号”<http://www.oclc.org/bibformats/en/fixedfield/oclc.shtm>.
[OFI] "ANSI/NISO Z39.88-2004, "The OpenURL Framework for Context-Sensitive Services", ISBN 1-880124-61-0", <http://www.niso.org/standards/resources/Z39_88_2004.pdf>.
[OFI]“ANSI/NISO Z39.88-2004，“上下文敏感服务的OpenURL框架”，ISBN 1-880124-61-0<http://www.niso.org/standards/resources/Z39_88_2004.pdf>.
[PMID] "PubMed Overview", <http://www.ncbi.nlm.nih.gov/entrez/ query/static/overview.html>.
[PMID]“PubMed概览”<http://www.ncbi.nlm.nih.gov/entrez/ query/static/overview.html>。
[SICI] "ANSI/NISO Z39.56-1996 (R2002), "Serial Item and Contribution Identifier (SICI)", ISBN 1-880124-28-9", <http://www.niso.org/standards/resources/Z39-56.pdf>.
[SICI]“ANSI/NISO Z39.56-1996（R2002），“序列项目和贡献标识符（SICI）”，ISBN 1-880124-28-9<http://www.niso.org/standards/resources/Z39-56.pdf>.
Authors' Addresses
作者地址
Herbert Van de Sompel Los Alamos National Laboratory Research Library, MS-P362 PO Box 1663 Los Alamos, NM 87545-1362 USA
赫伯特·范·德·索佩尔洛斯阿拉莫斯国家实验室研究图书馆，MS-P362邮箱1663洛斯阿拉莫斯，美国新墨西哥州87545-1362
EMail: herbertv@lanl.gov
EMail: herbertv@lanl.gov
Tony Hammond Nature Publishing Group Macmillan House 4 Crinan Street London N1 9XW UK
托尼·哈蒙德自然出版集团麦克米伦出版社4号克里南街伦敦N1 9XW英国
EMail: t.hammond@nature.com
EMail: t.hammond@nature.com
Eamonn Neylon Manifest Solutions Bicester, Oxfordshire OX26 2HX UK
Eamonn Neylon Manifest Solutions Bicester，牛津郡牛津26 2HX英国
EMail: eneylon@manifestsolutions.com
EMail: eneylon@manifestsolutions.com
Stuart L. Weibel OCLC Online Computer Library Center, Inc. 6565 Frantz Road Dublin, OH 43017-3395 USA
Stuart L.Weibel OCLC在线计算机图书馆中心，美国俄亥俄州都柏林弗兰茨路6565号，邮编43017-3395
EMail: weibel@oclc.org
EMail: weibel@oclc.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。