[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 4151

Internet Draft                                              Tim Kindberg
Document: draft-kindberg-tag-uri-00.txt      Hewlett-Packard Corporation
Expires: January 1, 2002                                    Sandro Hawke
                                               World Wide Web Consortium
                                                               July 2001

                          The 'tag' URI scheme


   This  document  is  an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents  of  the  Internet  Engineering
   Task  Force  (IETF),  its  areas,  and its working groups.  Note that
   other groups may  also  distribute  working  documents  as  Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at  any
   time.   It  is  inappropriate  to  use  Internet-Drafts  as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-draft will expire on January 1, 2002.

   Copyright Notice Copyright (C) The Internet Society (2001). All
   Rights Reserved.

   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.


   This document describes the 'tag' Uniform Resource Identifier (URI)
   scheme for identifiers that are unique across space and time.
   Identifiers belonging to this scheme are distinct from most other
   URIs in that they are intended for uses that are independent of any

Kindberg         Informational - Expires January 1, 2002        [Page 1]

Internet-Draft             The tag: URI scheme                 July 2001

   particular method for resource location or name resolution. A 'tag'
   URI may be used purely as an identifier that distinguishes one entity
   from another. It may also be presented to services for resolution
   into a web resource or into one or more further URIs, but no
   particular resolution scheme is implied or preferred by a 'tag' URI
   itself. Unlike UUIDs or GUIDs such as 'uuid' URIs and 'urn:oid' URIs,
   which also have some of the above properties, 'tag' URIs are designed
   to be tractable to humans. Furthermore, they have many of the
   desirable properties that 'http' URLs have when used as identifiers,
   but none of the drawbacks.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.


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

   1) Identifiers are unique across space and time and come from a
      practically inexhaustible supply;
   2) identifiers are convenient for humans to mint (create), read, type
   3) zero registration cost, at least to holders of domain names or
      email addresses; and negligible cost to mint new identifiers;
   4) independence of any particular resource-location or identifier-
      resolution scheme.

   For example, the above requirements may apply in the case of a user
   who wants to place identifiers on their documents:

   A) They want to be sure that the identifier is unique. Global
      uniqueness is valuable because it guarantees that one identifier
      cannot conflict with another, however identifiers become shared.
   B) It is useful for the identifier to be tractable to humans: they
      should be able to mint new identifiers conveniently, and to type
      them into emails and forms.
   C) They do not want to have to communicate with anyone else in order
      to mint identifiers for their documents.
   D) As a good net citizen, the user does not want to use an identifier
      that might be assumed by software to imply the existence of a
      corresponding resource in a default binding scheme  so that an
      attempt to retrieve that resource is likely but doomed to failure.
      Of course, this leaves them free to exploit the identifier in

Kindberg         Informational - Expires January 1, 2002        [Page 2]

Internet-Draft             The tag: URI scheme                 July 2001

      particular applications and services, where the context is clear.

   Existing identification schemes satisfy some but not all of the
   general requirements 1-4. For example:

   UUIDs [UUID, ISO11578] are hard for humans to read.

   OIDs [OID, RFC3061] and Digital Object Identifiers [DOI] require
   naming authorities to register themselves, even if they already hold
   a domain name registration.

   URNs [RFC2141] are intended to denote one and only one resource
   persistently. While that is useful in some cases, contextual (i.e.
   variable, according to context) and temporary denotations also have
   their uses.

   URLs (in particular, 'http' URLs) are sometimes used as ersatz
   identifiers that satisfy most of our 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:

   1) Software might try to dereference a URL-as-identifier, even though
      there is no resource at the 'location'.
   2) The new holder of a domain name can't be sure that they are
      minting new names. If Smith registers champignon.net and then
      Jones registers it, how can Jones know, in general, whether Smith
      has already used http://champignon.net/99?


   Section 2 gives a specification for tags: their syntax and the rules
   governing their creation and comparison. Section 3 revisits the
   requirements outlined above and shows that the tag specification
   meets them. Section 4 covers security considerations.


   Examples of tag URIs (also known as 'tags') are:


Kindberg         Informational - Expires January 1, 2002        [Page 3]

Internet-Draft             The tag: URI scheme                 July 2001


   Each tag consists of a 'tag authority' followed, optionally, by a
   specific identifier. The tag authority consists of an 'authority
   name' -- a fully qualified domain name or an email address containing
   a fully qualified domain name -- followed by a date. The tag
   authority is globally unique because domain names and email addresses
   are assigned to at most one entity at a time. That entity can be sure
   of minting unique identifiers.

   The date specifies, according to the Gregorian calendar, any
   particular day on which the authority name was assigned to the
   minting entity. One way to specify the date is to use the 'YYYY-MM-
   DD' format allowed by the ISO 8601 standard [DATETIME, ISO8601]. The
   tag specification permits no other ISO 8601 format.

   The other way of specifying a day is to use a 'tag date'. The tag
   date format mandates several abbreviations, in the interests of being
   able to transcribe tags into identification technologies of limited
   capacity (e.g.  barcodes), while ensuring that tags are single-
   valued, for easy comparison. Tag dates obey the following rules:

   1) The year, which MUST be specified and MUST be at least 2001, is
      abbreviated by subtracting 2000 and prefixing 't' (for 'tag
      date'), so that 2001 is written 't1', 11958 is 't9958', etc.
   2) The month and day default to 1. A day value of 1 MUST be omitted.
      A month value of 1 MUST be omitted unless it is followed by a day
      value other than 1. For example, 't1' is the date 2001-01-01,
      't3-4' is 2003- 04-01. The date values 't2-1' and 't2-4-1' are not
      allowed but 't2-1-4' is allowed.
   3) Date components MUST NOT contain a leading zero.

   Tag dates, including those such as 't1' and 't3-4', each specify a
   single day, like the ISO 8601 dates allowed in tags. They are not to
   be taken as periods of more than a day such as 'the whole of 2001' or
   'the whole of April 2003'.

   A tag authority mints specific identifiers that are unique within its
   context, in accordance with any internal scheme that uses only URI
   characters. Some tag authorities (e.g. corporations, mailing lists)
   consist of many people, in which case group decision-making and
   record- keeping procedures are required to achieve uniqueness.

   Entities that were assigned an authority name on a given date MAY
   mint tags rooted at that date-qualified name. An entity MUST NOT mint
   tags under an authority name that was assigned to a different entity

Kindberg         Informational - Expires January 1, 2002        [Page 4]

Internet-Draft             The tag: URI scheme                 July 2001

   on the given date, and it MUST NOT mint tags under a future date. We
   take the date of assignment of an authority name to be the first day
   for which the assignment is held at midnight (00:00) UTC.

   Software that processes tags MUST count syntactically distinct tag
   authorities as unequal. Therefore, to prevent confusion, tag
   authorities SHOULD NOT issue tags of both ISO 8601 and tag date
   formats for the same day.

   An entity that acquires an authority name immediately after a period
   during which the name was unassigned MAY mint tags as if the entity
   was 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'

   For example, Hewlett-Packard holds the domain registration for
   hpl.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,t1 under domain names not registered to
   it. It must not mint tags dated in the future, such as
   tag:hpl.hp.com,t999. If it obtains assignment of
   extremelyunlikelytobeassigned.org on 2001-05-01, then it must not
   mint tags under extremelyunlikelytobeassigned.org,1 unless it has
   evidence proving that that name was continuously unassigned between
   2001- 01-01 and 2001-05-01.

   The general syntax of a 'tag' URI, in BNF, is:

         tagURI         ::= "tag:" tagAuthority [":" specific]

         tagAuthority  ::= authorityName "," date
         authorityName ::= DNSname | emailAddress
         date          ::= ISO8601Date | tagDate
         ISO8601Date   ::= 4*dig "-" dig dig "-" dig dig ;[ISO8601]
         DNSname       ::= DNScomp | DNSname "." DNScomp   ; [RFC 1035]
         DNScomp       ::= lowAlphaNum [*(lowAlphaNum |"-") lowAlphaNum]
         emailAddress  ::= 1*(lowAlphaNum |"-"|"."|"_") "@" DNSname
         lowAlphaNum   ::= dig | "a"|"b"| ... "y"|"z"  ; lwr case alphas
         tagDate       ::= year ["-" (monthNon1 | month "-" day)]
         year          ::= "t" digitNon0 [*dig]
         monthNon1     ::= digit2Plus | "10" | "11" | "12"
         month         ::= "1" | monthNon1
         day           ::= digit2Plus | ("1"|"2") dig | "30" |"31"
         dig           ::= "0" | digitNon0

Kindberg         Informational - Expires January 1, 2002        [Page 5]

Internet-Draft             The tag: URI scheme                 July 2001

         digitNon0     ::= "1" | digit2Plus
         digit2Plus    ::= "2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
         specific      ::= *(URIchars)  ; [RFC 2396]

   The component 'tagAuthority' is the name space part of the URI. This
   MUST be expressed in lower case. The domain name in 'authorityName'
   (whether an email address or a simple domain name) MUST be fully

   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 be 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 any string of valid URI characters [RFC2396] chosen by the
   minter of the URI. Specific identifiers MUST be single-valued: that
   is, all syntactically distinct 'specific' strings must correspond to
   distinct identifiers. It is RECOMMENDED that specific identifiers
   should be human- friendly.


   The tag syntax rules uniquely determine tag authority identifiers for
   any particular authority and date. Furthermore, specific identifiers
   are mandated to be single-valued.

   Therefore, two tag URIs are equal if and only if they are identical
   as character strings.


   Requirement 2 of Section 1 -- convenience for humans -- is met by the
   URL- like syntax for tag authorities. However, the onus is on
   individual naming authorities to use human-friendly specific

   Requirement 3 -- negligible costs -- follows from use of domain names
   and email addresses. Those identifiers are already held by many
   individuals and organisations and are cheap to obtain. Specific
   identifiers may be minted without communication with any other

Kindberg         Informational - Expires January 1, 2002        [Page 6]

Internet-Draft             The tag: URI scheme                 July 2001


   Requirement 4 -- independence of resolution schemes -- is asserted by
   definition. However, this state of affairs is subject to actual usage

   Requirement 1 specifies uniqueness over space and time. Tag URIs meet
   that requirement by using uniquely assigned authority names and by
   handling transfers of their assignment, e.g. the transfer of a domain
   name's registration from one entity to another. The date is used to
   guarantee uniqueness of 'tagAuthority' across assignments of the
   authority name.

   For example, suppose that on November 2, 2001, the champignon.net
   domain registration becomes assigned to a new entity. That entity
   must qualify the domain name with a date on which it is or was
   assigned to it, to ensure that its tag authority is and will remain
   unique. In particular, it must take care not to use defaults in such
   a way as to specify an earlier date. For example, the new assignee of
   champignon.net may use 't1-11-2' (equivalently, '2001-11-02'),
   't1-12' or 't2' (assuming it retains the assignment) but not 't1' or


   Minting a tag, by itself, is an operation internal to the minting
   entity with 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.


   Further information about the tag URI scheme -- motivation, genesis
   and discussion -- can be obtained from http://www.taguri.org.

Kindberg         Informational - Expires January 1, 2002        [Page 7]

Internet-Draft             The tag: URI scheme                 July 2001


   [DATETIME]  M. Wolf and C. Wicksteed (1998). Date and Time Formats,
               W3C Note. Revised 27 August 1998. This document is
   [DOI]       Norman Paskin (1997). Information Identifiers. Learned
               Publishing, Vol. 10, No. 2, pp. 135-156, April. See also
   [ISO11578]  ISO (International Organization for Standardization).
               ISO/IEC 11578:1996. "Information technology - Open
               Systems Interconnection - Remote Procedure Call (RPC)"
   [ISO8601]   ISO (International Organization for Standardization). ISO
               8601:1988. Data elements and interchange formats --
               Information interchange -- Representation of dates and
   [OID]       ITU-T recommendation X.208 (ASN.1). See also RFC 1778.
   [RFC822]    David H. Crocker (1982). Standard for the format of ARPA
               Internet text messages.
   [RFC1035]   P. Mocapetris (1987). Domain Names - implementation and
   [RFC2141]   R. Moats (1997). URN syntax.
   [RFC2396]   T. Berners-Lee, R. Fielding, L. Masinter (1998). Uniform
               Resource Identifiers (URI): Generic Syntax.
   [RFC3061]   M. Mealling (2001). A URN Namespace of Object
   [UUID]      Paul Leach, Rich Salz (1997). UUIDs and GUIDs. Internet-
               Draft Draft-leach-uuids-01.


   Tim Kindberg
   Hewlett-Packard Laboratories
   1501 Page Mill Road
   Palo Alto, CA 94304, USA
   Tel:   +1 650 857-5609
   Email: timothy@hpl.hp.com

   Sandro Hawke
   World Wide Web Consortium
   200 Technology Square
   Cambridge, MA 02139, USA
   Tel:   +1 617 253-7288
   Email: sandro@w3.org

Kindberg         Informational - Expires January 1, 2002        [Page 8]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/