Subject: [urn] continued use of [email-masked] list

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 23 Dec 2014 11:54:00 -0700

RFC 3406 specified use of the [email-masked] list for discussion about 
namespace registrations, and 2141bis has not yet changed that. In the 
interest of economy, I would suggest using the [email-masked] list for all 
future discussions and deprecating the [email-masked] list.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Sean Leonard <[email-masked]>
Date: Tue, 23 Dec 2014 11:13:21 -0800

Maybe.

But there are two distinct controversies: 1) whether a proposed NID 
follows the URN rules sufficiently to permit registration, and 2) what 
the URN rules should be. It is very difficult for people who are trying 
to get work done under 1), to get sucked into debates about 2).

My latest proposal for xmlns and rdf URN NIDs 
(draft-seantek-xmlns-rdf-urns-00.txt) is an example of that. For those 
who want to resolve the f-component stuff with a practical example, 
please take a look. Thanks!

Sean

On 12/23/2014 10:54 AM, Peter Saint-Andre - &yet wrote:
> RFC 3406 specified use of the [email-masked] list for discussion 
> about namespace registrations, and 2141bis has not yet changed that. 
> In the interest of economy, I would suggest using the [email-masked] 
> list for all future discussions and deprecating the [email-masked] 
> list.
>
> Peter
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 23 Dec 2014 12:19:40 -0700

> to get work done under 1), to get sucked into debates about 2).

Ah, I am thinking of the post-URNBIS context. Once we finish 2141bis, 
the debates will be done. Or so I hope. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 24 Dec 2014 15:10:44 +0900

> the debates will be done. Or so I hope. :-)

I agree. Even now, the traffic isn't terribly high when averaged over a 
month or so, and while Sean definitely has a point, it's good that 
people who discuss the overall framework get exposed to actual examples 
and vice versa.

So I think we should put "[email-masked]" 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.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Thu, 25 Dec 2014 12:21:43 -0500

(Barry and IESG explicitly copied)

--On Wednesday, December 24, 2014 15:10 +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

>>> But there are two distinct controversies: 1) whether a
>>> proposed NID follows the URN rules sufficiently to permit
>>> registration, and 2) what the URN rules should be. It is
>>> very difficult for people who are trying to get work done
>>> under 1), to get sucked into debates about 2).
>> 
>> Ah, I am thinking of the post-URNBIS context. Once we finish
>> 2141bis, the debates will be done. Or so I hope. :-)
> 
> I agree. Even now, the traffic isn't terribly high when
> averaged over a month or so, and while Sean definitely has a
> point, it's good that people who discuss the overall framework
> get exposed to actual examples and vice versa.
> 
> So I think we should put "[email-masked]" 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 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.  The
problem is that, as we debate details of what should be
permitted in URN strings, it is at least theoretically possible
to slip registrations through a small mailing list and and
indifferent and noisy IETF LC process that would then give us
additional legacy compatibility problems.

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.

What is done is done and I think it would be ill-advised to
reopen the reviews on any namespace already approved and either
registered or in some phase of the post-approval publication
process, 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 and that authors or proponents of 

draft-atarius-dispatch-meid-urn
draft-atarius-dispatch-meid-urn-as-instanceid
draft-benjemaa-vbs-urn
draft-seantek-certspec-04
draft-seantek-rdf-urn-00
draft-seantek-xmlns-urn-00
draft-snell-social-urn-01
draft-spinosa-urn-lex-09

should be notified that their drafts [1] are going to be
referred to the WG for formal review when IETF Consensus
approval is formally requested.   Their alternative, of course,
is to encourage this WG to finish its work, after which a more
streamlined procedure will be in place.  If any of those authors
or would-be registrants believe their requests are urgent, let
them convince the WG, noting that a WG-approved request should
go through the IETF approval process more quickly and might even
qualify for a two-week Last Call. 

In addition, while I would hope to not delay it, someone should
send a note to this list requesting a quick review of
draft-murdock-nato-nid-03 when it appears.

I hope we can accomplish this change by an administrative
decision rather than by document-by-document appeals based on
the language of RFC 3406, the fact that there is a relevant WG,
and that the referrals have not been made.

    john

[1] List produced by a quick pass through the I-D Datatracker;
may not be complete.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 29 Dec 2014 15:37:15 -0500

> WG

One can hope, and I do.

> by blocking all pending and future URN namespace
> 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.

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.

> into being without formally asking the WG for it consensus

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.

> process

Thank you for being sensible about that.

> but I believe that the IETF Last Call on
> 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.

> and that authors or proponents of
>
> approval is formally requested.

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.

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

Barry, Applications AD

---

From: Sean Leonard <[email-masked]>
Date: Tue, 30 Dec 2014 01:45:43 -0800

> draft-seantek-xmlns-urn-00

Without commenting on the merits of any of the rest of that message…

Please note that draft-seantek-xmlns-urn-00 and draft-seantek-rdf-urn-00 have been replaced with draft-seantek-xmlns-rdf-urns-00, which incorporates prior feedback.

Due to ongoing uncertainty, draft-seantek-certspec-04 is being abandoned in favor of a much more straightforward set of approaches using URIs.

Sean

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Dec 2014 09:28:38 -0500

--On Monday, December 29, 2014 15:37 -0500 Barry Leiba
<[email-masked]> wrote:

>> should celebrate the new year and expected rapid progress in
>> the WG
> 
> One can hope, and I do.
> 
> 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.

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

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Dec 2014 10:31:31 -0500

> least some of them, and/or have your own).

Against my better judgment, I looked through this (that is
"looked through", not "read carefully").  I see multiple
problems which start with the observation that I know of at
least a few international legal document referencing systems
that would not fit this mold without considerable distortion
(I'm not an expert; if I were, I'd probably know of more); the
document commits Punycode abuse and, at the risk of appealing to
3986, there is no obvious reason to avoid use of %-encoding for
the non-ASCII cases they cite; they claim to be international,
but all of their thinking and examples seem to be tied to
sometimes-extended Latin script (in particular, Section 3.5
could create a huge mess and, for Section 3.9, someone should
explain to them what an "Arabic numeral" looks like); and so on.

As a slightly more complex example, Section 2.4 contains text
starting "In case of country code re-assignement...".  Perhaps
more study would help, but I'm not sure what it actually means
in practice but believe that it might violate the fundamental
principle of stability in URNs.

I also note that, while the introductory material (first
paragraph of 1.1) claims this is about legal materials and
sources of law and not, e.g., about legal doctrine, they
identify at least one example of a legitimate registrant who is
a source of law only in the wildest imagination of its more
doctrinaire adherents.  That particular example calls both the
consistency and the competence of the submission in this
particular area into question.

The naming authority model is also a bit muddy.  The
registration root should really be under control of an
international consensus body/authority, not a research
organization in one country (we've had more than enough proofs
of where the latter leads).  My skimming did not identify any
evidence that national legal/judicial authorities are willing to
sign up for the roles this document seems to give them, and so
on.

I spotted several other issues that might be more important but
that would require a lot more explanation.  One of them is
whether we should be using <foo>.urn.arpa for subtrees that have
neither network protocol implications or broad international use
and acceptance.  If there were the criterion, I don't know if
this would qualify.  Otherwise, and unless the i18n issues are
really sorted out, I'd think that consideration should be given
to whether something like <foo>.urn.eu would be appropriate.

I draw two conclusions for the above.  FIrst, there are a lot of
issues, some related to legal documents, some to URN (or URI)
niceties, and some to authority, that the document just does not
have sorted out yet.  Second, the IETF may be appropriate as a
place to sort out the best syntax model for registering an
established name space as a URN-embedded namespace, but we
should not be in the business of recognizing or ratifying naming
authorities, especially in areas we know almost nothing about
(either technically or in terms of socio-political
relationships).  Except where Internet protocols are concerned,
we should probably refer issues about defining namespace
fundamentals for particular fields to established and competent
bodies in those fields, let them establish their own standards,
and then work with them on URN embedding as needed.   That is
something we haven't written into 2141bis and, especially with
the elimination of experimental RFCs, we probably should figure
out how to say explicitly.   

For the case of this particular document, if the International
Federation of Library Associations and Institutions (IFLA) has
really been consulted, it would be reasonable to approach them,
ideally in consultation with ISO/TC 46, and define an
appropriate international standard that parallels the ISSN and
ISBN, or even DOI, work.  If not, I think we should suggest to
the authors that they try publishing a detailed description of
the underlying system in scholarly legal community journals of
appropriate scope and coverage (including an
internationally-broad editorial board and wide international
readership), see what feedback they get, and then strip this
document down to normative references about the theory and
organization of the namespace.  If they can't get such feedback,
or can't find a reputable and appropriate place to publish, then
no one relevant cares and the IETF should not be in the middle.

As an alternative, if they can get formal EU backing for this,
they might try registering a namespace that assigned codes and
jurisdictions for EU, IT, Brazil if they really want to play,
and any other EU countries they can get to sign up, reserve all
other codes for future expansion, designate the second-level
authorities (presumably ones who have formally agreed) in the
document, and come back to us with a revision plan when they can
show more international interest.  

Given the above and time constraints, I'm not willing to play
shepherd for this document unless at least those issues are
sorted out and clear endorsements and commitments are
established.  THe comments above may give you enough of a review
to get the draft out of "AD contemplation" state.

Melinda and Andy, these two notes seemed important, but sucked
up almost all of my URNBIS time for the week.  Schedule slipping
accordingly.

   john