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 | +------------------------+--------------------------------------------+
- [Uri-review] draft-masinter-dated-uri-06 Alfred Hönes
- Re: [Uri-review] draft-masinter-dated-uri-06 Larry Masinter