Subject: Re: [urn] Comments on PWID -05 - now PWID -06

From: Eld Zierau <[email-masked]>
Date: Mon, 29 Apr 2019 12:10:19 +0000

Did any of you have comments to my previous mail?
Is there any action you want me to take in order to get it accepted?
Best Regards, Eld

-----Original Message-----
From: Eld Zierau 
Sent: Friday, March 1, 2019 1:29 PM
To: 'Martin J. Dürst' <[email-masked]>; 'Dale R. Worley' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: [urn] Comments on PWID -05 - now PWID -06

I have now uploade a new version: draft-pwid-urn-specification-06
 - and thanks again for comments and suggestions

Regarding the suggestion from Martin (included below), I can as a computer scientist certainly see the reasoning as quite obvious. However, my experience with presentation of the PWID is that syntax based on computational reasoning is something that users find illogically, e.g. that the archived-item-id (usually URI) is included in the end of the PWID. I believe that adding a "~" for identifiers that are registered separately is acceptable for such users, but I am also convinced that a "+" before a domain will be something that confuses (non-computer science) users a lot. 
Also, as said in my previous mail, it is highly unlikely that there will ever be a case where "~" is the first character in a domain for a web archive. Therefore, it seems that it should not be necessary. 
A minor extra thing is that all existing PWIDs (and tools providing and resolving PWIDs) would not comply, which they would otherwise (none of these use registered identifiers yet only domains and URIs).
In other words: I will be very sorry to add a "+" to domains, and I believe it is not necessary.

The uploaded version  does not include a "+" to domains, - If required, I will of course add it (although sorry to do so)

Please let me know if it acceptable, and I will act accordingly.

Best regards, Eld 

On 2019/03/01 11:31, Dale R. Worley wrote:
> Martin J. Duerst <[email-masked]> writes:
>>> [...]  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.
> 
> 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.

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.

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

---

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 29 Apr 2019 18:00:21 +0000

I (as a non-computer scientist) tend to agree with Eld that even though it's technically possible to have a domain name that starts with a ~, it ought to be fairly unlikely. To me it would be fine to use ~ to indicate separately registered archive identifiers and to say that everything that does not start with ~ should be interpreted as a domain name.

Best,

Lars

> From: Eld Zierau [mailto:[email-masked]]
> Sent: Monday, April 29, 2019 2:10 PM
> To: Martin J. Dürst <[email-masked]>; Dale R. Worley
> <[email-masked]>
> Cc: [email-masked]; Svensson, Lars <[email-masked]>
> Subject: RE: [urn] Comments on PWID -05 - now PWID -06
> 
> Regarding the suggestion from Martin (included below), I can as a computer
> scientist certainly see the reasoning as quite obvious. However, my experience with
> presentation of the PWID is that syntax based on computational reasoning is
> something that users find illogically, e.g. that the archived-item-id (usually URI) is
> included in the end of the PWID. I believe that adding a "~" for identifiers that are
> registered separately is acceptable for such users, but I am also convinced that a
> "+" before a domain will be something that confuses (non-computer science) users
> a lot.
> Also, as said in my previous mail, it is highly unlikely that there will ever be a case
> where "~" is the first character in a domain for a web archive. Therefore, it seems
> that it should not be necessary.
> A minor extra thing is that all existing PWIDs (and tools providing and resolving
> PWIDs) would not comply, which they would otherwise (none of these use
> registered identifiers yet only domains and URIs).
> 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.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Apr 2019 21:13:36 -0600

Hello Eld,

Your proposed syntax (with "~") looks fine to me.

The ABNF definition of your proposed syntax does not conform to RFC
5234. You can check the ABNF using this tool:

https://tools.ietf.org/tools/bap/abnf.cgi

In particular, it's not clear to me what a rule like this is intended to
mean:

   registered-archive-id = +( unreserved )

Do you mean that a registered-archive-id can include one or more
instances of characters from the `unreserved` rule? If so, change "+" to
"*".

To simplify the ABNF, you could use the datetime rules from RFC 3339.

Please don't use `URI` as the name of an ABNF rule because that's
already defined in RFC 3986 and could cause confusion. Perhaps call it
`uri-string`.

Personally I found the `precision-spec` categories difficult to
understand and sometimes ambiguous. For instance:

* A precision level of "part" seems to be an HTML file only (at least in
the case when "it refers to an html web element"), however a URI can
point to many file types other than HTML files. Perhaps "single" (as in
a single file) would be clearer; it would also be good to specify how
this is handled in the case of file types other than HTML.

* Does a precision level of "page" apply only to HTML pages with all
"referenced web parts"? (By the latter term I think you mean what the
HTML 5.2 specification defines as "embedded content"; in general it
would be good to align terminology.)

As to the registration, instead of version 6 it should be version 1
because this is the initial registration (i.e., whenever we are finished
with this process it will be the initial version, whereas if you update
the entire registration in the future that would be version 2).

The security considerations strike me as underspecified. An archived web
page or part could be just as dangerous as a "live" page or part; for
instance, it could include insecure scripts, malware, trackers, etc.
Furthermore, an archived page could in fact be more dangerous, because
it could include outdated scripts with known vulnerabilities that can
never be patched because the script is archived for all time in a
vulnerable state (an attack of this sort was recently discovered in the
wild).

Best Regards,

Peter

On 4/29/19 6:10 AM, Eld Zierau wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: Eld Zierau <[email-masked]>
Date: Tue, 30 Apr 2019 10:22:05 +0000

Thank you all

I will make a new draft soon

Best regards, Eld

-----Original Message-----
From: Peter Saint-Andre <[email-masked]> 
Sent: Tuesday, April 30, 2019 5:14 AM
To: Eld Zierau <[email-masked]>
Cc: [email-masked]
Subject: Re: [urn] Comments on PWID -05 - now PWID -06

Hello Eld,

The ABNF definition of your proposed syntax does not conform to RFC 5234. You can check the ABNF using this tool:

Do you mean that a registered-archive-id can include one or more instances of characters from the `unreserved` rule? If so, change "+" to "*".

Please don't use `URI` as the name of an ABNF rule because that's already defined in RFC 3986 and could cause confusion. Perhaps call it `uri-string`.

Personally I found the `precision-spec` categories difficult to understand and sometimes ambiguous. For instance:

* A precision level of "part" seems to be an HTML file only (at least in the case when "it refers to an html web element"), however a URI can point to many file types other than HTML files. Perhaps "single" (as in a single file) would be clearer; it would also be good to specify how this is handled in the case of file types other than HTML.

* Does a precision level of "page" apply only to HTML pages with all "referenced web parts"? (By the latter term I think you mean what the HTML 5.2 specification defines as "embedded content"; in general it would be good to align terminology.)

As to the registration, instead of version 6 it should be version 1 because this is the initial registration (i.e., whenever we are finished with this process it will be the initial version, whereas if you update the entire registration in the future that would be version 2).

The security considerations strike me as underspecified. An archived web page or part could be just as dangerous as a "live" page or part; for instance, it could include insecure scripts, malware, trackers, etc.
Furthermore, an archived page could in fact be more dangerous, because it could include outdated scripts with known vulnerabilities that can never be patched because the script is archived for all time in a vulnerable state (an attack of this sort was recently discovered in the wild).

Best Regards,

Peter

On 4/29/19 6:10 AM, Eld Zierau wrote:
> The uploaded version  does not include a "+" to domains, - If 
> required, I will of course add it (although sorry to do so)
> 
>>> 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.
>>
>> 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.
>