idnits 2.17.1 draft-masinter-dated-uri-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 203: '... encoded MAY include a fragment iden...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (October 22, 2010) is 4928 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Masinter 3 Internet-Draft Adobe 4 Intended status: Informational October 22, 2010 5 Expires: April 25, 2011 7 The 'tdb' and 'duri' URI schemes, based on dated URIs 8 draft-masinter-dated-uri-07 10 Abstract 12 This document defines two URI schemes. The first, 'duri' (standing 13 for "dated URI"), allows indicating a URI as of a particular date 14 (and time). This allows explicit reference to the "time of 15 retrieval", similar to the way in which bibliographic references 16 containing URIs are used. 18 The second scheme, 'tdb' ( standing for "Thing Described By"), 19 provides a way of using a way of minting URIs for anything that can 20 be described, with the ability to fix the description to a given date 21 or time. The 'tdb' URI scheme may reduce the need to define define 22 new URN namespaces merely for the purpose of creating stable 23 identifiers for concepts or abstractions: it provides a ready means 24 for identifying "non-information resources" by semantic indirection 25 -- a way of creating a URI for anything. 27 Note 29 This document is not a product of any working group. Many of the 30 ideas here have been discussed since 2001. This document has been 31 discussed on the mailing list . Previous versions have 32 couched 'tdb' and 'tdb' as URN namespaces. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 25, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Overview and Requirements . . . . . . . . . . . . . . . . . . 4 68 1.1. Persistent identifiers . . . . . . . . . . . . . . . . . . 4 69 1.2. URIs for abstractions . . . . . . . . . . . . . . . . . . 5 70 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1. 'duri' Syntax . . . . . . . . . . . . . . . . . . . . . . 6 72 2.2. tdb Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 73 2.3. encoded-URI encoding . . . . . . . . . . . . . . . . . . . 6 74 2.4. Timestamp syntax . . . . . . . . . . . . . . . . . . . . . 6 75 3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.1. 'duri' Semantics . . . . . . . . . . . . . . . . . . . . . 7 77 3.2. 'tdb' Semantics . . . . . . . . . . . . . . . . . . . . . 7 78 3.3. Timestamp Semantics . . . . . . . . . . . . . . . . . . . 8 79 4. Use as a Locator . . . . . . . . . . . . . . . . . . . . . . . 9 80 5. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6. Additional Considerations . . . . . . . . . . . . . . . . . . 9 82 6.1. Embedded URI schemes . . . . . . . . . . . . . . . . . . . 9 83 6.2. Useful timestamps . . . . . . . . . . . . . . . . . . . . 10 84 6.3. Free assignment . . . . . . . . . . . . . . . . . . . . . 11 85 6.4. Resolution . . . . . . . . . . . . . . . . . . . . . . . . 11 86 6.5. Why Names with Semantics? . . . . . . . . . . . . . . . . 11 87 6.6. Avoiding MetaData . . . . . . . . . . . . . . . . . . . . 11 88 6.7. Avoiding 'duri' and 'tdb' . . . . . . . . . . . . . . . . 12 89 6.8. 'tdb' and levels of indirection . . . . . . . . . . . . . 12 90 7. URI Specification Templates . . . . . . . . . . . . . . . . . 13 91 7.1. 'duri' Scheme Template . . . . . . . . . . . . . . . . . . 13 92 7.2. tdb Scheme Template . . . . . . . . . . . . . . . . . . . 13 93 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 98 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 1. Overview and Requirements 103 The URI schemes defined here address several related problems: 105 1.1. Persistent identifiers 107 [RFC1737] defines several requirements for Uniform Resource Names. 108 In particular, it requires "persistence": 110 Persistence: It is intended that the lifetime of a URN be 111 permanent. That is, the URN will be globally unique forever, and 112 may well be used as a reference to a resource well beyond the 113 lifetime of the resource it identifies or of any naming authority 114 involved in the assignment of its name. 116 Many people have wondered how to create globally unique and 117 persistent identifiers. There are a number of URI schemes and URN 118 namespaces already registered. However, an absolute guarantee of 119 both uniqueness and persistence is very difficult. 121 In some cases, the guarantee of persistence comes through a promise 122 of good management practice, such as is encouraged in "Cool URLs 123 don't change" [COOL]. However, relying on promise of good management 124 practice is not the same as having a design that guarantees 125 reliability independent of actual administrative practice. 127 A primary design goal for URIs is that they are intended to mean the 128 same thing, no matter in what context they appear: a "Uniform" way to 129 Identify a Resource. However, even when URIs have Uniform meaning 130 from the point of view of the source of the reference, they don't 131 guarantee stability over time. Despite best efforts and intentions, 132 identifying information can change in unpredictable ways: domain 133 names can disappear or be reassigned, name assigning organizations 134 can change structure, responsibility, disappear, merge, or change in 135 unpredictable ways. 137 There is a significant dependence in the interpretation of many URNs 138 with the concept of "naming authority". The authority is presumably 139 some individual or organization both to insure uniqueness of 140 assignment and also to help with understanding the meaning of the 141 link between the name and the named. 143 However, authorities, whether individuals or organizations, have a 144 lifetime, and must be consulted at some point to understand the 145 bindings. The functioning of names as unique identifiers and holders 146 of meaning depends on having a reliable infrastructure of consulting 147 the authority or the authorities records to determine the thing 148 referenced. 150 1.2. URIs for abstractions 152 The description of URIs [RFC3986] describes a range for 'Resource' 153 that is quite broad: 155 This specification does not limit the scope of what might be a 156 resource; rather, the term "resource" is used in a general sense 157 for whatever might be identified by a URI. Familiar examples 158 include an electronic document, an image, a source of information 159 with a consistent purpose (e.g., "today's weather report for Los 160 Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a 161 collection of other resources. A resource is not necessarily 162 accessible via the Internet; e.g., human beings, corporations, and 163 bound books in a library can also be resources. Likewise, 164 abstract concepts can be resources, such as the operators and 165 operands of a mathematical equation, the types of a relationship 166 (e.g., "parent" or "employee"), or numeric values (e.g., zero, 167 one, and infinity). 169 One might use a URI such as "mailto:" email address to identify a 170 person, or a "http:" URI to identify an abstract comment. However, 171 this leaves the question of how one might identify, within the same 172 context, both the system mailbox and the person to which it is 173 assigned, or the web page at a http URI and the concept it describes. 174 The 'tdb' URI scheme allows ready assignment of URIs for abstractions 175 that are distinguished from the media content that describes them. 177 The goal, then, of the 'tdb' URI scheme is to provide a mechanism 178 which is, at the same time: 180 permanent: The identity of the resource identified is not subject 181 to reinterpretation over time. 183 explicitly bound: The mechanism by which the identified resource 184 can be determined is explicitly included in the URI. 186 useful for non-networked items: Allows identification of resources 187 outside the network: people, organizations, abstract concepts. 189 no administration: The mechanism does not depend on reliable 190 administrative processes of authorities for either assignment or 191 interpretation. 193 2. Syntax 194 2.1. 'duri' Syntax 196 A 'duri' URI takes the form: 197 duri:: 199 where is s sequence of digits representing a date and 200 time (Section 2.4) and is an absolute URI-reference 201 [RFC3986] in which any reserved character other than "/" have been 202 percent-encoded (Section 2.3). Note that the URI which has been 203 encoded MAY include a fragment identifier. 205 2.2. tdb Syntax 207 A 'tdb' URI takes a similar form: 208 tdb:: 210 with the same syntax. 212 2.3. encoded-URI encoding 214 The following characters must be encoded within : 216 o The character "#" 217 Note that the URI encoded by can include a fragment 218 identifier; the "#" character used to delimit it must be encoded. 219 This feature is intended for use with 'tdb', where the fragment 220 identified might contain the description. Including an encoded 221 "#" with a 'duri' is not as useful, since the fragment identifier 222 might as well be applied to the 'duri' itself. 224 o The character "%" 225 The encoded-URI can itself contain encoded characters, which are 226 encoded with the same method. To insure that decoding happens at 227 the right level of processing, the "%" itself must be encoded. 228 Unfortunately, this means there are cases where there is a double 229 encoding of characters, first to construct the embedded URI itself 230 and second to then embed the URI within the 'tdb' or 'duri' URI. 232 2.4. Timestamp syntax 234 A timestamp in these URI schemes consists of a restricted subset of 235 date times, as per [RFC3339]. The goal is to allow relatively short 236 expressions with no ambiguity, but also with arbitrary precision. 238 timestamp = date [ "T" time "Z" ] 239 date =date-fullyear [ "-" date-month [ "-" date-mday ]] 240 time = time-hour [ ":" time-minute 241 [ ":" time-second [ time-secfrac ]]] 243 where non-terminals "date-fullyear", "date-month", "date-mday", 244 "time-hour", "time-minute", "time-second", "time-secfrac" are taken 245 from [RFC3339]. The goal was to minimize the amount of precision 246 needed, while retaining the possibility of generating timestamps that 247 are exactly compatible with [RFC3339] "date-time" non-terminal. 249 3. Semantics 251 3.1. 'duri' Semantics 253 It is traditional in convention references and citations in printed 254 works to include the date of publication; this practice serves the 255 important purpose that the context of the naming can be determined. 257 The meaning of a 'duri' URI is "the resource that was identified by 258 the (after hex decoding) at the date(time) given". 260 For example, "duri:2001:http://www.ietf.org" is a persistent 261 identifier to "http://www.ietf.org" as of 2001. A 'duri' URI may not 262 be a resource locator in a practical sense: the time of location has 263 not yet arrived or has passed. 265 3.2. 'tdb' Semantics 267 The 'tdb' URI scheme is intended to be useful for describing 268 entities, concepts, abstractions, and other items which may not 269 themselves be network accessible resources, but have been at some 270 point described by network accessible resources. 272 A 'tdb' URI is intended to be used where the identifies 273 a 'document' (something a person could read, peruse, understand) or a 274 fragment thereof, where the document describes some thing or concept. 275 The 'tdb' URI itself then identifies the subject of that document. 276 It is common practice to give a reference for a concept by including 277 a pointer to a document, segment, phrase that defines the concept; 278 'tdb' attempts to capture this practice in URI space. 280 For example, one might use "tdb:2008:http://www.ietf.org" as a 281 persistent identifier for the Internet Engineering Task Force, as 282 described by the "http://www.ietf.org" in 2008. 284 The 'tdb' URI scheme differs from other URI or URN methods for 285 identifying abstractions because the designation of what is actually 286 identified by the 'tdb' doesn't depend on knowing the intention of 287 the "assigner" of the identifier. Unlike "tag", "info", "cid", "mid" 288 or related schemes, the identification is not dependent on the 289 context of use. The 'tdb' URI scheme can be thought of as giving a 290 way to invoke a level of semantic indirection to URI resolution. 292 While one could imagine using 'tdb' without a date, it would leave 293 the possibility that a reference that is unambiguous at one time 294 might become ambiguous at some other time. There are two ways that 295 the date is useful for 'tdb' URIs: it fixes the time of access of the 296 resource, for variable descriptions, and it fixes the time of 297 interpretation, for descriptions whose meaning (in natural language) 298 might vary. 300 3.3. Timestamp Semantics 302 It is traditional in convention references and citations in printed 303 works to include the date of publication; this practice serves the 304 important purpose that the context of the naming can be determined. 306 While one could imagine using 'tdb' without a timestamp, it would 307 leave the possibility that a reference that is unambiguous at one 308 time might become ambiguous at some other time. There are two ways 309 that the date is useful for 'tdb': it fixes the time of access of the 310 resource, for variable descriptions, and it fixes the time of 311 interpretation, for descriptions whose meaning (in natural language) 312 might vary. While normally, in a literary work in natural language 313 which makes a reference to another work, both the reference itself 314 and the work referenced are dated, e.g., a footnote in an article 315 written in 1967 might talk about a "private communication" which 316 itself had a date. The difference between a URI and a conventional 317 literary reference is the desire to be able to extract the URI from 318 its context and still retain its meaning. 320 The meaning of a timestamp is the interval specified by the 321 granularity of the time range indicated, in the UTC time zone, as 322 described in [RFC3339]. If necessary, timestamps can include times 323 and even fractional times, so that a generator of 'duri' or 'tdb' 324 URIs can be arbitrarily precise. 326 If there is any ambiguity of the resource within the range of time 327 indicated (for example, if the timestamp consists only of a year, and 328 the resource changes over the course of the year), then the resource 329 state as of the very last instant of the range indicated should be 330 used. 332 Timestamps are allowed to be specified with as much precision as 333 needed. This keeps most 'duri' and 'tdb' URIs relatively short. 335 4. Use as a Locator 337 A 'duri' URI is not directly useful as a resource locator, since many 338 resources vary their content over time. 340 A 'tdb' URI is not a resource locator in a practical sense, since it 341 explicitly requires human interpretation. However, it allows one to 342 know that a resource was described at some point in time; whether the 343 description is still available, or whether that description is still 344 meaningful, is not guaranteed. 346 5. Hierarchy 348 For 'tdb', the "thing described by" a resource may bear little 349 relationship to the "thing described by" a relative pointer, so the 350 'tdb' URI scheme seems to have no use cases for using "/" as a 351 hierarchical delimiter. 353 However, 'duri' URIs can often be used with relative URI references 354 with some amount of reliability. Note, however, that double-encoding 355 of previously encoded URI characters will cause some problems. 357 6. Additional Considerations 359 6.1. Embedded URI schemes 361 The intent of 'duri' and 'tdb' is to use them with embedded URI 362 references that identify documents or document fragments. That is, 363 they are most useful for "information resources". 365 For example, use with a "http" URI can be used to refer to a web page 366 or the subject of a web as it was described at the given time. This 367 can be a way of referring to a web site at some time in the past, or 368 an organization that has changed, merged, split, or disappeared. 370 Local systems that have known-to-be unique host names can use "file" 371 URIs with 'tdb', for example, 373 tdb:20010814142327:file://this.example.com/c|/temp/test.txt 375 since this use is primarily focused on providing a unique way of 376 identifying an abstraction, even if the referent of the abstraction 377 is not widely known. (Using 'file:' URIs in this way without a fully 378 qualified domain name would not be appropriate, because the 379 interpretation is not uniform.) 380 One might consider using 'tdb' with a "data" URI to designate 381 concepts that can be described uniquely briefly inline. For example, 383 tdb:2001:data:,The%20US%20president 385 names the concept described by the (text/plain) string "The US 386 president" at the very last instant of 2001. Of course, this 387 practice is only useful if the referent of the data is (or was at the 388 time) completely unique. Since "data" does not contain a way to 389 designate content-language, the string in question would have to not 390 be ambiguous as to its language. In the case of 'data', there is no 391 assigning authority at all; the interpretation of the 'tdb' depend on 392 the interpreting community. 394 Using 'tdb' or 'duri' with an embedded 'urn:' might not seem to be 395 too useful, But it might be useful where the assignment of names in a 396 URN namespace are not, in practice, permanent, or that one might want 397 to refer to the assignment as of a given date. In this case, it is 398 possible to use a "urn" within a 'duri', e.g., 400 duri:2000:urn:ietf:std:50 402 might be used to refer to "the document that the IETF considered to 403 be STD 50, as of the last instant of 2000". 405 For 'tdb', many URIs identify resources which do not clearly describe 406 anything at all. The "home page" for an organization isn't nearly as 407 good a resource to use to describe an organization as the 408 organization's "about" page. But it is up to the minter of the 'tdb' 409 URI to choose wisely. 411 6.2. Useful timestamps 413 Timestamps far in the future are suspect, because the future content 414 of a description resource cannot usually be reliably predicted. 415 Timestamps which preceed the availability of the description resource 416 should not be used either. For example, using a http URI with a 417 timestamp before the description resource is also not recommended. 419 However, although these practices are not recommended, there is no 420 assurance that they haven't been used; by itself, a 'tdb' URI by 421 itself does not constitute an assertion that the description resource 422 was available or assigned at the date specified. 424 Note that the use of the "very last instant" allows for the 425 conventional bibliographic convention that a work published in 2009 426 can use "2009" as the date string, to refer to the work in the year 427 of publication. 429 6.3. Free assignment 431 Because of the many possible schemes that can be used in the 432 portion, there should be no difficulty in almost any 433 computational process being able to assign 'duri' or 'tdb' URIs at 434 will. Of course, it is necessary for there to be some resource which 435 is available at some point in time, and to have a clock which is 436 accurate to the granularity of the frequency of assignment. 438 6.4. Resolution 440 There are no direct resolution servers or processes for 'duri' or 441 'tdb' URIs. However, a 'duri' URI might be "resolvable" in the sense 442 that a resource that was accessed at a point in time might have the 443 result of that access cached or archived in an Internet archive 444 service. See, for example, the "Internet Archive" project [archive]. 445 And a 'tdb' URI is "resolvable" in the sense that the description 446 resource can be accessed and interpreted. 448 Clients without access to an Internet archive service might take the 449 decoded of a 'duri' and attempt resolution of *that* 450 identifier. This will give an approximation whose reliability 451 depends on the what has happened in the time since the date 452 indicated. 454 6.5. Why Names with Semantics? 456 There are a number of URI and URN schemes that create otherwise 457 unbound "names", where the scheme only provides for uniqueness, with 458 some other agent or process or context providing the authority to 459 interpret the meaning of the identifier at some point in the future. 460 'duri' and 'tdb' is different, in that it is the agreement between 461 the describer (the agent creating the URI) and the receiver of the 462 URI (the agent interpreting the URI) to agree upon the semantics 463 without any reference to any third party. 465 6.6. Avoiding MetaData 467 One might consider the timestamp in a 'duri' or 'tdb' URI to be just 468 one piece of additional metadata about the URI, and consider adding 469 other pieces of metadata as annotation. 471 However, the use of the timestamp is intended primarily as a 472 mechanism of accomplishing uniqueness over time. No other bit of 473 metadata or description readily fills that purpose. Further, the 474 date is not descriptive (an assertion about the URI) but merely 475 refining. 477 6.7. Avoiding 'duri' and 'tdb' 479 Many applications of URIs already provide a context of timestamp. 480 For example, one could imagine a hypertext system where the URIs 481 contained within a document were intended to refer to the resources 482 as of the date of the enclosing document. This would be a reasonable 483 interpretation of URIs within an Internet archive system, for 484 example. 486 Some applications of URIs already implicitly use the level of 487 interpretive indirection that is explicit with 'tdb', For example, 488 within an ontology language definition, the URIs used for abstract 489 concepts, individuals and so forth are generally considered the 490 "thing described by" the URI. 492 In addition, the 'application/rdf+xml' Media Type [RFC3870] uses the 493 fragment identifier resolution as an explicit way of identifying 494 abstract concepts that are described by an RDF document. 496 6.8. 'tdb' and levels of indirection 498 The 'tdb' scheme introduces a level of semantic indirection. The 499 puzzles and confusions about use and mention, name and reference, and 500 levels of indirection have been puzzling and amusing for quite a 501 while. 503 "It's long," said the Knight, "but it's very, very beautiful. 504 Everybody that hears me sing it--either it brings tears into their 505 eyes, or else--" 506 "Or else what?" said Alice, for the Knight had made a sudden 507 pause. 508 "Or else it doesn't, you know. The name of the song is called 509 'Haddock's Eyes.'" 510 "Oh, that's the name of the song, is it?" Alice said, trying to 511 feel interested. 512 "No, you don't understand," the knight said, looking a little 513 vexed. "That's what the name is called. The name really is 'The 514 Aged Aged Man.'" 515 "Then I ought to have said 'That's what the song is called'?" 516 Alice corrected herself. 517 "No, you oughtn't: that's quite another thing! The song is called 518 'Ways and Means': but that's only what it's called, you know!" 519 "Well, what is the song, then?" said Alice, who was by this time 520 completely bewildered. 521 "I was coming to that," the Knight said. "The song really is 522 'A-sitting On A Gate': and the tune's my own invention." [LOOK] 524 7. URI Specification Templates 526 7.1. 'duri' Scheme Template 528 URI scheme name: duri 530 Status: permanent 532 URI scheme syntax: Briefly, the syntax is 533 tdb:: 534 The syntax is described in this document. 536 URI scheme semantics: A URI as of a particular time. Semantics are 537 described in detail in this document. 539 Encoding considerations: 'duri' URIs consist of a prefix followed by 540 another URI, and should have the same encoding considerations as 541 others. Note discussion of double-encoding. 543 Applications/protocols that use this URI scheme name: Limited: this 544 scheme was originally developed as a "thought experiment", 545 although there is some discussion of using it with Memento 546 [MEMENTO]. 548 Interoperability considerations: The actual interoperability with 549 Internet archiving services needs further exploration. 551 Security considerations: See Section 9 of this document. 553 Contact: Larry Masinter tdb:2010:http://larry.masinter.net 555 Author/Change controller: as above 557 References: See References of this document. 559 7.2. tdb Scheme Template 561 URI scheme name: tdb 563 Status: permanent 565 URI scheme syntax: Briefly, the syntax is 566 tdb:: 567 The syntax is described in this document. 569 URI scheme semantics: Semantic indirection at indicated date. 570 Semantics are described in detail in this document. 572 Encoding considerations: 'tdb' URIs consist of a prefix followed by 573 another URI, and should have the same encoding considerations as 574 others. Note discussion of double-encoding possibilities. 576 Applications/protocols that use this URI scheme name: Limited: This 577 scheme was originally designed as a "thought experiment", as a way 578 resolve some of the use/mention ambiguities in semantic web 579 applications that wish to "denote" concepts and other ideas and 580 not just access resources over the Internet. 582 Interoperability considerations: Existing semantic web applications 583 may have other means of fixing meaning at a particular time or 584 semantic indirection, and do not fix description by time. 586 Security considerations: See Section 9 of this document. 588 Contact: Larry Masinter tdb:2010:http://larry.masinter.net 590 Author/Change controller: as above 592 References: See References of this document. 594 8. IANA considerations 596 This document includes two URI scheme registrations (Section 7 that 597 should be entered into the IANA registry of URI schemes as a 598 permanent registration (once approved). 600 9. Security Considerations 602 'tdb' identifiers are not any more reliable because they have dates. 603 URIs don't contain enough information to supply the authority for 604 deciding what was or wasn't at a given URI at a given date. 606 10. Acknowledgements 608 There have been many discussions over several years on the 609 relationship of URLs, URNs, URIs, resources and resource identifiers, 610 with many contributions. Particular thanks to Alfred Hines, Herbert 611 Van de Sompel, Al Gilman, Aaron Swartz, Brian McBride, Stuart 612 Williams, Michael Mealling, Ray Denenberg and Pat Hayes. 614 11. References 616 11.1. Normative References 618 [RFC3339] Klyne, G. and C. Newman, "Date an Time on the Internet: 619 Timestamps", RFC 3339, July 2002. 621 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 622 Resource Identifiers (URI): Generic Syntax", RFC 3986, 623 January 2005. 625 [namespaces] 626 Bray, T., Hollander, D., and A. Layman, "Namespaces in 627 XML", W3C Recommendation REC-xml-names, January 1999, 628 . 630 11.2. Informative References 632 [COOL] Berners-Lee, T., "Cool URIs don't change", 1998, 633 . 635 [LOOK] Carroll, L., "Through the Looking Glass", 1872, . 639 [MEMENTO] Memento Development Group, "Memento: Adding Time to the 640 Web", 2010, . 642 [RFC1737] Sollins, K., "Functional Requirements for Uniform Resource 643 Names", RFC 1737, December 1994. 645 [RFC3870] Swartz, A., "application/rdf+xml Media Type Registration", 646 RFC 3870, September 2004. 648 [archive] Kahle, B., "Preserving the Internet", Scientific 649 American , March 1997, 650 . 652 Author's Address 654 Larry Masinter 655 Adobe 656 345 Park Ave 657 San Jose, CA 95110 658 US 660 Phone: +1 408 536 3024 661 Email: LMM@acm.org 662 URI: http://larry.masinter.net