Re: [urn] continued use of list

Juha Hakala <> Mon, 12 January 2015 10:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 835391A8AAB; Mon, 12 Jan 2015 02:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7wC47bn30Hvi; Mon, 12 Jan 2015 02:22:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F1FA1A8AA3; Mon, 12 Jan 2015 02:22:30 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id t0CAMJHL013959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Jan 2015 12:22:19 +0200
Message-ID: <>
Date: Mon, 12 Jan 2015 12:22:19 +0200
From: Juha Hakala <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba <>, John C Klensin <>
Subject: Re: [urn] continued use of list
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: Helmi-Kanerva Tuori <>,, "" <>, Esa-Pekka Keskitalo <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Jan 2015 10:22:39 -0000


On 9.1.2015 5:50, Barry Leiba wrote:

> 1. The IESG has just given approval for draft-higgs-hbbtv-urn, and as
> soon as he posts a new version I'm going to let it go out.  That
> covers the in-process ones.
> 2. I will not start processing on any other URN namespace requests
> until this WG has finished the update.

This should apply to the revision of existing namespaces - such as ISBN 
and NBN - as well. But once the URN syntax has been updated, I'll 
provide new versions of namespace registration requests for these 

These identifiers will support f- and q-components. But specifying which 
resolution services will (initially) be supported would not be really 
useful, since any list would become outdated fairly soon. And resolvers 
may support only a subset of potential services (or some informal 
services which are not yet widely known).

> 3. I'll watch the time-frame on that, and reserve the right to
> reconsider at some point.
> Fair?

Depends on how long it will be necessary to wait. The National Library 
of Finland wishes to register a URN namespace for International Standard 
Collection Identifier (ISCI), but we can wait a few weeks / months.

Best regards,


> Barry
> On Tue, Dec 30, 2014 at 10:28 PM, John C Klensin <> wrote:
>> --On Monday, December 29, 2014 15:37 -0500 Barry Leiba
>> <> wrote:
>>>>> So I think we should put "" into the draft as the
>>>>> address for review/discussions of namespace proposals, with
>>>>> the understanding that this will attain force when the draft
>>>>> is published as an RFC.
>>>> Actually, I think we should go a step further.  I think we
>>>> should celebrate the new year and expected rapid progress in
>>>> the WG
>>> One can hope, and I do.
>>>> by blocking all pending and future URN namespace
>>>> registrations by referring them to the WG for formal review
>>>> until 2141bis is approved and becomes the new procedure.
>>> I strongly disagree with blocking pending ones.  There is only
>>> one, and there's no reason to stop it now.  If you see
>>> something wrong with it, say so specifically.  If not, let it
>>> be approved, and we'll deal only with the future now.
>> Some observations below, but I'm going to defer to you on this
>> because I just don't have time or energy to both have a long
>> discussion and to make progress on the URNBIS WG documents.
>>> The urn-nid list is not a secret, and anyone here who thinks
>>> they need to scrutinize NID requests now more strongly than
>>> earlier... need only go there and do so.  It would be sillier
>>> to have those requesting NIDs post to and follow this list,
>>> which goes far beyond what they know or care to know.
>> I was actually thinking about the issue the other way around.
>> It has long been my experience that anyone who is active in the
>> IETF, knows where to find things or who to ask, and have lots of
>> time on their hands can find or follow just about anything that
>> amuses them.  There have historically been exceptions, but they
>> are few and becoming fewer.   However, one of several issues
>> with URNBIS is that people are coming into the discussions with
>> the perspective of one particular set of needs and advocating
>> for them on the implicit assumption that, if those needs are
>> accommodated, everything else will be taken care of [1].
>> The result is that we aren't getting a sufficient number of
>> perspectives and that increases the risks that we will get
>> something seriously wrong by omitting consideration of an
>> important case.  So my thinking was to create a situation in
>> which someone proposing a new URN namespace and NID was more or
>> less forced, as a condition for getting that NID, to follow and
>> participate in the WG, primarily wrt two questions:
>>          (i) Would any of the changes being proposed either hurt
>>          or help setting up their namespace, and any others
>>          similar to it that they can think about, be defined in a
>>          way that is clear, reasonable, and natural?
>>          (ii) Are there additional changes that should or should
>>          not be made that would be significant from their
>>          perspective?
>> Now, one could figure out other ways to ask those questions than
>> having them emerge in a dialog with the WG, and try to assure
>> that we got answers, then forcing applicants onto the on the URN
>> mailing list and holding the applications until the WG signed
>> off.  But, right now, it appears to me that we are not, and have
>> not been, getting those answers from the perspective of any
>> recent applicants other than Sean, and he hasn't been involved
>> for very long.
>>>> I note that RFC 3406 not only requires IETF Consensus for new
>>>> URN namespaces but explicitly quotes the portion of RFC 2434
>>>> pointing to referral to relevant WGs, so it has probably been
>>>> an error to approve new URN namespaces since this "bis" WG
>>>> came into being without formally asking the WG for it
>>>> consensus opinion.
>>> Hm.
>>> I don't see it that way.  What I say above has always applied,
>>> and the existing documents shunted the work over to urn-nid
>>> for good reason. It's been quite a good thing, really, through
>>> most of the life of this working group, that it hasn't
>>> directly been on the hook for reviewing and approving NID
>>> requests.  Participants here can be presumed to know well that
>>> urn-nid is where those go, and to know well how to go there
>>> too.
>> See above.
>>> ...
>>>> but I believe that the IETF Last Call on
>>>> draft-higgs-hbbtv-urn should not be closed out and an IESG
>>>> vote taken until this WG has formally reviewed it for
>>>> conformance to our plans going forward
>>> Please, let's not do that.  Let's just include that in the
>>> above "what's done is done" category, and let it finish.
>>> Unless you see specific harm, of course, which you absolutely
>>> should comment on.
>> I actually commented, at some length, on the GSMA/IMEI
>> namespace(s) (now RFC 7254 and 7255).  Those comments went
>> nowhere, including no useful responses from the authors or GSMA.
>> I considered making a fuss during the last round of IETF Last
>> Call (and, if necessary, on appeal) and concluded that
>>   (i) I'm reluctant to tell another standards body what
>>          they need, even though I'd be a lot happier if there was
>>          some sort of roadmap rather than "this request now and
>>          maybe there will be others later";
>>   (ii) I don't see a particular example, in its own
>>          namespace and with its own NID, as being especially
>>          harmful -- especially since nothing says "you get to use
>>          this as a precedent" -- even if there were serious
>>          problems with it;
>>   (iii) URNBIS wasn't nearly far enough along for us to
>>          have a serious discussion about one GSMA namespace and
>>          qualifiers of various sorts (?-components ?) that would
>>          identify different uses of that namespace.  I do note
>>          that, AFAIK, the situation with GSMA is rather different
>>          from that with ISO/TC 46.  In the latter case, there are
>>          separate registration authorities and oversight
>>          arrangements for, e.g., ISSN and ISBN.  If the
>>          registrations arrived, de novo, under the procedures
>>          outlined in 2141bis (and the former 3406bis), they would
>>          almost certainly arrive from different applicants.
>>          GSMA, again AFAIK, is a little more monolithic, so it
>>          would be reasonable to press for "one organization, one
>>          broad set of topics, one namespace" or at least for an
>>          explanation of why that was not appropriate;
>>   (iv)  I just don't have time to both fight individual
>>          URN namespace battles (unless they are obviously
>>          critical-path), try to drag i18n work along, and pay
>>          attention to anything else IETF-related.
>>> ...
>>> I am mostly happy to hold the future requests up, and I think
>>> it's not unreasonable to do that, provided that we do put a
>>> time limit on it.
>> Again, see the discussion of motivation above.
>>> The possible exception is "lex", which has been held up very
>>> long already.  It is, on the other hand, one that I find
>>> problematic for a number of reasons, and when the authors have
>>> responded to my last comments to them I'm inclined to ask you,
>>> John, to be its document shepherd... which may, in itself,
>>> throw it into the "delayed" pile (if you share my concerns, at
>>> least some of them, and/or have your own).
>> In the interest of future discussion and to keep this note from
>> getting longer, I'll reply separately on that subject.
>> Again, I'll defer to your decision about not combining the two
>> lists now, but note that, IMO, the continued separation is
>> weakening the work of this WG and increasing the risk of bad
>> results.
>> best,
>>      john
>> [1] There are more negative versions of that story, including
>> "as long as my needs are met, I don't care about anything else",
>> but such hypotheses are unnecessary to my point.
>> _______________________________________________
>> urn mailing list
> _______________________________________________
> urn mailing list


  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