RFC 4151

RFC 4151 🎀 The 'tag' URI Scheme

okay bestie, the title block tea ☕ This is an Informational doc from October 2005, written by T. Kindberg (Hewlett-Packard Corporation) and S. Hawke (World Wide Web Consortium) for the Network Working Group. The title block doesn't list any RFCs that it obsoletes or updates, so nothing is being replaced here 💅

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

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. So no, the W3C didn't sign off on this one as an official recommendation 😭

Abstract ✨

This doc describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while still being easy for humans to deal with 🧚 They are different from most other URIs because they have no authoritative resolution mechanism. A tag can be used purely as an entity identifier. Using tags also has some perks over the usual move of using "http" URIs as identifiers for non-HTTP-accessible resources. the glow-up is real 💜

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 🌈

okay so a tag is a type of Uniform Resource Identifier (URI) [1] built to hit these four requirements, and they're honestly so good 😭

1. Identifiers are likely to be unique across space and time, and they come from a practically inexhaustible supply.
2. Identifiers are relatively convenient for humans to mint (create), read, type, remember, etc.
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.
4. The identifiers are independent of any particular resolution scheme.

Let's say a user wants to slap identifiers on their documents. The above requirements would totally apply to them 📄

• a. The user wants to be reasonably sure that the identifier is unique. Global uniqueness is valuable because it stops identifiers from becoming unintentionally ambiguous.
• b. The identifiers should be tractable to the user, who should, for example, be able to mint new identifiers conveniently, memorise them, and type them into emails and forms.
• c. The user does not want to have to communicate with anyone else in order to mint identifiers for their documents.
• 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. nobody wants a dead link pretending to be alive 💀

Existing identification schemes hit some of those requirements, but not all of them, and they're kinda messy 🙈

UUIDs [5], [6] are hard for humans to read. Real talk, nobody can remember those things.

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. Ugh, more paperwork when you already did the paperwork 🥲

URLs (in particular, "http" URLs) are sometimes used as identifiers that satisfy most of the above requirements. Lots of users and organisations have already registered a domain name, and using that domain name to mint identifiers comes at no additional cost. But there are drawbacks to URLs-as-identifiers:

• An attempt may be made to resolve a URL-as-identifier, even though there is no resource accessible at the "location".
• 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. Yikes, that's a whole plot twist 😱
• 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. Why hand your identity to someone else's gatekeeping when you don't have to? 🚪

Lastly, lots of entities (especially individuals) are assignees of email addresses but not domain names. It would be preferable to enable those entities to mint unique identifiers too. Everyone deserves a unique ID, babe 🫶

1.1. Terminology 📖

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. Those are the official BCP 14 vibes, so read them as RFC 2119 says 🎀

1.2. Further Information and Discussion of this Document 💬

More info about the tag URI scheme (the motivation, the genesis, and the discussion) can be found at http://www.taguri.org. Earlier versions of this document were discussed on uri@w3.org. The authors welcome further discussion and comments, so feel free to slide into their replies 💖

2. Tag Syntax and Rules 🧩

This section first specifies the syntax of tag URIs and gives examples. Then it describes a set of rules for minting tags, designed to make them unique. Finally, it discusses the resolution and comparison of tags. It's giving structure, and I'm here for it 👑

2.1. Tag Syntax and Examples 🔍

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

      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]

The component "taggingEntity" is the name space part of the URI. To avoid ambiguity, the domain name in "authorityName" (whether it's 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 so 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. Capital letters really do matter here, bestie 😤

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, the authority names are restricted 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. Basically, don't gatekeep future tags 🦋

The component "specific" is the name-space-specific part of the URI. It is a string of URI characters (see restrictions in the 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. Make it readable, make it iconic ✨

Tag URIs may optionally end in a fragment identifier, in accordance with the general syntax of 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]). So you can do it, you just really shouldn't 🙃

Examples of tag URIs are:

     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

Part 2 is next, where we get into minting rules, resolution, and equality 🌸

2.2. Rules for Minting Tags ✨

okay so bestie, remember from Section 2.1 that every tag has a "tagging entity" followed, optionally, by a specific identifier 🎀. The tagging entity is labelled by an "authority name" (a fully qualified domain name, or an email address that contains one) followed by a date 💅. The date is what makes the tagging entity globally unique, and it works because domain names and email addresses are only ever assigned to at most one entity at a time 🦋. Once you have that, the entity is on the hook for making sure it mints unique identifiers 💖.

The date is a day in the Gregorian calendar and UTC 🌸. It's the particular day on which the authority name was assigned to the tagging entity, specifically 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, and it's written in one of the "YYYY", "YYYY-MM" or "YYYY-MM-DD" formats from the ISO 8601 standard [4] (see also RFC 3339 [10]) 🧚. The tag spec doesn't allow any other formats, so no freestyling 💀.

Now here's the part that matters a LOT 😭. Tagging entities MUST ascertain the date with enough accuracy that they don't accidentally use a date on which the authority name wasn't actually assigned to them, because lots of computers and phones have poorly synced clocks 🙈. The date MUST be reckoned from UTC, which can be different from the date in your local timezone at 00:00 UTC 🌈. Honestly that difference is usually safe to ignore, but NOT on the day the name was assigned 🚨. On that exact day, the previous assignee and the new assignee could both use the same date and end up minting the same tags, which is a total mess 💔.

The month and day default to "01" to keep things short 🍓. A day value of "01" MAY be left out, and a month value of "01" MAY be left out too, unless it's followed by a day value other than "01" 🌷. So "2001-07" means 2001-07-01, and "2000" means 2000-01-01 🎀. Every date points at one moment (00:00 UTC) on a single day, not a whole period like "the whole of July 2001" or "the whole of 2000" 📅. Being assigned at that moment is all you need to use a date ✨.

Tagging entities should know that different ways of writing the same date count as different, so the tags are unequal 🙃. For example, "tag:example.com,2000:" is never equal to "tag:example.com,2000-01-01:", even though they mean 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 🛑. Non-negotiable, bestie 😤.

An entity that picks up an authority name right after a period when the name was unassigned MAY mint tags as if it had been assigned the name during that unassigned stretch 🦋. This has a LOT of room for error, so it MUST NOT be used unless the entity has substantial evidence that the name really was unassigned during that period 😬. The authors aren't aware of any mechanism that would count as evidence, apart from daily polling of the "whois" registry 🔍.

For example, Hewlett-Packard holds the domain registration for hp.com, so it MAY mint any tags rooted at that name with a current or past date from when it held the registration 💼. It must not mint tags, like "tag:champignon.net,2001:", under domain names that aren't registered to it 🍄. It must not mint tags dated in the future, like "tag:hp.com,2999:" 🔮. If it gets 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 the name was continuously unassigned between 2001-04-01 and 2001-05-01 🕵️‍♀️ (iykyk, it's giving detective energy).

A tagging entity mints specific identifiers that are unique within its context, following any internal scheme that only uses URI characters 🧩. Tagging entities SHOULD use record-keeping procedures to get uniqueness 📒. Some tagging entities (like corporations or mailing lists) are made up of lots of people, and in that case group decision-making SHOULD also be used to get uniqueness 🙌. The result of that decision-making could be delegating 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:" to the individuals with internal names "fred" and "bill" on 2004-01-01 💅✨.

2.3. Resolution of Tags 🌸

There is no authoritative resolution mechanism for tags 🙅‍♀️. Unlike most other URIs, tags can only be used as identifiers and aren't designed to support resolution 🦋. If authoritative resolution is something you need, a different URI scheme should be used 💜.

2.4. Equality of Tags 💖

Tags are simply strings of characters, and they're equal if and only if they are completely indistinguishable in their machine representations when using the same character encoding 🎀. In other words, you can compare two tags by checking the numeric codes of their characters, in sequence, for numeric equality 🔢. This makes tag-handling software simpler, since it doesn't have to transform tags in any way to compare them 🧚 (the way that's so clean, honestly 😭).

3. Security Considerations 🔐

Minting a tag, on its own, is an operation that stays inside the tagging entity and has no external consequences 🏠. The consequences of using an improperly minted tag (whether from malice or error) depend on the application, and they must be considered in the design of any application that uses tags 🚨.

There's a significant chance of minting errors from people who don't follow the rules about 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, though, software MUST NOT reject tags that don't conform to the syntax in Section 2, so the format can grow in the future 🌈.

A malicious party could make it look like the same domain name or email address was assigned to 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 😤. They should use 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 on the order of days 🦋.

4. IANA Considerations 📋

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 (timothy@hpl.hp.com) and Sandro Hawke
(sandro@w3.org)

Author/Change controller: Tim Kindberg and Sandro Hawke

5. References 📚

5.1. Normative References 🔗

[1]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
     Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
     January 2005.

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

[3]  Mockapetris, P., "Domain names - implementation and
     specification", STD 13, RFC 1035, November 1987.

[4]  "Data elements and interchange formats -- Information
     interchange -- Representation of dates and   times", ISO
     (International Organization for Standardization) ISO 8601:1988,
     1988.

5.2. Informative References 🌟

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

[6]   "Information technology - Open Systems Interconnection - Remote
      Procedure Call (RPC)", ISO (International Organization for
      Standardization) ISO/IEC 11578:1996, 1996.

[7]   "Specification of abstract syntax notation one (ASN.1)", ITU-T
      recommendation X.208,  (see also RFC 1778), 1988.

[8]   Mealling, M., "A URN Namespace of Object Identifiers",
      RFC 3061, February 2001.

[9]   Paskin, N., "Information Identifiers", Learned Publishing Vol.
      10, No. 2, pp. 135-156,  (see also www.doi.org), April 1997.

[10]  Klyne, G. and C. Newman, "Date and Time on the Internet:
      Timestamps", RFC 3339, July 2002.

Authors' Addresses 💌

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


Sandro Hawke
World Wide Web Consortium
32 Vassar Street
Building 32-G508
Cambridge, MA  02139
USA

Phone: +1 617 253-7288
EMail: sandro@w3.org

Full Copyright Statement 🎀

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.

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.

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.

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.

Acknowledgement 💜

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