Re: [urn] continued use of list

John C Klensin <> Tue, 30 December 2014 14:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 262331A00CF; Tue, 30 Dec 2014 06:28:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LvB6ytvc6nw5; Tue, 30 Dec 2014 06:28:50 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92BF21A00CD; Tue, 30 Dec 2014 06:28:50 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1Y5xmt-000BRs-3Q; Tue, 30 Dec 2014 09:28:43 -0500
Date: Tue, 30 Dec 2014 09:28:38 -0500
From: John C Klensin <>
To: Barry Leiba <>
Subject: Re: [urn] continued use of list
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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: Tue, 30 Dec 2014 14:28:55 -0000

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

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


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