Re: [urn] PWID URN namespace registration version 10

[[e-mail]]

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