[urn] Comments on PWID -05

[[e-mail] (Dale R. Worley)]

The discussion of archive-id is considerably clearer than before but it
seems to me that there should be some discussion of how to distinguish
domain name archive-ids (e.g., netarkivet.dk) and archive-ids that have
to be looked up in the (future) registry.  Being able to reliably make
this decision seems to be the first step in resolving a PWID.

I think arranging this is straightforward, since the syntax of
archive-id is "+( unreserved )", and many of those strings are not
allowed as DNS names for hosts.  E.g., one could require that any
archive-id that is not intended to be interpreted as a DNS name to start
with one of "-", ".", "_", "~".

Similar considerations apply to archived-item-id and distinguishing it
from URI.  (All URIs must start with a letter.)

           precision-spec = "part" / "page" / "subsite" / "site"
                    / "collection" / "recording" / "snapshot"
                    / "other"

Is the inclusion of "other" the best way to handle this?  Usually a
component like this would allow "extension values" (that conform to the
same syntax as the defined values, e.g., "+letter").  As written,
everything that cannot be classified as "part", "page", ..., "snapshot"
would have to be labeled "other", even if a particular archive had
several different additional precision values that it operated with
internally.

      *  'URI' is defined as in [RFC3986] but where occurrences of "[",
         "]", "?" and "#" are %-encoded in order not to clash with URN
         reserved characters [RFC8141].

This gets complicated.  For example "http://example.com/foo#bar" is a
different URL than "http://example.com/foo%23bar", and might have
different contents.  You can't use "http://example.com/foo%23bar" as the
archived-item part of PWIDs for the saved contents of both of these
URLs.

One possibility is to set the archived-item string to be URI with [, ],
?, #, and % all %-encoded, so that the two URLs have these archived-item
values:
    http://example.com/foo%23bar
    http://example.com/foo%2523bar
That would be laborious, though, if many URLs contain %-escapes and
humans have to copy PWID URNs by hand.

      *  'archival-time' is a UTC timestamp as described in the W3C
         profile of [ISO8601] [W3CDTF] (also defined in [RFC3339]), for
         example YYYY-MM-DDThh:mm:ssZ.

Looking at RFC 3339, I see:

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                             ; month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                             ; rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

But comparing that to W3CDTF, I see no single nontermainal which
corresponds to the set of formats allowed in W3CDTF.  I suggest you make
a more rigid specification as to what is allwed for archival-time.

   [W3CDTF]   W3C, "Date and Time Formats: note submitted to the W3C. 15
              September 1997", 1997,
              <http://www.w3.org/TR/NOTE-datetime>.

              W3C profile of ISO 8601 urn:pwid:archive.org:2017-04-
              03T03:37:42Z:page:http://www.w3.org/TR/NOTE-datetime

The final two lines of this block look like a mis-formatted
bibliographic reference.

Dale