[urn] draft-ietf-urnbis-semantics-clarif-04

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

Hi.

Well, as I feared, last week disappeared and it has taken me
until now to get this ready.  Barry knows some of the rest of
what has gotten in the way, but it isn't important.  The new
draft should be posted very soon.

This draft is an attempt to explore what the WG really wants.
When "URNs are not URIs" was written, and then transformed into
this document, my sense of the WG's preference was to keep it
short, high-level, and to the point.  From that perspective, I
probably removed too little material in the transformation
rather than two much.    Recent comments, especially from Julian
and Sean, and with no one speaking in opposition, suggest that
it needs to be far more specific and explicit about
justification, relationships to 3986 and other documents, and
exactly what it does or does not do.

I think this version does that.  It describes the disagreements
about how to read 3986 and this document in terms of bypassing
those disagreements rather than resolving them, is a lot more
explicit about what "updates 3986" means (although I think that
really was covered in Section 4 of -03), and so on.  It also
mentions the perceived problem that 3986 has a perspective (and
maybe some specific requirements) that are inconsistent with
2141/3406, an issue that was discussed at some length a few
years ago.

In reading the I-D, please note that I've inserted a note to the
RFC Editor below the Abstract (after this version, I will turn
it into a comment to them in the XML, but the WG should see it
now and understand its request to not nit-pick tense).   I've
also inserted a number of "CREF" comments that are intended to
call WG attention to particular issues or choices and solicit
input.  

A few artifacts of "URNs are not URIs" have been removed or
rewritten but, in reading this spec, the WG needs to understand
that the earlier approach and this "syntax only" one are
different approaches to address the same issue (even though the
problem itself can be characterized in multiple ways, something
I hope the I-D now makes clear).  The earlier one is easier to
understand and write about, but many people believe it had
adverse consequences, particularly for generic URI parsers and
processors.  The current one tries to made a much more subtle
distinction, one that is complicated by there not being a clear
dichotomy between syntax and semantics in 3986 (at least a
distinction that is apparently not clear to many people).

However, I'm fairly unhappy with the result (one reason this
wasn't posted Sunday is that I was even more unhappy with what I
had then).  It feels very tedious to me, spending a lot of words
and space repeating the same things in different words.  I've
left one section and a few paragraphs that were less redundant
but it don't seem to be necessary for this draft.  I've proposed
just dropping some of those and have asked questions about
others.

It seems to me that the WG now has a choice among (at least):

	(i) Deciding that this reflects what was want and is
	approximately good enough, plus or minus editorial work
	and cleaning out the CREF comments and maybe some
	sections or paragraphs.
	
	(ii) Deciding that this generally reflects what we want
	but needs extensive and/or substantive additional work.
	
	(iii) Deciding that the document has now served its
	purpose and should be dropped entirely, replaced by
	inserting a variation on the third and fourth paragraphs
	of the Introduction and as little of Section 4 as
	possible into 2141bis.

One of the things that is _not_ on the above list is revisiting
the "syntax only" decision.  I think the WG Chairs have rather
clearly closed that question and the purpose of this I-D (or
text in 2141bis to replace it under (iii) above) is just to
implement that decision.

Personal comment: I note that both (ii) and (iii) above are
likely to require significant energy and, unless something
changes with how the WG works, calendar time to settle on text
and reach consensus.  I therefore see those options as tradeoffs
against "getting done" and the risk of the WG running completely
out of steam before we can produce documents for IETF Last Call.
I also think that available time (or the WG, its leadership,
document authors, etc.) is much better spent getting the
technical and editorial details of 2141bis right rather than
striving for generally perfection or fussing with a
transitional/ explanatory documents like this one and
draft-ietf-urnbis-ns-reg-transition.    YMMD, but I think it
will help if people are explicit about our priorities.

Finally, it would be really helpful to making progress, and to
me personally, if people would read and comment on this quickly,
before everyone (including myself) loses track of what is in it
and why or of the list discussions that led to the changes in
it. 

 best,
     john