Re: [urn] Tuning the "URNs are not URIs" spec

Hello John, others,

Your text proposal below is helpful because it shows how you frame the 
current discussion in terms of standard politics and procedures.

First, you mention "several discussions". These discussions may have 
lead you to certain conclusions, but it doesn't mean that WG members can 
make the same (or maybe other) conclusions without getting more 
information on these discussions, either from you or from the other 
people involved (or preferably from both).

I have no idea about the content of these discussions, but just for 
devil's advocate, there would be a huge difference between e.g. some of 
these discussions including very clear indications (even threats) of 
"having that work done elsewhere" and e.g. discussants showing little or 
no understanding for the (real or perceived) needs of (some parts of) 
the library community. Maybe there was both, or there was something else 
althogether.

So I would strongly urge you and others who have been involved in these 
discussions to inform the WG and therefore the public via this list.

Second, and more important, is that your document starts at the wrong 
end. Section 2 may be a good start for a requirements document. And 
based on that, it may be possible to work out how to address the various 
issues brought up. After discussion of each of the requirements and 
possible solutions addressing these, we would end up with a spec that 
may or may not have some discrepancies with RFC 3986. It is at this 
point, and only at this point, that we can with good faith decide to put 
something like the current Section 3 into the spec, and to label the 
document as "updates 3986". Cutting ties before we know we need to cut 
them is hopelessly premature.

I don't currently have the time to go through all nine items in Section 
2 (*). But in order to show that what I said in the previous paragraph 
is important, I'm going to pick out one item and explain my concerns in 
more detail:

    7.  Persistent identification must be available for resources which
        are available only in databases and other environments that are
        often identified today as "deep web".  URIs for these resources
        tend to be very complicated and it will be difficult to keep them
        alive even with the help of DNS redirection when e.g.  the
        underlying database management system changes.

Reading this, I don't see any point I would have to disagree with. But 
there is also nothing I can see or even guess that would suggest that 
persistent identification (meaning URNs, yes?) and URIs need to be 
separated. It is already possible with current syntax to define URNs for 
resources in the "deep web". Keeping the correspondence between such 
URNs and their referent will be difficult when the underlying database 
management system changes. As far as I can see, that's not URI's fault 
and not URN's fault, and isn't affected, positively or negatively, by 
separating URNs from URIs. Similar for length issues. It's possible to 
define short URNs or short URIs if that's what is needed. Both for URNs 
and for URIs, there are ample examples. Again, length issues are not 
affected, positively or negatively, by separating URNs from URIs.

So at the minimum, items such as item 7 need a lot more work to make the 
connection to Section 3 way clearer. Or they should just be removed as 
non-sequiturs, leaving only those items (if any) that actually support a 
conclusion such as that in Section 3.

So in summary, I'd strongly suggest to invest *way more* work into the 
technical aspects of this document. The IETF has a very strong and 
healthy tradition of putting technical arguments first. It is my strong 
belief that if the technical arguments are actually there and are 
presented well enough, then political/procedural text such as the 
appendix below won't be necessary. On the other hand, if the technical 
arguments can't be found, then again the appendix below (and the whole 
document) will become irrelevant.

Regards,    Martin.

(*) I note in passing that the paragraphs between item 8 and 9, and 
those after item nine, should be formatted to be part of the preceding 
item).

On 2014/06/14 17:25, John C Klensin wrote:
> Hi.
>
> After several discussions in the last two weeks, including two
> very significant (to me at least) offline and face to face ones,
> it seems to me that the explanation in
> draft-ietf-urnbis-urns-are-not-uris-00 may be missing the point
> or be irrelevant to some people.  Consequently, I propose to add
> the following text to the I-D.  It was written on the assumption
> that it would be an appendix but that is not a firm decision or
> anything we need to decide now.  If we do want to keep it for
> the long term (as distinct from helping with discussion in the
> interim), perhaps we should think about creating two subsections
> of Section 2, one more or less the present Section 2 and the
> other a variation on the text below.
>
> In any event, comments welcome on the text below.  Unless the
> general sense of the WG is that it sets us backwards, I'd
> generate and post a new draft that incorporates it (and any
> agreeable modifications) sometime next week.  Again, having the
> text at this point is not a commitment for it to be in the final
> document.  The question, IMO, is whether it will help to move
> the discussions forward and thereby contribute to getting the
> WG's work unstuck.
>
>      john
>
>     ----- Proposed text -----------
>
> Appendix A.  A More Pragmatic Perspective
>
>     Section 2 provides an explanation of the reasons for this
>     change.  That explanation is not without controversy,
>     especially from those who make different assumptions about
>     the future, or even interpretations of the present, than
>     many members of the community (and especially members of
>     the communities describe in that section).  Some of those
>     who do not accept the explanation above simply do not
>     recognize the distinctions on which it, and URNs more
>     generally, are based, including the name-locator
>     distinction.  In some cases, opposition to that explanation
>     is quite pronounced, involving fundamental differences in
>     philosophy that move beyond mere differences of opinion.
>
>     Like most controversies in which one group does not accept
>     the definitions, facts, or logic of another, the
>     differences are unlikely to be resolved by further
>     discussion, no matter how sensible and patient.  The
>     material in this appendix is provided for the benefit of
>     those who cannot accept Section 2 or consider the
>     discussion there to be meaningless.
>
>     Independent of the details of the discussion above, in the
>     case of URNs, the IETF is faced with a pair of problems
>     that are ultimately faced sooner or later by all voluntary
>     standards bodies: nothing except quality and broad
>     community consensus prevents a standard from being ignored
>     in the marketplace and nothing prevents another body from
>     creating a competing standard.  The effort required to
>     create a competing standard can be increased and its
>     potential for confusion can be reduced somewhat by various
>     measures -- measures the IETF has rarely tried to actually
>     use -- but those measures are rarely effective when the
>     other body is convinced that they have legitimate and
>     significant needs that differ from the original atandard.
>     Because of those problems, the key question for the URN
>     effort is ultimately not whether a clear enough distinction
>     exists between names and locator or location-based
>     information, nor whether "persistent" can be defined
>     clearly enough, nor even whether the communities and
>     requirements described in Section 2 are valid or will be
>     judged valid in retrospect in a few decades or centuries.
>     Instead, the question is whether the IETF is willing to
>     evolve and adapt the URN definition to accommodate those
>     perceived needs or whether if prefers to have that work
>     done elsewhere, either by adoption in the broader
>     community and marketplace of a different approach or,
>     potentially, even a competing URN standard.  If, in the
>     long run, those other communities and perspectives turn
>     out to be wrong, the additional features will atrophy.  But
>     that would be true whether they are specified and
>     standardized in the IETF or elsewhere.
>
>   --- end proposed text -----------
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>