[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Uri-review] 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 at TR-Sys.de |
+------------------------+--------------------------------------------+