[urn] draft-ietf-urnbis-urns-are-not-uris

[Larry Masinter <[e-mail]>]

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12070.html
"we'd like the discussion in Toronto to be the resolution,
 not the start of the conversation."

The document does not describe the problem for which the
proposal is the solution. I believe there are problems that urn's
and uri's don't solve, I acknowledge there are people for
whom these problems are important. I am not convinced
that there are new problems we didn't think about 20 years
ago, or that the proposal is either necessary or sufficient to solve
any of them. I'm not sure, though; the doc does not supply 
sufficient detail.

We already have a forked specification, the OASIS XRI.
http://en.wikipedia.org/wiki/Extensible_resource_identifier
initiated for similar concerns. It seems quite a bit more thought
out than the urnbis proposal and doesn't seem to require 
any change to 3986.

3986 fragments have problems beyond those in
 http://www.w3.org/2001/tag/doc/mimeTypesAndFragids
And I think letting the fragment depend on the scheme first
(with the default depending on retrieved media type)
would allow 'urn:' to define fragments (and xri too).

I think I've provided evidence that the needs of the
library community were well-considered at the time
when URNs were specified. I haven't seen any
evidence of new requirements arising or discovered
in the intervening 20 years.
I haven't seen any new solutions to requirements
for which splitting URN from URI would help.

In 1998 
http://larry.masinter.net/eudl/eudl-part3b.pdf#page=7
"Internet Technologies for Digital Libraries"  notes
the question of URL  syntax constraining URN syntax.

The 2001 document
" URIs, URLs, and URNs: Clarifications and Recommendations 1.0
Report from the joint W3C/IETF URI Planning Interest Group
W3C Note 21 September 2001"
http://www.w3.org/TR/uri-clarification/
should also be an informative reference and responded
to.


> The issue is whether, based on their experience, their perceived
> needs should be accommodated. .    I started to say "are entitled
> to be accommodated", but that isn't ultimately the point either.

Sure, needs are entitled.

> Instead, if they feel strongly enough about those needs --and
> the WG has heard from far more than Juha, with people and
> institutions of multiple varieties based on multiple countries
> (and I've heard even more) to at least entertain a strong
> hypothesis that they do-- will they move off to create a
> standard of their own if the IETF says, e.g., "no, we, based on
> the ideas of Larry or others, don't believe you need to do
> that"

It already happened with XRI, doi, xmp.did, 
 (http://tools.ietf.org/html/rfc6920 ) and zillions
of other  ways of invented to naming. Naming is
powerful and valuable.

> I'm convinced that they will and am a bit surprised they haven't
> done so already (Juha and others have been exerting superhuman
> efforts to avoid that outcome).  YMMD, but I'm convinced that
> the costs of two inconsistent definitions of "URN" would be
> sufficiently high that it trumps the claimed advantages of
> trying to preserve an overarching RFC 3986. 

It's fine to invent a new way of naming things, but calling your
new way "urn:" is just rude and unnecessary. 

 > While the issues
> are completely separate from the URN one, the view that
> preservation of 3986 and its current definitions across the
> whole range of whatever people choose to call URIs is not worth
> shedding blood over (or even further constraining URNs or
> slowing URNbis over) is somewhat reinforced by efforts in W3C
> and WHATWG to change the URL definition in ways that, to me,
> also look incompatible with 3986.

Solving the WHATWG / W3C / IETF / Unicode consortium / 
ICANN / IDN coordination issue over things UR* is a problem 
as worthy (dare I say, even MORE worthy) of taking on, 
but I'm not at all convinced that  cleaving URN out of URI
is part of the solution. The main problem is turf, which
technology cannot solve by itself. 

Larry
--
http://larry.masinter.net