Re: [Uri-review] draft-masinter-dated-uri-06

Larry Masinter <masinter@adobe.com> Fri, 22 October 2010 23:27 UTC

Return-Path: <masinter@adobe.com>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1313A67D1 for <uri-review@core3.amsl.com>; Fri, 22 Oct 2010 16:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMF8XUpTc9uN for <uri-review@core3.amsl.com>; Fri, 22 Oct 2010 16:27:50 -0700 (PDT)
Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by core3.amsl.com (Postfix) with ESMTP id 5E7A33A67AF for <uri-review@ietf.org>; Fri, 22 Oct 2010 16:27:49 -0700 (PDT)
Received: from source ([192.150.8.22]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKTMIeVEWaQKJY6A+mfqTAQzqB8P9AwVQ7@postini.com; Fri, 22 Oct 2010 16:29:29 PDT
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o9MNTMfx022370; Fri, 22 Oct 2010 16:29:22 -0700 (PDT)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id o9MNTLZm028031; Fri, 22 Oct 2010 16:29:21 -0700 (PDT)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Fri, 22 Oct 2010 16:29:19 -0700
From: Larry Masinter <masinter@adobe.com>
To: Alfred HÎnes <ah@TR-Sys.de>
Date: Fri, 22 Oct 2010 16:29:18 -0700
Thread-Topic: draft-masinter-dated-uri-06
Thread-Index: Aco8ijxmh8OhK8k1Sq2nlrnFvNDYZk1tiC9A
Message-ID: <C68CB012D9182D408CED7B884F441D4D0476B4FD29@nambxv01a.corp.adobe.com>
References: <200909232008.WAA06116@TR-Sys.de>
In-Reply-To: <200909232008.WAA06116@TR-Sys.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "uri-review@ietf.org" <uri-review@ietf.org>, Herbert van de Sompel <hvdsomp@gmail.com>
Subject: Re: [Uri-review] draft-masinter-dated-uri-06
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Oct 2010 23:27:52 -0000

It's been quite a while, but I have finally submitted 
-07 of this document, putting back in 'duri' (since
I was asked to revive it) as well as changing from 
TAI to using a variant of RFC 3339.

It's been so long that I've probably dropped the ball on several
things here....



-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] 
Sent: Friday, October 22, 2010 4:23 PM
To: lmm@acm.org
Cc: LMM@acm.org
Subject: New Version Notification for draft-masinter-dated-uri-07


A new version of I-D, draft-masinter-dated-uri-07.txt has been successfully submitted by Larry Masinter and posted to the IETF repository.

Filename:	 draft-masinter-dated-uri
Revision:	 07
Title:		 The 'tdb' and 'duri' URI schemes, based on dated URIs
Creation_date:	 2010-10-22
WG ID:		 Independent Submission
Number_of_pages: 16

Abstract:
This document defines two URI schemes.  The first, 'duri' (standing
for "dated URI"), allows indicating a URI as of a particular date
(and time).  This allows explicit reference to the "time of
retrieval", similar to the way in which bibliographic references
containing URIs are used.

The second scheme, 'tdb' ( standing for "Thing Described By"),
provides a way of using a way of minting URIs for anything that can
be described, with the ability to fix the description to a given date
or time.  The 'tdb' URI scheme may reduce the need to define define
new URN namespaces merely for the purpose of creating stable
identifiers for concepts or abstractions: it provides a ready means
for identifying "non-information resources" by semantic indirection
-- a way of creating a URI for anything.

Note

This document is not a product of any working group.  Many of the
ideas here have been discussed since 2001.  This document has been
discussed on the mailing list <uri@w3.org>.  Previous versions have
couched 'tdb' and 'tdb' as URN namespaces.
                                                                                  


The IETF Secretariat.



--
http://larry.masinter.net


-----Original Message-----
From: Alfred HÎnes [mailto:ah@TR-Sys.de] 
Sent: Wednesday, September 23, 2009 1:09 PM
To: LMM@acm.org
Cc: uri-review@ietf.org
Subject: draft-masinter-dated-uri-06

Hello,
I'm a bit late, but eventually I now found the time to also follow
up to your revised 'tdb' draft, draft-masinter-dated-uri-06,
and would like to submit the following comments.


(A)   DISCUSS

I am concerned with the <timestamp> concept in the draft,
based on TAI, and not re-using existing Internet standards.

TAI is a rather unusual scale for typical users, and its use
seems to be counter-intuitive and detrimental for the intended
use of 'coarse-grained' timestamps.  For instance, in the
proposed interpretation, Dec 31, 2009 shall indicate the last
moment of that day/month/year;  however, the intuitive use of
"day" implicitely is based on the local time scale, including
the applicable time zone offset: the creator of a 'tdb' URI
will most likely want to indicate the end of a day as she
perceives a day in her time zone, and not the concept of a day
in TAI.  The intended combination of intuitive use and precision
is lost to a great degree, whenever one of the proposed URIs is
brought from an originator to a recipient in another time zone.
With respect to that trouble, the minimal differences between
TAI and UTC become insignificant and immaterial.

I'm not sure whether the idea to replace the specified
low-precision timestamp by the last moment in time falling
into it is feasible.  Some of the examples and parallels to
the "paper world" do not support this idea in a convincing way.
Regarding the problems and existing standards based solutions
for varying resolution in date and time, I recommend the
Amendment to the ASN.1 Standard (ITU-T X.680) defining the
datetime/date/time ASN.1 data type for enlightening insights.
(PDF available for free download from the ITU-T web site.)

I therefore propose to reconsider the direction of the draft
to use TAI and a proprietary timestamp format.
I recommend to shift to UTC based timescales and request the
specification of a time zone offset, and to refer to RFC 3339
(and the ISO standard quoted there) for the formatting of the
<timestamp> element -- maybe a 'profile' of RFC 3339 may be
specified.
Doing so should better align this proposal with existing (and
actually used!) standards and intuitive expectations of the
target audience regarding the semantics of time spans like
year, month, and date.


(B)  More or less editorial comments

(1)  General

ABNF makes use of double quotes to enclose (case-insensitive)
string literals.  In order to visually distinguish various other
elements in the text typographically, a convention has emerged
to enclose URI schem names in single quotes.
I warmly recommend to follow this convention in order to reduce
the semantical overloading for the double-quote character.

This applies to the document title and the prose.


(2)  Abstract

There are a few textual artifacts left over in the draft
from the elimination of the "duri" namespace and the shift
from URN namespcae registration to URI scheme registration.
Among these artifacts is the flaw below.  (For brevity, I'll
not repeat this kind of rationale below.)

The 2nd para of the Abstract should be modified:

|  This URI scheme may reduce the need to define define new URN
!  ^^^^^^^^^^^^^^^ (singular!)
   namespaces merely for the purpose of creating stable identifiers.  In
|  addition, they provide a ready means for identifying "non-information
             ^^^^^^^^^^^^
   resources" by semantic indirection -- a way of creating a URI for
   anything.
---
   This URI scheme may reduce the need to define define new URN
   namespaces merely for the purpose of creating stable identifiers.  In
|  addition, it provides a ready means for identifying "non-information
             ^^^^^^^^^^^
   resources" by semantic indirection -- a way of creating a URI for
   anything.


(3)  Section 1 -- word omission

Please correct the apparent word omission, and apply (1):

   The tdb URI scheme here solves several related problems:
---
   The 'tdb' URI scheme defined here solves several related problems:


(4)  Section 3

(4a)  2nd para

The draft says:

   The meaning of a duri is "the resource (or fragment) that was
   identified by the <encoded-URI> (after hex decoding) at the very last
   instant of the date(time) given".

Oooops!  It should perhaps say now:

|  The meaning of a `tdb` URI is "the resource that was identified by
|  the contained <URI> at the very last instant of the date(time)
   given".

(4b)  4th para

I suggest to clarify:

   For example, one might use "tdb:2008:http://www.ietf.org" as a
   persistent identifier for the Internet Engineering Task Force, as
   described by the "http://www.ietf.org" as of the very last instant of
   the year 2008.
---
   For example, one might use "tdb:2008:http://www.ietf.org" as a
   persistent identifier for the Internet Engineering Task Force, as
|  described by the "http://www.ietf.org" web site as of the very last
   instant of the year 2008.
                                         ^^^^^^^^^^

(4c)  5th para

|  The "tdb" namespace differs from the URN methods for identifying
   abstractions because the designation of what is actually identified
|  by the tdb doesn't depend on knowing the intention of the "assigner"
   of the identifier.  [...]
---    v   v vvvvvvvvvv
|  The 'tdb' URI scheme differs from the URN methods for identifying
   abstractions because the designation of what is actually identified
|  by the 'tdb' URI doesn't depend on knowing the intention of the
          ^   ^^^^^
   "assigner" of the identifier.  [...]


(5)  Section 4 (ff.)

The draft says:

   A tdb URI is not a resource locator in a practical sense.  It allows
   one to know that a resource was described at some point in time, but
   whether the description is still available, or whether that
|  description is still meaningful, is ambiguous.

Do you really mean "ambiguous"?  Maybe "unspecified" ?


(6)  Section 7.1, 2nd para -- typos

   For example, use with a "http" URI can be used to refer to the
|  subject of a web page (at it was described at the given time.)  This
   can be a way of referring to a web site at some time in the past, or
   an organization that has changed, merged, split, or disappeared.
---
   For example, use with a "http" URI can be used to refer to the
|  subject of a web page (as it was described at the given time).  This
                           ^                                   ^^
   can be a way of referring to a web site at some time in the past, or
   an organization that has changed, merged, split, or disappeared.


(7)  Section 7.2, 1st para -- missing verb

   Timestamps far in the future are suspect, because the future content
|  of a description resource cannot usually reliably predicted.
   [...]
---
   Timestamps far in the future are suspect, because the future content
|  of a description resource cannot usually be reliably predicted.
   [...]                                   ^^^^


(8)  Section 7.4 -- more omissions

|  There no resolution servers or processes for tdb URI.  [...]
---     vvvvv                                       v   v    v
|  There are no resolution servers or processes for 'tdb' URIs.  [...]


(9)  Section 9 -- typos

|  This document includes a URI scheme registration (Section 8 that
   should be entered into the IANA registry of URI schemes as a
|  permanent registration (once approved.)
---                                     ^^                    v
|  This document includes a URI scheme registration (Section 8) that
   should be entered into the IANA registry of URI schemes as a
|  permanent registration (once approved).
                                        ^^

Kind regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+