Subject: durls and tibs: dated URLs as URNs

From: Larry Masinter <[email-masked]>
Date: Wed, 8 Aug 2001 16:01:18 -0700

This still needs some work, but since it's been bouncing around
as a meme for 3 years, I thought I would try writing it down.

It's probably a bad idea, but if so maybe you can help me figure
out why. (Is this the right list? [email-masked]?)

===============

INTERNET-DRAFT                                         Larry Masinter
draft-masinter-dated-url-00a.txt                       August 8, 2001
Expires February 2002

                 Two URN Namespaces based on dated URLs

Status of this Memo

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

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
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This document is not a product of any working group, but may be
discussed on the mailing list <[email-masked]>.

Abstract

This document defines a persistent namespace of URNs based on
prepending a date to an encoded URL. The result is a namespace that is
as easy to obtain as a URL, but which offers total persistance.

1. Introduction

Many people have wondered about how to create persistent identifiers
without registration. Some people have noted that cool URLs shouldn't
change. However, it isn't a good idea to design systems on the
assumption that other bits of design are uniformly implemented.

URLs are unique across all space, but not across all time. Domain
names can change, as can other pieces of identifying information.
Normally, library citations include date of publication so that the
context of the naming can be determined.

The first kind of URN takes the form:

     urn:durl:<date>:<encoded-URL>

where 'durl' means 'dated URL'; <date> is a digit string corresponding
to a date (and possibly time), and an <encoded-URL> is a URL where
every "/" and "%" is encoded in hex (as %2f and %25 respectively).
The meaning of a durl is "the resource that was identified by the
<encoded-URL> (after hex decoding) at the very first instant of the
date given".

For example, urn:durl:2001:http:%2f%2flarry.masinter.net is a
persistent identifier to 'http://larry.masinter.net' as of the very
first moment of the year 2001. Note that a durl isn't a resource
locator in any practical sense, because the time of location has
passed. However, is an acceptable resource identifier, and fulfills
all of the requirements for URNs.

The second kind of URN is a parallel space.  Many uses for URIs are
for objects or concepts that are not actually networked resources. For
this purpose, a second namespace is defined which designates the
"thing identified by" the resource at the given URL at the given
date. This URN namespace is described by 'tib', e.g.,

        urn:tib:<date>:<encoded-URL>

So urn:durl:2001:http:%%2f%2fwww.ietf.org can be used to designate the
Internet Engineering Task Force organization, at least as it was
constituted at the first instant of 2001.

2. "durl" URN Specification Template

  Namespace ID:
      "durl" requested.

  Registration Information:

      Registration Version: 1
      Registration Date: 2001-08-08

  Declared registrant of the namespace:
      Larry Masinter, <durl:2001:mailto:[email-masked]>

  Declaration of syntactic structure:

3. Dates

 A <date> is a date in the syntax of a subset of RFC 2550;
   date = year [ month [ day [ hour [ minute [ second [ fraction ]]]]]]
   year     = 4digit
   month    = 2digit
   day      = 2digit
   hour     = 2digit
   minute   = 2digit
   second   = 2digit
   fraction = *digit

   All dates and times MUST be relative to International Atomic Time
   (TAI) [NRAO].

4. Good practice

The meaning of a 'durl' is:

The resource that was (or will be) located by the given
URL at the very first instant of the given date and time.
For this purpose (as with RFC 2550), a date precedes every
other date for which it is a prefix.

Using dates in the future, before web servers were available
makes no sense and shouldn't be done.

Using URLs that weren't resolvable at the given time
isn't a good idea.

5. Community COnsiderations

The assignment of identifiers in the 'durl' and 'tib' namespaces are
completely open; anyone who can assign any sort of URI can assign
such a URN.

There are no accurate resolution servers for URNs in these namespaces;
however, the principles of operation are simple. 'tib' URNs are not
intended to be resolvable (ever), although resolution of the
corresponding 'durl' would give a resource that would indicate the
identity of the actual resource it identifies. Resolvers for 'durl'
identifiers with dates in the past require some archiving
service. Internet archives may be managed by anyone, and there are a
number of search engines that maintain some set of archives.

Clients without access to any resolution service can take the
decoded <encoded-URL> of a durl and attempt resolution of *that*
identifier. This will give an approximation whose reliability
depends to some degree on the amount of time elapsed.

6. IANA considerations

This document includes a URN NID registration that should
be entered into the IANA registry of URN NIDs.

7. Security Considerations

URLs don't contain enough information to supply the
authority for deciding what was or wasn't at a given
URL at a given date.

8. Acknowledgements

Many thanks to the many discussions on the relationship of URLs, URNs,
URIs and resource identifiers, as well as similar ideas, that have
been floated over the last many years.

9. Copyright

Copyright (C) The Internet Society, 1997. All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other
than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."

10. Author's addresses

          Larry Masinter
          Adobe Systems Incorporated
          345 Park Ave
          San Jose, CA 95110
          mailto: [email-masked]
          http://larry.masinter.net
          Tel: +1 408 536-3024

11. References

[RFC 2141] R. Moats, "URN Syntax", May 1997.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Aug 2001 20:25:24 -0400

I would like the tib to simply be a date, dns address and an opaque string.
I don't want to have to specify a protocol prefix to identify a thing that
is not going to be accesible by protocol.

If there has to be a URL involved we will still have the problem of people
insisting on being told the semantics of derefferencing the URL which is
precisely what I don't want anyone to be able to do.

I would like to be a bit more specific about the party that makes the
authoritative statement about the binding of the identifier. Since DNS names
have unique owners at given points in time, or at least are capable of being
bound to unique machines it should be possible to be a bit more specific.
This would help on the legal side.

Instead of tib I would prefer ddi for dated DNS identifier. 'Thing
identified' looks like an attempt to not use the words 'object' or
'resource'.

Also there are a couple of typos, urn:durl:2001:http:%2f%2f should be
urn:durl:2001:http%2e%2f%2f and urn:durl:2001:http:%%2f%2fwww.ietf.org
should be urn:durl:2001:http%2e%2f%2fwww.ietf.org [or the text is wrong]

I also have a need to be able to identify hierarchy within the identifier
for my applications (XKMS, XTASS, SAML) so that I can make assertions about
sets of related things.

<...>
   <Declare First="urn:ddi:xtass.xmltrustcenter.org/200108082202/AAAAEGIE"
                Last="urn:ddi:xtass.xmltrustcenter.org/200108082202/AAAAFEAB"
                Status="Valid" Terminal="True">

States that the assertions with identifiers in the specified interval are
Valid.

<...>
   <Declare Match="urn:ddi:xtass.xmldistrustcenter.org/*"
                Status="Invalid" Terminal="True">

States that all assertions issued by the distrust center are Invalid.

[BTW First, Last and Match ar of type string, not uriReference since they
specify a restricted regular expression that defines an interval of URIs.
Wildcards are only permitted at the end of the expression, the match is
segmented across the hierarchical boundaries]

With the tib and durl schemes I can't take advantage of any syntactic
similarity to group identifiers which in my application is a non-negotiable
requirement.

        Phill

> -----Original Message-----
> From: Larry Masinter [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2001 7:01 PM
> To: [email-masked]
> Subject: durls and tibs: dated URLs as URNs
>
>

---

From: Larry Masinter <[email-masked]>
Date: Thu, 9 Aug 2001 04:00:58 -0700

> I would like the tib to simply be a date, dns address and an opaque string.

I'm uncomfortable with making references that never were or will be
resolvable. In the case of 'tib', resolution is a matter of intent (which
I intend to elaborate in the next revision); the thing identified by a tib
is to be interpreted in the context of the intent of the corresponding
URL at the corresponding moment.

So urn:tib:2001:data:,the%20president%20of%20the%20United%20States could
refer to George Bush. It is "resolvable" in the sense that it is possible
to make a good guess about what the tib refers to. It may be uncertain,
but it isn't unambiguous.

If you only supply date, DNS and string, though, there can
be disagreements because there is no constraint about assignment.
You and I could both claim to assign completely different
semantics to the date "20010809", dns name "ietf.org" and
string "wonderful name space" and there would be no way to
differentiate these ever. There's no particular advantage
to those bits of data over just using random strings.

> I don't want to have to specify a protocol prefix to
> identify a thing that is not going to be accessible by protocol.

The protocol prefix is an essential part of the resolution
mechanism for both durl and tibs, albeit the resolution is
only reliably available with a time machine.

> precisely what I don't want anyone to be able to do.

I'm not sure why you want to insist on crippling people's
ability to ever know what you mean. In the case of durls and tibs,
the semantics of dereferencing the URL is clear; it accesses
now the resource that WAS the target (or description/identifier
of the target) at the given date.

> This would help on the legal side.

I'm uncomfortable with the assertion that DNS names have unique
owners at any given point in time; there are many cases of DNS
name disputes, DNS names whose listed owners are service providers
many steps removed from the actual location of intent.

The URI system is much more flexible than DNS, in that it allows
the kind of source of authority to migrate from DNS name to any other
kind of URI scheme.

(I'm going to avoid discussing the 'legal' side because of all of
the differing interpretations of intent in various jurisdictions.)

> identified' looks like an attempt to not use the words 'object' or

I think it's clear that we're solving different problems; I think
I'm a little clearer about what problem I'm solving (creating
a system of resource identifiers that have clear semantics that
do not change over time). I also think that durls and tibs might
be more useful in the context of RDF expressions and other uses
which want to replace ASN.1 OIDs with URIs but cannot find appropriate
URIs to use.

> should be urn:durl:2001:http%2e%2f%2fwww.ietf.org [or the text is wrong]

There is no need to escape the ":" in the URI. As far as URN syntax
goes, I confess that it is a stretch to say that the date is the naming
authority and the URL scheme is a delegated authority, but I don't think
that model is out of the question. On the other hand, URNs don't allow
"/" (although it might be useful).

I did make a mistake in the text, in not being explicit that all of
the <excluded> characters of URNs (section 2 of RFC 2141) which occur
within the referenced URL should all be escaped in the encoded-URL.

> for my applications (XKMS, XTASS, SAML) so that I can make assertions about

Well, RFC 2141 is clear that URNs do not admit hierarchy. If
you'd really solved the problems with hierarchy and URNs then
one might consider trying to update RFC 2141, but I think that
there are problems with your intended use of hierarchy (below).

> States that the assertions with identifiers in the specified interval are

You've gone substantially beyond hierarchies to also assume a
sorting order. I suppose this is OK, although you'll have to
be clearer.

> States that all assertions issued by the distrust center are Invalid.

You have an implicit universal quantifier, but you haven't stated
the scope. "All assertions" over what time period? Are statements
associated with that domain name in the year 2235 also invalid?
My impression is that most of these kind of assertions and inferences
based on them are valid only if there is a context that clearly
bounds the context, but the main power of URIs are that they retain
meaning when moved from one context to another.

> similarity to group identifiers which in my application is a non-negotiable

I agree that durls and tibs don't satisfy your requirements.
On the other hand,
(a) there are requirements that durls and tibs satisfy that
   ddis do not.
(b) I'm not sure the (implicit) requirements you've placed on
  ddis can be satisfied, e.g., that they can be used with regular
  expressions to make universally quantified assertions about
  sets of resources.

Larry
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Aug 2001 10:36:15 -0400

> be disagreements because there is no constraint about assignment.

I very much doubt that people would be using unstable domain
names for the purposes I am anticipating.

> to those bits of data over just using random strings.

But a court can resolve the issue with little difficulty.
The owner of the domain name www.citibank.com is not going
to be in much dispute.

The rule book of the exchange and membership agreements are
going to address the issue in any case.

Furthermore the courts will have less difficulty resolving
my proposal after the fact than yours.

> only reliably available with a time machine.

Quite.

> ability to ever know what you mean.

Because these are names and not locators. The meaning arises
from the usage.

> "/" (although it might be useful).

The text says to escape the colon. The double %% is wrong in any
case.

> there are problems with your intended use of hierarchy (below).

The only 'problems' were people. There is no ambiguity. The intention
was to prevent people doing entirely resonable things with the
identifiers.

If you have slashes they indicate a hierarchical structure. If that
causes problems for your scheme don't use them.

The statement in 2141 is a SHOULD NOT, the rationale is ideological.
The authors admit that they don't think they understand the reasoning,
so let them give way to folk who can.

I'll bet that nobody can state one bad thing that would happen if
the words SHOULD NOT were replaced by MAY. Other than the fact that
people could use fragments for the intended use.

Even in your intended application the ideology breaks your
use. If I have a page http://www.cnn.com/index then your construction
would be urn:durl:2001:http:%2f%2fwww.cnn.com%2findex
this would break all the internal links to no purpose.

If you object 'well the semantics of the links are captured', this
looks to me to be a reasonable thing to expect to happen if you give
a document two different identifiers.

If I have an identifier for the document on the date then it is
reasonable to also demand that relative URIs refer to the respective
documents on the respective dates.

If you want a cannonical form for the durl of a document then
specify a time interval rather than an instant. The time interval
would be the time the document was first published to the time when
it was replaced.

The ideological attempt to prevent URLs containing hierarchy has simply
caused that function to be transfered from the slash to the colon.

What I am considering doing is rewriting the XTASS draft to stipulate
that if you have a URN scheme you consider colons to be segment
identifiers in recgonition of this 'achievement'.

> sorting order. I suppose this is OK, although you'll have to

The paper is explicit on the point, the post is merely descriptive.

> associated with that domain name in the year 2235 also invalid?

No, because the assertion itself has a validity interval.

> meaning when moved from one context to another.

Its a Wittgenstein type name, the meaning is defined by the use.
There is no meaning outside the context.

                Phill

---

From: Larry Masinter <[email-masked]>
Date: Fri, 17 Aug 2001 14:29:41 -0700

I don't think there was closure on the discussion about
durls and tibs. I've been struggling to make a better
case for my discomfort with the common notion of using
a URN as an unbounded abstract "name" where the only
source of authority is "the owner of the domain name
at the time of assignment".

Let's suppose we had a "host" URL scheme:
  host:<dns-name>[ <path> ]

and then
  tib:<date>:host:<dns-name>[ <path> ]

would be the way that you could have a tib with the properties
you wanted.
> precisely what I don't want anyone to be able to do.

I've gone back and forth about renaming "tib" to "tdb": "thing described
by", that is, dereferencing the URL in a tib does give you something, it
gives you the description of the concept identified.

Now, getting the description in some unspecified format (HTML, text,
someone who might answer email) isn't actually useful in protocol
implementation, but it is useful in determining semantics.

> This would help on the legal side.

With tib/tdb, you don't need to get into the world of individuals
and responsibility, community web sites that are mantained by groups,
etc. DNS names don't really have "owners"; there's some registration
process that's managed by a domain administrator in many cases, but
it's often hard to decide "who". So I'd rather avoid all of that and
come up with an extrinsic reference rather than an intrinsic one,
"tdb" is a reader-relative reference rather than a writer-relative
reference.

> identified' looks like an attempt to not use the words 'object' or

Well, "tib" and "tdb" were somewhat tongue-in-cheek. I kind of like
durl since it's short. Dated URL-based Identifier, "durlbi".