Re: [urn] PWID URN namespace registration version 10

[Eld Zierau <[e-mail]>]

Thank you Dale

My comments is given below, and updated version is attached with following corrections: 
- added draft information in filename/header
- description of archive-domain
- syntax for utc-time 
- date of document
Best regards, Eld

---------------------------------------------------------------------------------------

My apologies for not giving this attention sooner.

I've read version 10, and I think we should approve it.  I have the following observations, which include one editorial suggestion.


I assume that the attachment to message
https://mailarchive.ietf.org/arch/msg/urn/x_JVtfKpANKZz6Qr8iOqpsXJ8SU/
"PWID URN (shortened title)" is draft verson 10, despite that neither the attachment's name or contents states that.
> Eld: At some stage, I was told that it is version 1, maybe I misunderstood, 
> but I thought the document date then indicated the version. 
> It was actually draft version 11. In the attached draft version 12, I have put in the information 
> about it being draft version 12


I particularly support the PWID proposal for the reasons I described in "PWID as citation"
https://mailarchive.ietf.org/arch/msg/urn/s-CM7hcWtUeAz7ZVBF94rCHMtsQ/
-- namely that what a PWID references is transparent enough that one could algorithmically transform a PWID pointing to one archive into a query into another archive.  This is a genuinely new capability for URNs (as far as I know) and only by deploying it in practice can we see what benefits might be obtained.
> Eld: Agree

I still dislike that there's no well-defined way to catalog allowed values of archive-dimain.  But the number of values that are used will likely remain small and there are unlikely to be "ownership conflicts"
about them, so this is unlikely to be a problem in practice.
> Eld: I agree, and I will certainly work on other fronts to make it possible to make more 
> precise reference, but this is what exists at the moment.

A minor editorial point:
      *  'archive-domain' is defined as in (section 3.5) [RFC1034].
"archive-domain" is not defined in RFC 1034.  You need to say
      * 'archive-dimain' is <subdomain> as defined in (section 3.5) [RFC1034].
(Oddly, you do want to use <subdomain> rather than <domain> defined in that section.)
> Eld: You are right - it is subdomain because <domain> ::= <subdomain> | " " and we want to avoid the " " possibility.
> I have corrected in the attached  draft version 12 


I see that if utc-time is part of archival-time, then it must contain both utc-hour and utc-minute, whereas utc-second and secfrac can be added independently.  This is a bit of an inconsistency, but I assume you intend it.
> Eld: That is actually an error, - I have corrected it, so it is possible just to specify the hour without minutes

Given that precision-spec is currently limited to one of two values, later extensions can be indicated by additional values defined for this field.
> Eld: Agree

Dale

-----
Eld Zierau
Digital Preservation Specialist PhD
The Royal Danish Library
Digital Cultural Heritage
P.O. Box 2149, 1016 Copenhagen K
Ph. [phone] 
Email: [e-mail]

-----Original Message-----
From: Dale R. Worley <[e-mail]> 
Sent: Sunday, May 24, 2020 5:19 AM
To: Eld Zierau <[e-mail]>; [e-mail]
Subject: Re: PWID URN namespace registration version 10

My apologies for not giving this attention sooner.

I've read version 10, and I think we should approve it.  I have the following observations, which include one editorial suggestion.

I assume that the attachment to message
https://mailarchive.ietf.org/arch/msg/urn/x_JVtfKpANKZz6Qr8iOqpsXJ8SU/
"PWID URN (shortened title)" is draft verson 10, despite that neither the attachment's name or contents states that.

I particularly support the PWID proposal for the reasons I described in "PWID as citation"
https://mailarchive.ietf.org/arch/msg/urn/s-CM7hcWtUeAz7ZVBF94rCHMtsQ/
-- namely that what a PWID references is transparent enough that one could algorithmically transform a PWID pointing to one archive into a query into another archive.  This is a genuinely new capability for URNs (as far as I know) and only by deploying it in practice can we see what benefits might be obtained.

I still dislike that there's no well-defined way to catalog allowed values of archive-dimain.  But the number of values that are used will likely remain small and there are unlikely to be "ownership conflicts"
about them, so this is unlikely to be a problem in practice.

A minor editorial point:
      *  'archive-domain' is defined as in (section 3.5) [RFC1034].
"archive-domain" is not defined in RFC 1034.  You need to say
      * 'archive-dimain' is <subdomain> as defined in (section 3.5) [RFC1034].
(Oddly, you do want to use <subdomain> rather than <domain> defined in that section.)

I see that if utc-time is part of archival-time, then it must contain both utc-hour and utc-minute, whereas utc-second and secfrac can be added independently.  This is a bit of an inconsistency, but I assume you intend it.

Given that precision-spec is currently limited to one of two values, later extensions can be indicated by additional values defined for this field.

Dale