Re: [urn] editorial comments on draft-ietf-urnbis-ns-reg-transition-01

[[e-mail]]

Hello,

Quoting John C Klensin <[e-mail]>:

> Hi.
>
>
> Observation from a participant in this WGs who thinks the work
> is very important and who has some experience with how the IETF
> works, but no official role in the WG other than being willing
> to help with writing: When WG drafts are posted and met with
> dead silence (or silence except from an extremely small number
> of people, the usual IETF tendency is to assume that the WG is
> dead, no one cares, and that, if it produces any work, that work
> doesn't represent enough meaningful consensus to be moved
> forward.

In this case, these conclusions may be at least partially wrong.

The organizations which currently use URNs or other persistent  
identifiers most actively do not normally participate actively in the  
IETF work. Therefore they may not follow what is going on, or they may  
just be lurking (I know several people who are doing exactly that.

The eagerness to just lurk was strengthened when discussions on the  
list veered away from (what for instance we librarians) consider  
practical issues related to resource identification into more  
fundamental issues of what it means to use fragment and query in URNs  
and how that relates to the generic URI syntax.



> Barry has been extremely patient, I think because he
> shares my/our sense of importance, but I'm very concerned about
> how we move forward this way.   This is especially important
> because a few of us have been thinking about a very radical move
> to get the various issues of syntax, properties of the name or
> named object versus things that can be done only after it is
> retrieved, and so on unstuck.  That move would be, IMO,
> impossible without strong backing from the WG.  Because just
> raising it would probably stir up a lot of controversy, I (at
> least) haven't even been willing to explain it on this mailing
> list.

It may be difficult not to bring these issues up eventually. The  
conclusions we have at least tentatively drawn are not exactly a  
perfect match with RFC 3986.

Juha

>
> So, nay I ask (and recommend) that those of you who are reading
> drafts, saying "seems ok" to yourselves, and moving on start
> posting "I have read this and seems ok" (or "I have read it and
> it is hopeless" if that is that better reflects your views)
> notes to the list.  And those of you who haven't been reading
> drafts should start soon -- the silence will kill us, if not by
> action from the IESG than by the authors giving up.
>
> Again, a few notes on Peter's comments below
>
> thanks,
>   john
>
>
> --On Wednesday, February 12, 2014 09:10 -0700 Peter Saint-Andre
> <[e-mail]> wrote:
>
>> Thanks to John and Juha for working on this document. Overall
>> I think the substance is fine. Here are a few small editorial
>> issues I noticed.
>>
>> 1. Expand URN on first use:
>> ...
>> 2. This is a bit awkward:
>> ...
>> 3. There's a stray word here:
>> ...
>> 4. A missing and:
>> ...
>
>> 5. This text might be slightly ambiguous:
>>
>>     For both ISSN and ISBN URNs, it is intended that the
>> registrations
>>     track the evolution of ISO standardization without
>> requiring
>>     resubmission of the templates or other formal IETF or IANA
>>     registration update approval procedures.
>>
>> I assume that refers to the current registrations, not any
>> future registrations.
>
> Actually, I was trying to finesse a problem.  This really needs
> input from you and the read of the WG.   Let me keep it separate
> from the editorial issues by writing a separate note.
>
>> 6. This is a bit of a run-on sentence:
>> ...
>> 7. Typo here:
>> ...
>> 8. I sense some ambiguity here:
>>
>>     IANA is requested to update the registry entries for URN
>> ISSNs,
>>     ISBNs, and NRNs to reflect the new, RFC 3406bis-complaint
>> templates
>>     as soon as they are available and to no longer reference
>> the now-
>>     historic RFCs.  Other registrations and templates
>> conforming to the
>>     newer rules may be substituted for the older ones when
>> they are
>>     available.  However, neither this document nor RFC 3406bis
>>     invalidates existing registrations other than those listed
>> above, so
>>     IANA needs to be prepared to maintain a registry whose
>> contents
>>     reflect both old and new templates.
>>
>> I think "other registrations and templates" might be referring
>> to registrations and templates for namespaces other than ISSN,
>> ISBN, and NBN.
>
> Yes.  And it needed to spelled out a bit more even where it
> wasn't ambiguous.    I've substituted your proposed sentence,
> which is probably good enough.
>
> Suggestions for less tedious wording are welcome.
>
>> I think "supersedes" might be more appropriate than
>> "invalidates".
>
> I really did mean "invalidate", partially because of aspects of
> the ongoing "obsoletes" versus "historic" debate.   In addition,
> in theory this document or 3507bis could declare all existing
> registrations invalid without any superceding documentation or
> registration (in some sense, it does make tham obsolete because
> the information required is different).   We've decided (I
> think) to not do that and I thought it was worth making
> explicit.  But I've changed the word to "supercedes".  It can be
> changed back if anyone feels strongly about it.
>
>> And I think "a registry whose contents reflect both old and
>> new templates" does not imply that IANA would point to both an
>> old and a new template for the same namespace, but for
>> different namespaces.
>
> One would hope that, in the former case, a new NID would be
> assigned.
>
>> Thus I suggest:
>>
>>     IANA is requested to update the registry entries for URN
>> ISSNs,
>>     ISBNs, and NBNs to reflect the new, RFC 3406bis-complaint
>> templates
>>     as soon as they are available and to no longer reference
>> the now-
>>     historic RFCs for those namespaces.  With respect to
>> namespaces
>>     other than those listed above, registrations and templates
>>     conforming to the newer rules may be substituted for the
>> older ones
>>     when they are available.  However, neither this document
>> nor RFC
>>     3406bis supersedes existing registrations other than those
>> listed
>>     above.  Therefore, IANA needs to be prepared to maintain a
>> registry
>>     whose contents reflect old templates for some namespaces
>> and new
>>     templates for other namespaces.
>
> Smoothed a bit but basically incorporated.
>
> Thanks for the careful reading,
>    john
>
>
>
>
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn