Re: [urn] Comments on PWID -05

[Martin J. Dürst <[e-mail]>]

Hello Dale, others,

On 2019/02/28 12:19, Dale R. Worley wrote:
> 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 "-", ".", "_", "~".

I haven't looked into the details, but in general, I think this is a bad 
idea. It is much better to have an explicit distinction than to rely on 
some syntax restrictions. Such syntax restrictions may or may not 
actually hold in practice. It's very easy to create a DNS name starting 
with '-' or '_', for example, even though officially, that's not allowed.

Regards,   Martin.

> 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