Subject: [urn] Comments on PWID -05

From: [email-masked] (Dale R. Worley)
Date: Wed, 27 Feb 2019 22:19:30 -0500

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

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 28 Feb 2019 06:02:10 +0000

Hello Dale, others,

> 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.

---

From: Eld Zierau <[email-masked]>
Date: Thu, 28 Feb 2019 10:42:35 +0000

Thank you so much for a quick and constructive response!

I will upload a new draft (hopefully at the latest tomorrow), where I will do the following:

1) add "." to syntax of (both) identifiers as an indication character (not part of the identifier itself). 
For the archive identiifers I will make the options that it is either a domain (defined in RFC1034 section 3.5) or a registered identifier (indicated with the ".") In this way I do not make an explicit registriction, but a reference to the common domain syntax restrictions.
I really appriciate you comment Martin, but it is very hard to make rules that takes into account that other rules are broken - and in practice it seems highly unlikely that there will be official web archives that have domain names that are not following the rules, so I hope this way around it is acceptable.
The description of the two identifiers as well as construction and resolution of PWID URNs will be updated accordingly.

2) remove the "other" value and specified extension values instead - a very good point which have annoyed me, so this is certainly a much better solution

3) change the archived URI description, so it is clear that all special characters must be % encoded (good point that I failed to see in the first place)

4) change the syntax for the timestamp so it is more explicit - as well as emphasized that it should follow the recommondations for web archives (currently best described in the WARC standard)

5) change the [W3CDTF]  reference so it does not look misformatted

Hope this is satisfactory

Best regards, Eld

PS: I will send a mail as soon as I have uploaded a new version

-----Original Message-----
From: Martin J. Dürst <[email-masked]> 
Sent: Thursday, February 28, 2019 7:02 AM
To: Dale R. Worley <[email-masked]>; Eld Zierau <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [urn] Comments on PWID -05

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.
> 
> 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.

> component like this would allow "extension values" (that conform to 
> the same syntax as the defined values, e.g., "+letter").  As written, 
> 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:
> 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.
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 28 Feb 2019 21:31:19 -0500

Martin J. Duerst <[email-masked]> writes:
>> [...]  E.g., one could require that any

I may agree with you ... But what do you mean by "an explicit
distinction"?  E.g., I would tend to consider "archive-ids starting with
'~' are registered archive names, and archive-ids that do not are
considered DNS names" to be an "explicit" distinction, but you mean
something else.

Or maybe the right question is, What do you propose as an alternative?

Dale

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 1 Mar 2019 07:46:54 +0000

> considered DNS names" to be an "explicit" distinction, but you mean

Well, the explicit distinction would be "if it starts with '~', what 
follows is a registered archive name, and if it starts with '+', what 
follows is a DNS name" or some such. This would not exclude any leading 
characters in either archive names or DNS names.

Regards,   Martin.