[Uri-review] draft-masinter-dated-uri-06
Alfred Hönes <ah@TR-Sys.de> Wed, 23 September 2009 20:08 UTC
Return-Path: <A.Hoenes@TR-Sys.de>
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 269013A6873 for <uri-review@core3.amsl.com>; Wed, 23 Sep 2009 13:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.231
X-Spam-Level: **
X-Spam-Status: No, score=2.231 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 i09pAbRqB3Do for <uri-review@core3.amsl.com>; Wed, 23 Sep 2009 13:08:30 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 9632F3A6809 for <uri-review@ietf.org>; Wed, 23 Sep 2009 13:08:28 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA108846533; Wed, 23 Sep 2009 22:08:53 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA06116; Wed, 23 Sep 2009 22:08:52 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200909232008.WAA06116@TR-Sys.de>
To: LMM@acm.org
Date: Wed, 23 Sep 2009 22:08:51 +0200
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Cc: uri-review@ietf.org
Subject: [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: Wed, 23 Sep 2009 20:08:31 -0000
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