Network Working Group T. Kindberg
Request for Comments: 4151 Hewlett-Packard Corporation
Category: Informational S. Hawke
World Wide Web Consortium
October 2005
Network Working Group T. Kindberg
Request for Comments: 4151 Hewlett-Packard Corporation
Category: Informational S. Hawke
World Wide Web Consortium
October 2005
The 'tag' URI Scheme
“标记”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 (2005).
版权所有（C）互联网协会（2005年）。
Disclaimer
免责声明
The views and opinions of authors expressed herein do not necessarily state or reflect those of the World Wide Web Consortium, and may not be used for advertising or product endorsement purposes. This proposal has not undergone technical review within the Consortium and must not be construed as a Consortium recommendation.
本文作者的观点和意见不一定陈述或反映万维网联盟的观点和意见，也不可能用于广告或产品背书目的。本建议书未经联合体内部的技术审查，不得解释为联合体建议。
Abstract
摘要
This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources.
本文档描述了“标记”统一资源标识符（URI）方案。标签URI（也称为“标签”）被设计为在空间和时间上都是唯一的，同时便于人类使用。它们不同于大多数其他URI，因为它们没有权威的解析机制。标记可以纯粹用作实体标识符。此外，与使用“http”URI作为非http可访问资源的标识符的常见做法相比，使用标记具有一些优势。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Further Information and Discussion of this Document ........4
2. Tag Syntax and Rules ............................................4
2.1. Tag Syntax and Examples ....................................4
2.2. Rules for Minting Tags .....................................5
2.3. Resolution of Tags .........................................7
2.4. Equality of Tags ...........................................7
3. Security Considerations .........................................7
4. IANA Considerations .............................................8
5. References ......................................................9
5.1. Normative References .......................................9
5.2. Informative References .....................................9
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Further Information and Discussion of this Document ........4
2. Tag Syntax and Rules ............................................4
2.1. Tag Syntax and Examples ....................................4
2.2. Rules for Minting Tags .....................................5
2.3. Resolution of Tags .........................................7
2.4. Equality of Tags ...........................................7
3. Security Considerations .........................................7
4. IANA Considerations .............................................8
5. References ......................................................9
5.1. Normative References .......................................9
5.2. Informative References .....................................9
A tag is a type of Uniform Resource Identifier (URI) [1] designed to meet the following requirements:
标记是一种统一资源标识符（URI）[1]，旨在满足以下要求：
1. Identifiers are likely to be unique across space and time, and come from a practically inexhaustible supply.
1. 标识符可能在空间和时间上都是唯一的，并且几乎取之不尽、用之不竭。
2. Identifiers are relatively convenient for humans to mint (create), read, type, remember etc.
2. 标识符对于人类来说是相对方便的，可以造币（创建）、阅读、键入、记忆等。
3. No central registration is necessary, at least for holders of domain names or email addresses; and there is negligible cost to mint each new identifier.
3. 无需进行集中注册，至少对于域名或电子邮件地址的持有人而言是如此；制造每一个新的标识符的成本可以忽略不计。
4. The identifiers are independent of any particular resolution scheme.
4. 标识符独立于任何特定的解决方案。
For example, the above requirements may apply in the case of a user who wants to place identifiers on their documents:
例如，上述要求可适用于希望在其文档上放置标识符的用户：
a. The user wants to be reasonably sure that the identifier is unique. Global uniqueness is valuable because it prevents identifiers from becoming unintentionally ambiguous.
a. 用户希望合理地确保标识符是唯一的。全局唯一性很有价值，因为它可以防止标识符无意中变得不明确。
b. The identifiers should be tractable to the user, who should, for example, be able to mint new identifiers conveniently, to memorise them, and to type them into emails and forms.
b. 标识符应便于用户处理，例如，用户应能够方便地创建新的标识符，记忆它们，并将它们键入电子邮件和表单中。
c. The user does not want to have to communicate with anyone else in order to mint identifiers for their documents.
c. 用户不希望为了为其文档创建标识符而必须与任何其他人通信。
d. The user wants to avoid identifiers that might be taken to imply the existence of an electronic resource accessible via a default resolution mechanism, when no such electronic resource exists.
d. 当不存在这样的电子资源时，用户希望避免可能被认为暗示存在可通过默认解析机制访问的电子资源的标识符。
Existing identification schemes satisfy some, but not all, of the requirements above. For example:
现有识别方案满足上述部分（但不是全部）要求。例如：
UUIDs [5], [6] are hard for humans to read.
UUID[5]、[6]对人类来说很难阅读。
OIDs [7], [8] and Digital Object Identifiers [9] require entities to register as naming authorities, even in cases where the entity already holds a domain name registration.
OID[7]、[8]和数字对象标识符[9]要求实体注册为命名机构，即使实体已经拥有域名注册。
URLs (in particular, "http" URLs) are sometimes used as identifiers that satisfy most of the above requirements. Many users and organisations have already registered a domain name, and the use of the domain name to mint identifiers comes at no additional cost. But there are drawbacks to URLs-as-identifiers:
URL（特别是“http”URL）有时用作满足上述大多数要求的标识符。许多用户和组织已经注册了一个域名，使用该域名来创建标识符不需要额外的费用。但URL作为标识符也有缺点：
o An attempt may be made to resolve a URL-as-identifier, even though there is no resource accessible at the "location".
o 即使“位置”上没有可访问的资源，也可以尝试将URL解析为标识符。
o Domain names change hands and the new assignee of a domain name can't be sure that they are minting new names. For example, if example.org is assigned first to a user Smith and then to a user Jones, there is no systematic way for Jones to tell whether Smith has already used a particular identifier such as http://example.org/9999.
o 域名易手，域名的新受让人无法确定他们是否在创造新的域名。例如，如果example.org首先分配给用户Smith，然后再分配给用户Jones，Jones就无法系统地判断Smith是否已经使用了特定的标识符，例如http://example.org/9999.
o Entities could rely on purl.org or a similar service as a (first-come, first-served) assigner of unique URIs; but a solution without reliance upon another entity such as the Online Computer Library Center (OCLC, which runs purl.org) may be preferable.
o 实体可以依赖purl.org或类似服务作为唯一URI的（先到先得）分配者；但是一个不依赖其他实体的解决方案，如在线计算机图书馆中心（OCLC，运行purl.org）可能更可取。
Lastly, many entities -- especially individuals -- are assignees of email addresses but not domain names. It would be preferable to enable those entities to mint unique identifiers.
最后，许多实体——特别是个人——是电子邮件地址的受让人，而不是域名。最好是使这些实体能够创造独特的标识符。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
Additional information about the tag URI scheme -- motivation, genesis, and discussion -- can be obtained from http://www.taguri.org.
关于标记URI方案的其他信息——动机、起源和讨论——可以从http://www.taguri.org.
Earlier versions of this document have been discussed on uri@w3.org. The authors welcome further discussion and comments.
本文档的早期版本已在上讨论过uri@w3.org. 作者欢迎进一步的讨论和评论。
This section first specifies the syntax of tag URIs and gives examples. It then describes a set of rules for minting tags that is designed to make them unique. Finally, it discusses the resolution and comparison of tags.
本节首先指定标记URI的语法并给出示例。然后，它描述了一组用于制作标记的规则，这些规则旨在使标记具有唯一性。最后，讨论了标签的分辨率和比较。
The general syntax of a tag URI, in ABNF [2], is:
ABNF[2]中标记URI的一般语法为：
tagURI = "tag:" taggingEntity ":" specific [ "#" fragment ]
tagURI = "tag:" taggingEntity ":" specific [ "#" fragment ]
Where:
哪里：
taggingEntity = authorityName "," date
authorityName = DNSname / emailAddress
date = year ["-" month ["-" day]]
year = 4DIGIT
month = 2DIGIT
day = 2DIGIT
DNSname = DNScomp *( "." DNScomp ) ; see RFC 1035 [3]
DNScomp = alphaNum [*(alphaNum /"-") alphaNum]
emailAddress = 1*(alphaNum /"-"/"."/"_") "@" DNSname
alphaNum = DIGIT / ALPHA
specific = *( pchar / "/" / "?" ) ; pchar from RFC 3986 [1]
fragment = *( pchar / "/" / "?" ) ; same as RFC 3986 [1]
taggingEntity = authorityName "," date
authorityName = DNSname / emailAddress
date = year ["-" month ["-" day]]
year = 4DIGIT
month = 2DIGIT
day = 2DIGIT
DNSname = DNScomp *( "." DNScomp ) ; see RFC 1035 [3]
DNScomp = alphaNum [*(alphaNum /"-") alphaNum]
emailAddress = 1*(alphaNum /"-"/"."/"_") "@" DNSname
alphaNum = DIGIT / ALPHA
specific = *( pchar / "/" / "?" ) ; pchar from RFC 3986 [1]
fragment = *( pchar / "/" / "?" ) ; same as RFC 3986 [1]
The component "taggingEntity" is the name space part of the URI. To avoid ambiguity, the domain name in "authorityName" (whether an email address or a simple domain name) MUST be fully qualified. It is RECOMMENDED that the domain name should be in lowercase form. Alternative formulations of the same authority name will be counted as distinct and, hence, tags containing them will be unequal (see Section 2.4). For example, tags beginning "tag:EXAMPLE.com,2000:" are never equal to those beginning "tag:example.com,2000:", even though they refer to the same domain name.
组件“taggingEntity”是URI的名称空间部分。为避免歧义，“authorityName”中的域名（无论是电子邮件地址还是简单域名）必须完全限定。建议域名采用小写形式。相同机构名称的替代公式将被视为不同的，因此，包含它们的标签将不相等（见第2.4节）。例如，以“tag:example.com，2000:”开头的标记永远不等于以“tag:example.com，2000:”开头的标记，即使它们引用的是相同的域名。
Authority names could, in principle, belong to any syntactically distinct namespaces whose names are assigned to a unique entity at a time. Those include, for example, certain IP addresses, certain MAC addresses, and telephone numbers. However, to simplify the tag scheme, we restrict authority names to domain names and email addresses. Future standards efforts may allow use of other authority names following syntax that is disjoint from this syntax. To allow for such developments, software that processes tags MUST NOT reject them on the grounds that they are outside the syntax defined above.
原则上，权限名称可以属于任何语法上不同的名称空间，这些名称空间的名称一次分配给一个唯一的实体。例如，这些包括某些IP地址、某些MAC地址和电话号码。然而，为了简化标记方案，我们将权限名称限制为域名和电子邮件地址。未来的标准工作可能允许使用与此语法不相交的语法后面的其他机构名称。为了允许此类开发，处理标记的软件不得以标记超出上面定义的语法为由拒绝标记。
The component "specific" is the name-space-specific part of the URI: it is a string of URI characters (see restrictions in syntax specification) chosen by the minter of the URI. Note that the "specific" component allows for "query" subcomponents as defined in RFC 3986 [1]. It is RECOMMENDED that specific identifiers should be human-friendly.
组件“specific”是URI的名称空间特定部分：它是URI的minter选择的URI字符字符串（参见语法规范中的限制）。注意，“特定”组件允许RFC 3986[1]中定义的“查询”子组件。建议特定标识符应人性化。
Tag URIs may optionally end in a fragment identifier, in accordance with the general syntax of RFC 3986 [1].
根据RFC 3986[1]的一般语法，标记URI可以选择性地以片段标识符结尾。
In the interests of tractability to humans, tags SHOULD NOT be minted with percent-encoded parts. However, the tag syntax does allow percent-encoded characters in the "pchar" elements (defined in RFC 3986 [1]).
为了便于人类使用，标签不应使用百分比编码部分制作。但是，标记语法允许在“pchar”元素中使用百分比编码字符（在RFC 3986[1]中定义）。
Examples of tag URIs are:
标记URI的示例包括：
tag:timothy@hpl.hp.com,2001:web/externalHome
tag:sandro@w3.org,2004-05:Sandro
tag:my-ids.com,2001-09-15:TimKindberg:presentations:UBath2004-05-19
tag:blogger.com,1999:blog-555
tag:yaml.org,2002:int
tag:timothy@hpl.hp.com,2001:web/externalHome
tag:sandro@w3.org,2004-05:Sandro
tag:my-ids.com,2001-09-15:TimKindberg:presentations:UBath2004-05-19
tag:blogger.com,1999:blog-555
tag:yaml.org,2002:int
As Section 2.1 has specified, each tag includes a "tagging entity" followed, optionally, by a specific identifier. The tagging entity is designated by an "authority name" -- a fully qualified domain name or an email address containing a fully qualified domain name -- followed by a date. The date is chosen to make the tagging entity globally unique, exploiting the fact that domain names and email addresses are assigned to at most one entity at a time. That entity then ensures that it mints unique identifiers.
如第2.1节所述，每个标签包括一个“标签实体”，后面可选地跟有一个特定的标识符。标记实体由“权威名称”——完全限定的域名或包含完全限定的域名的电子邮件地址——后跟日期来指定。选择日期是为了使标记实体具有全局唯一性，利用域名和电子邮件地址一次最多分配给一个实体这一事实。然后，该实体确保其生成唯一标识符。
The date specifies, according to the Gregorian calendar and UTC, any particular day on which the authority name was assigned to the tagging entity at 00:00 UTC (the start of the day). The date MAY be a past or present date on which the authority name was assigned at
根据公历和UTC，日期指定在UTC 00:00（一天的开始）将机构名称分配给标记实体的任何特定日期。该日期可以是过去或现在的日期，在该日期分配机构名称
that moment. The date is specified using one of the "YYYY", "YYYY-MM" and "YYYY-MM-DD" formats allowed by the ISO 8601 standard [4] (see also RFC 3339 [10]). The tag specification permits no other formats. Tagging entities MUST ascertain the date with sufficient accuracy to avoid accidentally using a date on which the authority name was not, in fact, assigned (many computers and mobile devices have poorly synchronised clocks). The date MUST be reckoned from UTC, which may differ from the date in the tagging entity's local timezone at 00:00 UTC. That distinction can generally be safely ignored in practice, but not on the day of the authority name's assignment. In principle it would otherwise be possible on that day for the previous assignee and the new assignee to use the same date and, thus, mint the same tags.
那一刻。使用ISO 8601标准[4]允许的“YYYY”、“YYYY-MM”和“YYYY-MM-DD”格式之一指定日期（另请参见RFC 3339[10]）。标签规范不允许其他格式。标记实体必须以足够的准确性确定日期，以避免意外使用事实上未分配机构名称的日期（许多计算机和移动设备的时钟同步性较差）。必须根据UTC计算日期，UTC可能不同于标记实体当地时区00:00 UTC的日期。在实践中，这种区别通常可以被安全地忽略，但在机构名称被指定之日，这种区别就不会被忽略。原则上，前受让人和新受让人可以在该日使用同一日期，因此可以制作相同的标签。
In the interests of brevity, the month and day default to "01". A day value of "01" MAY be omitted; a month value of "01" MAY be omitted unless it is followed by a day value other than "01". For example, "2001-07" is the date 2001-07-01 and "2000" is the date 2000-01-01. All date formulations specify a moment (00:00 UTC) of a single day, and not a period of a day or more such as "the whole of July 2001" or "the whole of 2000". Assignment at that moment is all that is required to use a given date.
为了简洁起见，月份和日期默认为“01”。可以省略“01”的日值；月份值“01”可以省略，除非后面跟的是除“01”以外的日值。例如，“2001-07”是日期2001-07-01，“2000”是日期2000-01-01。所有日期公式都指定了一天中的某一时刻（UTC时间00:00），而不是一天或更长的时间段，如“2001年7月整”或“2000年整”。此时的任务是使用给定日期所需的全部任务。
Tagging entities should be aware that alternative formulations of the same date will be counted as distinct and, hence, tags containing them will be unequal. For example, tags beginning "tag:example.com,2000:" are never equal to those beginning "tag:example.com,2000-01-01:", even though they refer to the same date (see Section 2.4).
标签实体应意识到，同一日期的替代配方将被视为不同配方，因此，包含它们的标签将不相等。例如，以“tag:example.com，2000:”开头的标记永远不等于以“tag:example.com，2000-01-01:”开头的标记，即使它们指的是同一日期（见第2.4节）。
An entity MUST NOT mint tags under an authority name that was assigned to a different entity at 00:00 UTC on the given date, and it MUST NOT mint tags under a future date.
实体不得在给定日期UTC 00:00分配给不同实体的机构名称下创建标签，也不得在未来日期创建标签。
An entity that acquires an authority name immediately after a period during which the name was unassigned MAY mint tags as if the entity were assigned the name during the unassigned period. This practice has considerable potential for error and MUST NOT be used unless the entity has substantial evidence that the name was unassigned during that period. The authors are currently unaware of any mechanism that would count as evidence, other than daily polling of the "whois" registry.
在未分配名称的期间之后立即获得机构名称的实体可以制作标签，就好像该实体在未分配期间被分配了名称一样。这种做法有相当大的潜在错误，除非实体有确凿证据证明该名称在此期间未指定，否则不得使用。除了每天对“whois”登记处进行投票外，作者目前还不知道有什么机制可以算作证据。
For example, Hewlett-Packard holds the domain registration for hp.com and may mint any tags rooted at that name with a current or past date when it held the registration. It must not mint tags, such as "tag:champignon.net,2001:", under domain names not registered to it. It must not mint tags dated in the future, such as
例如，Hewlett-Packard持有hp.com的域名注册，并且可能会在其持有注册时在该名称的根上刻上当前或过去日期的任何标记。它不得在未注册的域名下制造标签，如“tag:champignon.net，2001:”。它不能铸造日期在将来的标签，例如
"tag:hp.com,2999:". If it obtains assignment of "extremelyunlikelytobeassigned.org" on 2001-05-01, then it must not mint tags under "extremelyunlikelytobeassigned.org,2001-04-01" unless it has evidence proving that name was continuously unassigned between 2001-04-01 and 2001-05-01.
标签：hp.com，2999:。如果在2001-05-01获得“extremelyunlikelytobeassigned.org”的分配，则不得在“extremelyunlikelytobeassigned.org，2001-04-01”下制作标签，除非有证据证明名称在2001-04-01和2001-05-01之间连续未分配。
A tagging entity mints specific identifiers that are unique within its context, in accordance with any internal scheme that uses only URI characters. Tagging entities SHOULD use record-keeping procedures to achieve uniqueness. Some tagging entities (e.g., corporations, mailing lists) consist of many people, in which case group decision-making SHOULD also be used to achieve uniqueness. The outcome of such decision-making could be to delegate control over parts of the namespace. For example, the assignees of example.com could delegate control over all tags with the prefixes "tag:example.com,2004:fred:" and "tag:example.com,2004:bill:", respectively, to the individuals with internal names "fred" and "bill" on 2004-01-01.
标记实体根据仅使用URI字符的任何内部方案，在其上下文中生成唯一的特定标识符。标记实体应使用记录保存程序实现唯一性。一些标记实体（如公司、邮件列表）由许多人组成，在这种情况下，还应使用群体决策来实现唯一性。这种决策的结果可能是委派对命名空间部分的控制权。例如，example.com的受让人可以将前缀为“tag:example.com，2004:fred:”和“tag:example.com，2004:bill:”的所有标记的控制权分别委托给2004-01-01上内部名为“fred”和“bill”的个人。
There is no authoritative resolution mechanism for tags. Unlike most other URIs, tags can only be used as identifiers, and are not designed to support resolution. If authoritative resolution is a desired feature, a different URI scheme should be used.
标签没有权威的解析机制。与大多数其他URI不同，标记只能用作标识符，并且不支持解析。如果需要权威解析，则应使用不同的URI方案。
Tags are simply strings of characters and are considered equal if and only if they are completely indistinguishable in their machine representations when using the same character encoding. That is, one can compare tags for equality by comparing the numeric codes of their characters, in sequence, for numeric equality. This criterion for equality allows for simplification of tag-handling software, which does not have to transform tags in any way to compare them.
标记只是字符串，当且仅当使用相同的字符编码时，它们在机器表示中完全不可区分时，才被认为是相等的。也就是说，可以通过按顺序比较标记字符的数字代码来比较标记是否相等。此相等标准允许简化标记处理软件，该软件不必以任何方式转换标记来比较它们。
Minting a tag, by itself, is an operation internal to the tagging entity, and has no external consequences. The consequences of using an improperly minted tag (due to malice or error) in an application depends on the application, and must be considered in the design of any application that uses tags.
生成标记本身是标记实体的内部操作，没有外部后果。在应用程序中使用不正确的标记（由于恶意或错误）的后果取决于应用程序，并且在设计任何使用标记的应用程序时必须考虑到这一点。
There is a significant possibility of minting errors by people who fail to apply the rules governing dates, or who use a shared (organizational) authority-name without prior organization-wide agreement. Tag-aware software MAY help catch and warn against these
如果有人未能应用日期规则，或未事先获得整个组织的同意而使用共享（组织）机构名称，则很可能会制造错误。标签感知软件可能有助于捕获和警告这些信息
errors. As stated in Section 2, however, to allow for future expansion, software MUST NOT reject tags which do not conform to the syntax specified in Section 2.
错误。但是，如第2节所述，为便于将来扩展，软件不得拒绝不符合第2节规定语法的标记。
A malicious party could make it appear that the same domain name or email address was assigned to each of two or more entities. Tagging entities SHOULD use reputable assigning authorities and verify assignment wherever possible.
恶意方可能使两个或多个实体中的每一个都被分配了相同的域名或电子邮件地址。标记实体应使用声誉良好的分配机构，并尽可能验证分配。
Entities SHOULD also avoid the potential for malicious exploitation of clock skew, by using authority names that were assigned continuously from well before to well after 00:00 UTC on the date chosen for the tagging entity -- preferably by intervals in the order of days.
实体还应避免恶意利用时钟偏移的可能性，方法是使用在为标记实体选择的日期从UTC 00:00之前到00:00之后连续分配的机构名称——最好以天为间隔。
The IANA has registered the tag URI scheme as specified in this document and summarised in the following template:
IANA已按照本文件的规定注册了标签URI方案，并在以下模板中进行了总结：
URI scheme name: tag
URI方案名称：标记
Status: permanent
地位：永久
URI scheme syntax: see Section 2
URI方案语法：参见第2节
Character encoding considerations: percent-encoding is allowed in 'specific' and 'fragment' components (see Section 2)
字符编码注意事项：“特定”和“片段”组件中允许百分比编码（参见第2节）
Intended usage: see Section 1 and Section 2.3
预期用途：见第1节和第2.3节
Applications and/or protocols that use this URI scheme name: Any applications that use URIs as identifiers without requiring dereference, such as RDF, YAML, and Atom.
使用此URI方案名称的应用程序和/或协议：使用URI作为标识符而不需要解引用的任何应用程序，如RDF、YAML和Atom。
Interoperability considerations: none
互操作性注意事项：无
Security considerations: see Section 3
安全注意事项：见第3节
Relevant publications: none
相关出版物：无
Contact: Tim Kindberg (timothy@hpl.hp.com) and Sandro Hawke
(sandro@w3.org)
Contact: Tim Kindberg (timothy@hpl.hp.com) and Sandro Hawke
(sandro@w3.org)
Author/Change controller: Tim Kindberg and Sandro Hawke
作者/变更控制员：蒂姆·金德伯格和桑德罗·霍克
[1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[1] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[3] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[4] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO (International Organization for Standardization) ISO 8601:1988, 1988.
[4] “数据元和交换格式——信息交换——日期和时间的表示”，ISO（国际标准化组织）ISO 8601:1988，1988。
[5] Leach, P. and R. Salz, "UUIDs and GUIDs", Work in Progress, 1997.
[5] Leach，P.和R.Salz，“UUID和GUID”，正在进行的工作，1997年。
[6] "Information technology - Open Systems Interconnection - Remote Procedure Call (RPC)", ISO (International Organization for Standardization) ISO/IEC 11578:1996, 1996.
[6] “信息技术.开放系统互连.远程过程调用（RPC）”，ISO（国际标准化组织）ISO/IEC 11578:1996，1996。
[7] "Specification of abstract syntax notation one (ASN.1)", ITU-T recommendation X.208, (see also RFC 1778), 1988.
[7] “抽象语法符号1规范（ASN.1）”，ITU-T建议X.208，（另见RFC 1778），1988年。
[8] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001.
[8] Mealling，M.“对象标识符的URN名称空间”，RFC 3061，2001年2月。
[9] Paskin, N., "Information Identifiers", Learned Publishing Vol. 10, No. 2, pp. 135-156, (see also www.doi.org), April 1997.
[9] N.Paskin，“信息标识符”，学习出版第10卷，第2期，第135-156页，（另见www.doi.org），1997年4月。
[10] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[10] Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 33392002年7月。
Authors' Addresses
作者地址
Tim Kindberg Hewlett-Packard Corporation Hewlett-Packard Laboratories Filton Road Stoke Gifford Bristol BS34 8QZ UK
Tim Kindberg Hewlett-Packard Corporation Hewlett-Packard Laboratories Filton Road Stoke Gifford Bristol BS34 8QZ UK
Phone: +44 117 312 9920
EMail: timothy@hpl.hp.com
Phone: +44 117 312 9920
EMail: timothy@hpl.hp.com
Sandro Hawke World Wide Web Consortium 32 Vassar Street Building 32-G508 Cambridge, MA 02139 USA
Sandro Hawke World Wide Web Consortium 32 Vassar Street Building 32-G508美国马萨诸塞州剑桥市02139
Phone: +1 617 253-7288
EMail: sandro@w3.org
Phone: +1 617 253-7288
EMail: sandro@w3.org
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编辑功能的资金目前由互联网协会提供。