Re: FW: I-D ACTION:draft-masinter-dated-uri-03.txt

The functionality introduced by these forms is needed, they should go forward.

There are two decisions, however, in the definition of the time-stamping which merit some further consideration.  These have to do with the algorithm for value identification given a time interval, and the reference timebase.  

At present, time codes are [correctly] expanded to time intervals, and then the values that a URI-reference may have referred to during that time interval are selected among by the following rule:  

The value that was associated with the URI-reference *at the first point of time in the interval* is presently the value _indicated by the duri form of URN_ or _used as a stepping-stone in the tdb form_.  This is not user-safe.  People will coin lots of mis-coded URIs under this rule.  Never mind that the codes are assembled by [active] code.  That code is written by people who will erroneously implement this rule.  It's arbitrary in the present case to the point of capricious.  Violates strong conventions of existing usage in essentially the same application.

An alternative algorithm that matches colloquial use of dates for publications far better would be as follows:

- If the URI-reference took on one and only one value during the time interval, that is the value indicated by the date-qualified references.

- elseIf the URI-reference took on two values (including changing from noValue to someValue) during the time interval, it is the later, new value that is indicated.

- else the reference is ill-posed and the dated reference does not have a legal dereference value.

In other words, if the URI-reference encoded in either data-qualified form indicated more than two values during the time interval associated with the time code encoded in the reference, the result is the same as if the URI-reference never referred to anything during that time interval.  More detail must be added in the timestamp to indicate a smaller interval in order for the time-stamped reference to be valid.


This sounds complicated as an algorithm.  

But it will let things that are commonly referred to by date, as periodicals and almanacs and the like, be time-stamped with the same date as appears in their bibliographic identification without violating the encoding of the scheme.

One has to consider what the respective pain is of ruling a code illegal when the first-point rule would have resolved to the thing indended, vs. accepting by the first-point rule a value that was not intended.  Either kind of errors will happen, whichever definition we choose.   

Making a change in this clause may be necessary to get our coding scheme used right, enough, for people to recognize the value of using it.  The early adopters have to find themselves experiencing actual interoperability, or the network effect won't nucleate and the whole thing fizzles.

We could also lump the leap seconds, even if we don't like 'em, and use UTC, that people actually use, rather than ATI for the official clock.  For the same reasons.

Those are the functional questions, or suggestions for reconsideration.  This next just looks like a broken text:

There is a missing word (are?) in

<quote>

5.4 Resolution

   There no accurate resolution servers for duri or tdb URNs.  However,

</quote>

The machinable encoding has to work for machines, but all deviations from continuity with the human-comprehensible representation at the user interface are costly and we should try to minimize them.

I do hope that this goes forward.

Al


At 01:58 PM 2002-04-26 , you wrote:
>I hope I've addressed the comments I've gotten on this.
>If you said something and think I ignored you, please
>let me know, I might have lost some comments.
>
>I picked "uri@w3.org" as the main list to discuss this
>draft on for public comments.
>
>
>-----Original Message-----
>From: nsyracus@cnri.reston.va.us On Behalf Of Internet-Drafts@ietf.org
>Sent: Friday, April 26, 2002 5:14 AM
>To: IETF-Announce:
>Subject: I-D ACTION:draft-masinter-dated-uri-03.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
> Title : 'duri' and 'tdb': URN namespaces based on
>dated URIs
> Author(s) : L. Masinter
> Filename : draft-masinter-dated-uri-03.txt
> Pages : 20
> Date : 25-Apr-02
> 
>This document defines two namespaces of URNs, based on using a
>timestamp with an (encoded) URI.  The results are namespaces in which
>names are readily assigned, offer the persistence of reference that
>is required by URNs, but do not require a stable authority to assign
>the name.  The first namespace ('duri') is used to refer to URI-
>identified resources as they appeared at a particular time.  The
>second namespace ('tdb') is useful as a way of creating URNs that
>refer to physical objects or even abstractions that are not
>themselves networked resources.
>The definition of these namespaces may reduce the need to define new
>URN namespaces merely for the purpose of creating stable identifiers.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-03.txt
>
>To remove yourself from the IETF Announcement list, send a message to 
>ietf-announce-request with the word unsubscribe in the body of the
>message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the
>username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
> "get draft-masinter-dated-uri-03.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 

>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
> mailserv@ietf.org.
>In the body type:
> "FILE /internet-drafts/draft-masinter-dated-uri-03.txt".
> 
>NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail
>readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>

Received on Sunday, 28 April 2002 09:09:04 UTC