W3C home > Mailing lists > Public > www-tag@w3.org > January 2011

Re: "tdb" and "duri" URI schemes...

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 18 Jan 2011 13:50:55 +0000
Message-ID: <AANLkTinDna4O6f134QSaHGuyaDRPZQt0LfXiuT7udbZO@mail.gmail.com>
To: Larry Masinter <masinter@adobe.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>
On Mon, Jan 17, 2011 at 10:38 PM, Larry Masinter <masinter@adobe.com> wrote:
> In the new version of
> http://tools.ietf.org/html/draft-masinter-dated-uri

A few little things (sorry I haven't done a full review)

   "Further, the
   date is not descriptive (an assertion about the URI) but merely
   refining."

This is a use/mention confusion. URIs are just strings and it's not
useful to assert anything about them (other than perhaps what their
syntactic components are). What you want to talk about is the
"resource" that the URI "identifies".  In this case you are talking
about a resource that is a "refinement" of the original.  The date in
the URI tells someone which of many refinements you might intend (i.e.
there are different refinements corresponding to different times).

I'm not sure what point you're trying to make here. I think it's that
the date does not reflect anything you might learn by looking at the
'representation(s)' or its provenance, e.g. when the (refined)
resource in question was created or composed - after all, it might
have been put on the web long after it was created - but rather when
that particular refinement was available on the web at the subject
URI.

(Pat Hayes suggested to me once that correcting use/mention confusions
is a lost cause, but I can't give it up.)

Similarly, you have:

      "URI scheme semantics:  A URI as of a particular time.  Semantics are
      described in detail in this document."

The URI is a string and therefore does not change over time.  You need
to say something like "A resource as of a particular time or more
explicitly "A duri: URI identifies a resource as of a particular
time."

This sentence:

   "permanent:  The meaning of the URI doens't change over time."

is disingenuous.  The sentence isn't true as a matter of fact, and
nobody has the authority to make it true. You might mean either of two
things: (a) *according to this URI scheme registration* the meaning
doesn't change (i.e. permanence is supported by your document - as
long as this registration is respected the URs will have "permanent"
meaning); or else (b) you *believe* that the scheme will be permanent,
based on some complex argument involving the known current ethics of
the IETF, the durability of those ethics, IETF's influential role in
the world's technical infrastructure, the likelihood that this
registration will survive any corruption of IETF, and the lack of any
currently foreseeable scenario in which the technical community might
want to change the meaning of these URIs.

The subtext is: "I (Masinter) think that these URIs are a better
permanence bet than some others, for some purposes, and I think you
should think this too." As you well know the persistence debate has
been hobbled by a failure to investigate the term deeply, and I don't
think you should feed the flames.

By the way I see that you use the two words "permanent" and
"persistent".  I think you use them synonymously. I suggest you stick
to just one of them - and define it at some point so that it's clear
what property you're talking about.

   "A 'duri' URI is not directly useful as a resource locator, since many
   resources vary their content over time."

I think you should say something about how DURIs are in principle no
better or worse as locators (whatever those are -- are you referring
to RFC 1736?) than any other kind of URI; you can use a service or
other technical apparatus to 'dereference' them.

That is, anything you can say against http: URIs - that they sometimes
don't resolve, that they're vulnerable to spoofing, that you don't
know whether what you got was 'authorized' - also applies to DURIs -
and vice versa, anything you can say *for* http: URIs - that they
sometimes do (or might) resolve, that you sometimes get the right
information - also applies to DURIs.  The only practical differences
are: (1) at the present time some http: URIs resolve while no DURIs
do, (2) the notion of "correct" resolution is different for the two
schemes (http: resolution is correct if the response is 'authorized'
while duri: relies on circumstances of past 'authority').

Section 9 'security considerations' doesn't make any sense to me.  First of all:

   "'tdb' identifiers are not any more reliable because they have dates."

True, but the introduction of a date provides an attacker with another
way to lie? A credulous client receiving a DURI could be misled into
believing something false about the past.

Then:

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

What was or wasn't at a given URI at a given date is a matter of fact,
not of authority, and facts about the past are ultimately unknowable.
If you want to determine whether or not a given 'representation'
belongs (belonged) to the refined resource 'identified' by a DURI,
then you are faced with a question of fact, for which you would need
to gather evidence, as in a court case or scientific study.  The
evidence and the resulting conclusions can only be assessed, not
"authorized".

Jonathan
Received on Tuesday, 18 January 2011 13:51:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:29 GMT