idnits 2.17.1 draft-kindberg-tag-uri-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 465. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 395 has weird spacing: '...tes and time...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 31, 2005) is 7018 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- No information found for draft-leach-uuids - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1778 (ref. '7') (Obsoleted by RFC 3494) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Kindberg 3 Internet-Draft Hewlett-Packard Corporation 4 Expires: August 4, 2005 S. Hawke 5 World Wide Web Consortium 6 January 31, 2005 8 The 'tag' URI scheme 9 draft-kindberg-tag-uri-07 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 4, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes the "tag" Uniform Resource Identifier (URI) 45 scheme. Tag URIs (also known as "tags") are designed to be unique 46 across space and time while being tractable to humans. They are 47 distinct from most other URIs in that there is no authoritative 48 resolution mechanism. A tag may be used purely as an entity 49 identifier. Furthermore, using tags has some advantages over the 50 common practice of using "http" URIs as identifiers for 51 non-HTTP-accessible resources. 53 Terminology 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119. 59 Disclaimer 61 The views and opinions of authors expressed herein do not necessarily 62 state or reflect those of the World Wide Web Consortium, and may not 63 be used for advertising or product endorsement purposes. This 64 proposal has not undergone technical review within the Consortium and 65 must not be construed as a Consortium recommendation. 67 Further Information and Discussion of this Document 69 Information about the tag URI scheme additional to this document -- 70 motivation, genesis and discussion -- can be obtained from 71 http://www.taguri.org. 73 Earlier drafts of this document have been discussed on uri@w3.org. 74 The authors welcome further discussion and comments. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Tag Syntax and Rules . . . . . . . . . . . . . . . . . . . . . 5 80 2.1 Tag Syntax and Examples . . . . . . . . . . . . . . . . . 5 81 2.2 Rules for Minting Tags . . . . . . . . . . . . . . . . . . 6 82 2.3 Resolution of Tags . . . . . . . . . . . . . . . . . . . . 8 83 2.4 Equality of Tags . . . . . . . . . . . . . . . . . . . . . 8 84 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 5.1 Normative References . . . . . . . . . . . . . . . . . . . 10 88 5.2 Informative References . . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 90 Intellectual Property and Copyright Statements . . . . . . . . 12 92 1. Introduction 94 A tag is a type of Uniform Resource Identifier (URI) [1] designed to 95 meet the following requirements: 97 1. Identifiers are likely to be unique across space and time, and 98 come from a practically inexhaustible supply. 99 2. Identifiers are relatively convenient for humans to mint 100 (create), read, type, remember etc. 101 3. No central registration is necessary, at least for holders of 102 domain names or email addresses; and there is negligible cost to 103 mint each new identifier. 104 4. The identifiers are independent of any particular resolution 105 scheme. 107 For example, the above requirements may apply in the case of a user 108 who wants to place identifiers on their documents: 110 a. The user wants to be reasonably sure that the identifier is 111 unique. Global uniqueness is valuable because it prevents 112 identifiers from becoming unintentionally ambiguous. 113 b. The identifiers should be tractable to the user, who should, for 114 example, be able to mint new identifiers conveniently, to 115 memorise them, and to type them into emails and forms. 116 c. The user does not want to have to communicate with anyone else in 117 order to mint identifiers for their documents. 118 d. The user wants to avoid identifiers that might be taken to imply 119 the existence of an electronic resource accessible via a default 120 resolution mechanism, when no such electronic resource exists. 122 Existing identification schemes satisfy some but not all of the 123 requirements above. For example: 125 UUIDs [5], [6] are hard for humans to read. 127 OIDs [7], [8] and Digital Object Identifiers [9] require entities to 128 register as naming authorities, even in cases where the entity 129 already holds a domain name registration. 131 URLs (in particular, "http" URLs) are sometimes used as identifiers 132 that satisfy most of the above requirements. Many users and 133 organisations have already registered a domain name, and the use of 134 the domain name to mint identifiers comes at no additional cost. But 135 there are drawbacks to URLs-as-identifiers: 137 o An attempt may be made to resolve a URL-as-identifier, even though 138 there is no resource accessible at the "location". 139 o Domain names change hands and the new assignee of a domain name 140 can't be sure that they are minting new names. For example, if 141 example.org is assigned first to a user Smith and then to a user 142 Jones, there is no systematic way for Jones to tell whether Smith 143 has already used a particular identifier such as 144 http://example.org/9999. 145 o Entities could rely on purl.org or a similar service as a 146 (first-come, first-served) assigner of unique URIs; but a solution 147 without reliance upon another entity such as the Online Computer 148 Library Center (OCLC, which runs purl.org) may be preferable. 150 Lastly, many entities -- especially individuals -- are assignees of 151 email addresses but not domain names. It would be preferable to 152 enable those entities to mint unique identifiers. 154 2. Tag Syntax and Rules 156 This section first specifies the syntax of tag URIs and gives 157 examples. It then describes a set of rules for minting tags designed 158 to make them unique. Finally, it discusses the resolution and 159 comparison of tags. 161 2.1 Tag Syntax and Examples 163 The general syntax of a tag URI, in ABNF [2], is: 165 tagURI = "tag:" taggingEntity ":" specific [ "#" fragment ] 167 Where: 169 taggingEntity = authorityName "," date 170 authorityName = DNSname / emailAddress 171 date = year ["-" month ["-" day]] 172 year = 4DIGIT 173 month = 2DIGIT 174 day = 2DIGIT 175 DNSname = DNScomp *( "." DNScomp ) ; see RFC 1035 [3] 176 DNScomp = alphaNum [*(alphaNum /"-") alphaNum] 177 emailAddress = 1*(alphaNum /"-"/"."/"_") "@" DNSname 178 alphaNum = DIGIT / ALPHA 179 specific = *( pchar / "/" / "?" ) ; pchar from RFC 3986 [1] 180 fragment = *( pchar / "/" / "?" ) ; same as RFC 3986 [1] 182 The component "taggingEntity" is the name space part of the URI. To 183 avoid ambiguity, the domain name in "authorityName" (whether an email 184 address or a simple domain name) MUST be fully qualified. It is 185 RECOMMENDED that the domain name should be in lowercase form. 186 Alternative formulations of the same authority name will be counted 187 as distinct and hence tags containing them will be unequal (see 188 Section 2.4). For example, tags beginning "tag:EXAMPLE.com,2000:" 189 are never equal to those beginning "tag:example.com,2000:", even 190 though they refer to the same domain name. 192 Authority names could, in principle, belong to any syntactically 193 distinct namespaces whose names are assigned to a unique entity at a 194 time. Those include, for example, certain IP addresses, certain MAC 195 addresses, and telephone numbers. However, to simplify the tag 196 scheme, we restrict authority names to be domain names and email 197 addresses. Future standards efforts may allow use of other authority 198 names following syntax that is disjoint from this syntax. To allow 199 for such developments, software that processes tags MUST NOT reject 200 them on the grounds that they are outside the syntax defined above. 202 The component "specific" is the name-space-specific part of the URI: 203 it is a string of URI characters (see restrictions in syntax 204 specification) chosen by the minter of the URI. Note that the 205 "specific" component allows for "query" subcomponents as defined in 206 RFC 3986 [1]. It is RECOMMENDED that specific identifiers should be 207 human-friendly. 209 Tag URIs may optionally end in a fragment identifier, in accordance 210 with the general syntax of RFC 3986 [1]. 212 In the interests of tractability to humans, tags SHOULD NOT be minted 213 with percent-encoded parts. However, the tag syntax does allow 214 percent-encoded characters, in the "pchar" elements (defined in RFC 215 3986 [1]). 217 Examples of tag URIs are: 219 tag:timothy@hpl.hp.com,2001:web/externalHome 220 tag:sandro@w3.org,2004-05:Sandro 221 tag:my-ids.com,2001-09-15:TimKindberg:presentations:UBath2004-05-19 222 tag:blogger.com,1999:blog-555 223 tag:yaml.org,2002:int 225 2.2 Rules for Minting Tags 227 As Section 2.1 has specified, each tag includes a "tagging entity" 228 followed, optionally, by a specific identifier. The tagging entity 229 is designated by an "authority name" -- a fully qualified domain name 230 or an email address containing a fully qualified domain name -- 231 followed by a date. The date is chosen to make the tagging entity 232 globally unique, exploiting the fact that domain names and email 233 addresses are assigned to at most one entity at a time. That entity 234 then ensures that it mints unique identifiers. 236 The date specifies, according to the Gregorian calendar and UTC, any 237 particular day on which the authority name was assigned to the 238 tagging entity at 00:00 UTC (the start of the day). The date MAY be 239 a past or present date on which the authority name was assigned at 240 that moment. The date is specified using one of the "YYYY", 241 "YYYY-MM" and "YYYY-MM-DD" formats allowed by the ISO 8601 standard 242 [4] (see also RFC 3339 [10]). The tag specification permits no other 243 formats. Tagging entities MUST ascertain the date with sufficient 244 accuracy to avoid accidentally using a date on which the authority 245 name was not in fact assigned (many computers and mobile devices have 246 poorly synchronised clocks). The date MUST be reckoned from UTC -- 247 which may differ from the date in the tagging entity's local timezone 248 at 00:00 UTC. That distinction can generally be safely ignored in 249 practice, but not on the day of the authority name's assignment. In 250 principle it would otherwise be possible on that day for the previous 251 assignee and the new assignee to use the same date and thus mint the 252 same tags. 254 In the interests of brevity, the month and day default to "01". A 255 day value of "01" MAY be omitted; a month value of "01" MAY be 256 omitted unless it is followed by a day value other than "01". For 257 example, "2001-07" is the date 2001-07-01 and "2000" is the date 258 2000-01-01. All date formulations specify a moment (00:00 UTC) of a 259 single day, and not a period of a day or more such as "the whole of 260 July 2001" or "the whole of 2000". Assignment at that moment is all 261 that is required to use a given date. 263 Tagging entities should be aware that alternative formulations of the 264 same date will be counted as distinct and hence tags containing them 265 will be unequal. For example, tags beginning "tag:example.com,2000:" 266 are never equal to those beginning "tag:example.com,2000-01-01:", 267 even though they refer to the same date (see Section 2.4). 269 An entity MUST NOT mint tags under an authority name that was 270 assigned to a different entity at 00:00 UTC on the given date, and it 271 MUST NOT mint tags under a future date. 273 An entity that acquires an authority name immediately after a period 274 during which the name was unassigned MAY mint tags as if the entity 275 was assigned the name during the unassigned period. This practice 276 has considerable potential for error and MUST NOT be used unless the 277 entity has substantial evidence that the name was unassigned during 278 that period. The authors are currently unaware of any mechanism that 279 would count as evidence, other than daily polling of the "whois" 280 registry. 282 For example, Hewlett-Packard holds the domain registration for hp.com 283 and may mint any tags rooted at that name with a current or past date 284 when it held the registration. It must not mint tags such as 285 "tag:champignon.net,2001:" under domain names not registered to it. 286 It must not mint tags dated in the future, such as 287 "tag:hp.com,2999:". If it obtains assignment of 288 "extremelyunlikelytobeassigned.org" on 2001-05-01, then it must not 289 mint tags under "extremelyunlikelytobeassigned.org,2001-04-01" unless 290 it has evidence proving that that name was continuously unassigned 291 between 2001-04-01 and 2001-05-01. 293 A tagging entity mints specific identifiers that are unique within 294 its context, in accordance with any internal scheme that uses only 295 URI characters. Tagging entities SHOULD use record-keeping 296 procedures to achieve uniqueness. Some tagging entities (e.g. 297 corporations, mailing lists) consist of many people, in which case 298 group decision-making SHOULD also be used to achieve uniqueness. The 299 outcome of such decision-making could be to delegate control over 300 parts of the namespace. For example, the assignees of example.com 301 could delegate control over all tags with the prefixes 302 tag:example.com,2004:fred: and tag:example.com,2004:bill: 303 respectively to the individuals with internal names "fred" and "bill" 304 on 2004-01-01. 306 2.3 Resolution of Tags 308 There is no authoritative resolution mechanism for tags. Unlike most 309 other URIs, tags can only be used as identifiers, and are not 310 designed to support resolution. If authoritative resolution is a 311 desired feature, a different URI scheme should be used. 313 2.4 Equality of Tags 315 Tags are simply strings of characters and are considered equal if and 316 only if they are completely indistinguishable in their machine 317 representations when using the same character encoding. That is, one 318 can compare tags for equality by comparing the numeric codes of their 319 characters, in sequence, for numeric equality. This criterion for 320 equality allows for simplification of tag-handling software, which 321 does not have to transform tags in any way to compare them. 323 3. Security Considerations 325 Minting a tag, by itself, is an operation internal to the tagging 326 entity with no external consequences. The consequences of using an 327 improperly minted tag (due to malice or error) in an application 328 depends on the application, and must be considered in the design of 329 any application that uses tags. 331 There is a significant possibility of minting errors by people who 332 fail to apply the rules governing dates, or who use a shared 333 (organizational) authority-name without prior organization-wide 334 agreement. Tag-aware software MAY help catch and warn against these 335 errors. As stated in Section 2, however, to allow for future 336 expansion, software MUST NOT reject tags which do not conform to the 337 syntax specified in Section 2. 339 A malicious party could make it appear that the same domain name or 340 email address was assigned to each of two or more entities. Tagging 341 entities SHOULD use reputable assigning authorities, and verify 342 assignment wherever possible. 344 Entities SHOULD also avoid the potential for malicious exploitation 345 of clock skew, by using authority names that were assigned 346 continuously from well before to well after 00:00 UTC on the date 347 chosen for the tagging entity -- preferably by intervals in the order 348 of days. 350 4. IANA Considerations 352 The IANA is asked to register the tag URI scheme as specified in this 353 document and summarised in the following template: 355 URI scheme name: tag 357 Status: permanent 359 URI scheme syntax: see Section 2 361 Character encoding considerations: percent-encoding is allowed in 362 'specific' and 'fragment' components (see Section 2) 364 Intended usage: see Section 1 and Section 2.3 366 Applications and/or protocols that use this URI scheme name: Any 367 applications that use URIs as identifiers without requiring 368 dereference, such as RDF, YAML, and Atom. 370 Interoperability considerations: none 372 Security considerations: see Section 3 374 Relevant publications: none 376 Contact: Tim Kindberg (timothy@hpl.hp.com) and Sandro Hawke 377 (sandro@w3.org) 379 Author/Change controller: Tim Kindberg and Sandro Hawke 381 5. References 383 5.1 Normative References 385 [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 386 Identifier (URI): Generic Syntax", RFC 3986, January 2005. 388 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 389 Specifications: ABNF", RFC 2234, November 1997. 391 [3] Mockapetris, P., "Domain names - implementation and 392 specification", STD 13, RFC 1035, November 1987. 394 [4] "Data elements and interchange formats -- Information 395 interchange -- Representation of dates and times", ISO 396 (International Organization for Standardization) ISO 8601:1988, 397 1988. 399 5.2 Informative References 401 [5] Leach, P. and R. Salz, "UUIDs and GUIDs", 402 Internet-Draft draft-leach-uuids-01, 1997. 404 [6] "Information technology - Open Systems Interconnection - Remote 405 Procedure Call (RPC)", ISO (International Organization for 406 Standardization) ISO/IEC 11578:1996, 1996. 408 [7] "Specification of abstract syntax notation one (ASN.1)", ITU-T 409 recommendation X.208, (see also RFC 1778), 1988. 411 [8] Mealling, M., "A URN Namespace of Object Identifiers", 412 RFC 3061, February 2001. 414 [9] Paskin, N., "Information Identifiers", Learned Publishing Vol. 415 10, No. 2, pp. 135-156, (see also www.doi.org), April 1997. 417 [10] Klyne, G. and C. Newman, "Date and Time on the Internet: 418 Timestamps", RFC 3339, July 2002. 420 Authors' Addresses 422 Tim Kindberg 423 Hewlett-Packard Corporation 424 Hewlett-Packard Laboratories 425 Filton Road 426 Stoke Gifford 427 Bristol BS34 8QZ 428 UK 430 Phone: +44 117 312 9920 431 Email: timothy@hpl.hp.com 433 Sandro Hawke 434 World Wide Web Consortium 435 32 Vassar Street 436 Building 32-G508 437 Cambridge, MA 02139 438 USA 440 Phone: +1 617 253-7288 441 Email: sandro@w3.org 443 Intellectual Property Statement 445 The IETF takes no position regarding the validity or scope of any 446 Intellectual Property Rights or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; nor does it represent that it has 450 made any independent effort to identify any such rights. Information 451 on the procedures with respect to rights in RFC documents can be 452 found in BCP 78 and BCP 79. 454 Copies of IPR disclosures made to the IETF Secretariat and any 455 assurances of licenses to be made available, or the result of an 456 attempt made to obtain a general license or permission for the use of 457 such proprietary rights by implementers or users of this 458 specification can be obtained from the IETF on-line IPR repository at 459 http://www.ietf.org/ipr. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 463 rights that may cover technology that may be required to implement 464 this standard. Please address the information to the IETF at 465 ietf-ipr@ietf.org. 467 Disclaimer of Validity 469 This document and the information contained herein are provided on an 470 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 471 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 472 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 473 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 474 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 475 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 477 Copyright Statement 479 Copyright (C) The Internet Society (2005). This document is subject 480 to the rights, licenses and restrictions contained in BCP 78, and 481 except as set forth therein, the authors retain all their rights. 483 Acknowledgment 485 Funding for the RFC Editor function is currently provided by the 486 Internet Society.