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


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).

Copyright(C)The Internet Society(2005)。



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.

本書に記載されている著者の見解や意見は、必ずしもWorld Wide Web Consortiumの見解や意見を反映したものではなく、広告や製品の推奨目的に使用することもできません。この提案はコンソーシアム内で技術的な検討を受けておらず、コンソーシアムの推奨として解釈されるべきではありません。



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(Uniform Resource Identifier)スキームについて説明します。タグURI(「タグ」とも呼ばれます)は、人間が扱いやすいように、空間と時間にわたって一意になるように設計されています。信頼できる解決メカニズムがないという点で、他のほとんどのURIとは異なります。タグは、純粋にエンティティ識別子として使用できます。さらに、タグを使用すると、HTTPでアクセスできないリソースの識別子として「http」URIを使用する一般的な方法よりもいくつかの利点があります。

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
1. はじめに

A tag is a type of Uniform Resource Identifier (URI) [1] designed to meet the following requirements:

タグは、次の要件を満たすように設計されたURI(Uniform Resource Identifier)の一種です。

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:


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 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

o ドメイン名は変更され、ドメイン名の新しい担当者は、新しい名前を作成していることを確信できません。たとえば、example.orgが最初にユーザーSmithに割り当てられ、次にユーザーJonesに割り当てられた場合、JonesがSmithがなどの特定の識別子をすでに使用しているかどうかを体系的に知る方法はありません。

o Entities could rely on 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 may be preferable.

o エンティティは、一意のURIの(先着順)割り当て者として、purl.orgまたは同様のサービスに依存できます。ただし、オンラインコンピュータライブラリセンター(purl.orgを実行するOCLC)などの別のエンティティに依存しないソリューションが望ましい場合があります。

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.


1.1. Terminology
1.1. 用語

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.

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119で説明されているように解釈されます。

1.2. Further Information and Discussion of this Document
1.2. このドキュメントの詳細と説明

Additional information about the tag URI scheme -- motivation, genesis, and discussion -- can be obtained from


Earlier versions of this document have been discussed on The authors welcome further discussion and comments.

このドキュメントの以前のバージョンは、uri @ w3.orgで議論されています。著者はさらなる議論とコメントを歓迎します。

2. Tag Syntax and Rules
2. タグの構文とルール

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.


2.1. Tag Syntax and Examples
2.1. タグの構文と例

The general syntax of a tag URI, in ABNF [2], is:

ABNF [2]でのタグURIの一般的な構文は次のとおりです。

      tagURI = "tag:" taggingEntity ":" specific [ "#" fragment ]



      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 ",2000:" are never equal to those beginning ",2000:", even though they refer to the same domain name.


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.


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.

「特定の」コンポーネントは、URIの名前空間固有の部分です。これは、URIのミンターによって選択されたURI文字列(構文仕様の制限を参照)です。 「特定の」コンポーネントは、RFC 3986 [1]で定義されている「クエリ」サブコンポーネントを許可することに注意してください。特定の識別子は人にやさしいものであることが推奨されます。

Tag URIs may optionally end in a fragment identifier, in accordance with the general syntax of RFC 3986 [1].

タグURIは、RFC 3986 [1]の一般的な構文に従って、オプションでフラグメント識別子で終わる場合があります。

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:

2.2. Rules for Minting Tags
2.2. タグの作成に関するルール

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.


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 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.

日付は、グレゴリオ暦とUTCに従って、機関名がタグ付けエンティティに00:00 UTC(その日の開始)に割り当てられた特定の日を指定します。日付は、その時点で権限名が割り当てられた過去または現在の日付である場合があります。日付は、ISO 8601標準[4]で許可されている「YYYY」、「YYYY-MM」、「YYYY-MM-DD」のいずれかの形式を使用して指定されます(RFC 3339 [10]も参照)。タグの仕様では、他の形式は許可されていません。タグ付けエンティティは、権限名が実際に割り当てられていない日付を誤って使用しないように十分な精度で日付を確認する必要があります(多くのコンピューターとモバイルデバイスのクロックの同期が不十分です)。日付は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です。すべての日付の定式化は、「2001年7月の全体」または「2000年の全体」などの1日以上の期間ではなく、1日の瞬間(00:00 UTC)を指定します。その時点での割り当ては、特定の日付を使用するために必要なすべてです。

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 ",2000:" are never equal to those beginning ",2000-01-01:", even though they refer to the same date (see Section 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.

エンティティは、指定された日付の00:00 UTCに別のエンティティに割り当てられた機関名でタグを作成してはならず、将来の日付でタグを作成してはなりません。

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.


For example, Hewlett-Packard holds the domain registration for 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 ",2001:", under domain names not registered to it. It must not mint tags dated in the future, such as


",2999:". If it obtains assignment of "" on 2001-05-01, then it must not mint tags under ",2001-04-01" unless it has evidence proving that name was continuously unassigned between 2001-04-01 and 2001-05-01.

「、2999:」。 2001-05-01に「」の割り当てを取得した場合、2001-04-の間に名前が継続的に割り当てられていないことを証明する証拠がない限り、「、2001-04-01」の下のタグを作成してはなりません。 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 could delegate control over all tags with the prefixes ",2004:fred:" and ",2004:bill:", respectively, to the individuals with internal names "fred" and "bill" on 2004-01-01.

タグ付けエンティティは、URI文字のみを使用する内部スキームに従って、そのコンテキスト内で一意の特定の識別子を作成します。タグ付けエンティティは、一意性を達成するために記録保持手順を使用する必要があります。一部のタグ付けエンティティ(企業、メーリングリストなど)は多くの人で構成されています。この場合、グループの意思決定を使用して一意性を実現する必要があります(SHOULD)。このような意思決定の結果、名前空間の一部に対する制御を委任することができます。たとえば、example.comの担当者は、プレフィックスが「、2004:fred:」と「、2004:bill:」のすべてのタグの制御を、 2004-01-01の「fred」と「bill」の内部名。

2.3. Resolution of Tags
2.3. タグの解決

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.


2.4. Equality of Tags
2.4. タグの同等性

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.


3. Security Considerations
3. セキュリティに関する考慮事項

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.


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 UTCの前から後まで継続的に割り当てられた機関名を使用することにより、悪意のあるクロックスキューの悪用の可能性を回避する必要があります。

4. IANA Considerations
4. IANAに関する考慮事項

The IANA has registered the tag URI scheme as specified in this document and summarised in the following template:


URI scheme name: tag


Status: permanent


URI scheme syntax: see Section 2


Character encoding considerations: percent-encoding is allowed in 'specific' and 'fragment' components (see Section 2)


Intended usage: see Section 1 and Section 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.


Interoperability considerations: none


Security considerations: see Section 3


Relevant publications: none


   Contact: Tim Kindberg ( and Sandro Hawke

Author/Change controller: Tim Kindberg and Sandro Hawke

著者/変更コントローラー:Tim KindbergとSandro Hawke

5. References
5. 参考文献
5.1. Normative References
5.1. 引用文献

[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、「Uniform Resource Identifier(URI):Generic Syntax」、STD 66、RFC 3986、2005年1月。

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

[2] クロッカー、D。、エド。および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 1035、1987年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.2. Informative References
5.2. 参考引用

[5] Leach, P. and R. Salz, "UUIDs and GUIDs", Work in Progress, 1997.

[5] リーチ、P.、R。サルツ、「UUIDとGUID」、Work in Progress、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, April 1997.

[9] パスキン、N。、「情報識別子」、学習出版Vol。 10、No。2、pp。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、「Date and Time on the Internet:Timestamps」、RFC 3339、2002年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

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 Cambridge、MA 02139 USA

   Phone: +1 617 253-7288

Full Copyright Statement


Copyright (C) The Internet Society (2005).

Copyright(C)The Internet Society(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に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。



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


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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能への資金提供は、現在Internet Societyから提供されています。