Subject: Re: [urn] ISSNs, ISBNs, and automatic definition upgrading

From: Juha Hakala <[email-masked]>
Date: Mon, 03 Mar 2014 10:59:37 +0200

Hello,

A few comments below.

On 28.2.2014 22:15, John C Klensin wrote:
> The other note I promised...
>
> --On Wednesday, February 12, 2014 09:10 -0700 Peter Saint-Andre
> <[email-masked]> wrote:
>
>> 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.
> As I said, this needs WG thought and input.
>
> As we have seen with the revisions that specified the longer
> identifiers for ISBNs, these underlying ISO standards change.
There are other ISO identifiers which are about to change. For instance, 
a thorough revision of ISRC, International Standard Recording Code, has 
just started. And another revision of ISBN is already under way. So we 
may expect that even if (ISO) identifiers themselves are persistent 
(they will last for centuries), the identifier standards themselves will 
be regularly tweaked for various reasons.
> The good news is that, at least in my opinion, changes that
> would make older identifiers invalid are just not going to
> happen: they would be extremely disruptive and costly to a
> community that is very dependent on stability over periods the
> IETF has trouble thinking about.
Usually, every identifier that has been assigned according to the old 
version of the standard remains valid. However, there are exceptions to 
this rule.

ISBN-13 allows two different practices as regards the use of old 
ISBN-10s. They may be kept as is (library preference) or they may be 
converted to ISBN-13 format. In practice, I've seen books (reprints of 
books which were first published during ISBN-10 era) which have both 
ISBN-10 and ISBN-13, or more precisely, the same ISBN number in two 
formats.

New ISRC standard, if approved, may make invalid some old ISRC 
identifiers. So far, ISRC assignment has been very decentralized, but 
there has been no global ISRC database. Therefore a single recording may 
have received multiple ISRCs. The idea is to validate existing ISRCs by 
harvesting them and related metadata into an international ISRC 
database. If a recording has two or more ISRCs, only one of them will be 
approved and others deprecated. But these deprecated ISRCs will never be 
reassigned and most likely they will still be included in the metadata 
of the recording, so from the users' point of view even these ISRCs are 
still actionable.

However, even when the identifier community changes things (the 
identifier assignment process, the identifier syntax, etc.) everything 
will be done to make sure that even the deprecated identifiers will 
remain actionable. This principle also applies to errors; if a book has 
a typo in the ISBN number, it is possible to find the book with that 
ISBN, although the correct number has been assigned later.

> My instinct is to trust that
> and allow a registration that does not require revision or
> updating to move from one version of an underlying ISO standard
> for the identifier to another.  The current reference version
> of the underlying standard, syntax, assignment rules, etc., are
> what ISO says they are with no IETF, Expert, or registrant
> action being required (even though I'm sure we would welcome
> explanatory updates).

Some modifications to identifier standards may have no impact on 
existing URN namespace registrations. But only the identifier community 
itself will know if this is the case. However, most ISO identifier 
standard updates I've seen have been non-trivial from URN point of view.

Even if the standard remains the same, there may be a need to update the 
registration. For instance, the designated contact person or his/her 
contact information may change, and namespace related documentation may 
be updated. It should be possible to make these editorial changes "any 
time".

>
> I don't know whether that generalizes beyond ISSNs and ISBNs
> (and, maybe, if the IAB decides to go in that direction, the
> ISO version of DOIs).  We would certainly want to have a very
> serious discussion if someone wanted to register a URN
> namespace that was dependent on a possibly more volatile set of
> references.
Most URN namespace registrations will require less maintenance than ISBN 
and ISSN. For instance, there is no NBN standard except RFC 3188 so 
there is no "external pressure" to revise the namespace registration. 
The scope and syntax of NBN are intentionally relaxed, and there is no 
need to make the specification more precise.

As an aside, as identifiers DOI (and Handle) are NBN-like broad umbrella 
systems. These identifiers can be applied to almost any resource out 
there. "Digital object identifier" actually means "digital identifier to 
all kinds of objects".

>   But, for this case, it makes sense to me and would
> eliminate possible uncertainties between the time an ISO
> standard is updated and published and when someone gets around
> to updating the URN registration.  Experience leds me to hate
> those sorts of timing dependencies, especially when they can be
> avoided.
>
> So, two questions (I'll try to interpret the answers, but the
> decision about agreement, as I noted earlier, belongs to Andy):
>
> (1) Does the WG agree with my analysis and believe that having
> the registration based on the "current version" of the ISO
> standard, whatever that version is at a given time, is wise?

Yes, for ISO and any other identifier standards. And I don't see a good 
alternative to this approach, based on my practical experiences on how 
the ISO identifiers have developed during the last 20 years.

>
> (2) If so, how should this be said?  Note that it might (or
> might now) require some tuning to 3507bis to get an explicit
> statement in the registration template as to whether the
> referenced external standard is the version as of some specific
> date (and/or version number) or whether it always follows the
> versions of the external standard as I'm suggesting here.

RFC3406bis should make it more clear that that if the namespace is being 
registered for a de jure standard identifier, the name and version of 
the standard shall be specified in the Purpose section of the 
registration. This is important since many other things (such as the 
scope of the identifier, syntax of the identifier string, identifier 
assignment process, technical basis for resolution process) are based on 
the identifier system AND its version.

It might be useful to provide in RFC3406bis examples of circumstances 
when the revision of the registration is recommended or even required. 
These include:

1. Changes in the registrant information (new contact person or change 
in the address info)

2. Substantial changes in the documentation (such as a new user guide)

3. Changes in the purpose, syntax, assignment or resolution of the 
identifier

For instance, the planned new ISRC would require an update to the 
(currently non-existing) ISRC namespace registration due to the 
possibility of resolving URN:ISRCs in the global ISRC database required 
by the new version of the standard.

IMO for cases 1 & 2 above, formal update of the registration via the 
review process should not be necessary since the changes are just 
editorial. Case 3 is different; for instance, if the purpose (scope) of 
the identifier changes, a review by designated experts is necessary, 
especially if the new extended scope overlaps with that of one of more 
existing namespaces. Another issue which requires consideration is a 
syntax change which makes it necessary to alter the resolution process.

IETF and ISO TC 46 have established a liaison. This will enable IETF to 
keep an eye on the revision of those ISO identifiers which have URN 
namespaces, and - if the suggested new versions of these identifiers are 
problematic from the URN point of view - provide guidance on how the 
situation could be improved.

Best regards,

Juha
>
> thanks,
>      john
>
>
>
>
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678

---

From: [email-masked]
Date: Wed, 05 Mar 2014 17:30:34 +0200

Hello,

Quoting John C Klensin <[email-masked]>:

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