Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Apr 18, 2014 at 3:53 PM, John C Klensin <[e-mail]> wrote:
>
>
> --On Friday, April 18, 2014 11:44 +1000 Mark Nottingham
> <[e-mail]> wrote:
>
>> I have to say that I'm sympathetic to the proposed outcomes,
>> albeit for different reasons, perhaps.
>>
>> We have two communities using a shared artefact (URIs) with
>> vastly differing use cases and viewpoints about them. Managing
>> this situation has already proven extremely difficult for the
>> IETF, and it seems to me to be very pragmatic to cease forcing
>> them to co-exist, constantly bickering about angels dancing on
>> pins.
>
> Mark,
>
> The above is actually a slightly different version of what drove
> me to propose the "separate URNs" change in the new draft.  As
> you say, we have two different communities with different
> assumptions, exemplars, and perceived needs.  The one thing they
> have in common is that neither accepts and interprets the
> examples of the other in the same way.

I think the disagreement is over what counts as an example.

Back in the early days of URNs I remember a lot of people telling me
that naming 'was hard' but could not explain why and that 'only a few
people understand it' but not who.

After a while I got rather tired of that mode of argument and decided
that I won't accept any argument that is not stated within the four
corners of the message or cited directly.


> Indeed, each community
> tends to reject the legitimacy of the position and arguments of
> the other and often to be dismissive and as far as I can tell,
> largely stops listening.  More on that below, but let me suggest
> there are two separate discussions that we can have now:

Well either a URN is a distinct class from a URL or it isn't.

One of the things that makes me rather suspicious about the argument
is that every URL is based on a name, that is either a DNS name or an
IP address both of which are names in tat the relationship between the
signifier and the signified is purely convention. (In the case of an
IP address the addresses are resolved via BGP)

Making a distinction between URIs that are based on a naming
infrastructure that is defined by the IETF and those that are not
seems to me to be a perfectly sensible approach for the IETF to take.


> (1) Whether to continue to try to defend a Grand Unified
> "Uniform Resource Identifier" theory (and, in your words,
> "shared artifact"), with each of those words meaning whatever it
> does to the person who pronounces it, or to let the communities
> you mention go off and develop solutions to their own perceived
> problems.  The predictable consequence of the first is going to
> be standards development elsewhere, rather than stopping what
> some perceive as bad behavior... we are just past "stopping"
> those communities with which some other community disagrees.

I am not sure what the above means. I can't parse it.

The IETF has limited bandwidth, the Internet has 3 billion users. So
less than 1/millionth of the Internet population is currently active
in IETF. Decisions and standards are going to get made in many places.

Whether any grand unified theory can be defended depends on the claims
made. If the claims made are extensive then the theory is likely to
collapse. If the claims are weak then it can be defended but has
little impact.


> (2) The details of what the community that the draft identifies
> as "content industries and memory organizations" need in URNs
> and how to organize that information.  I will comment on that
> subthread, but only on the URN list.

This is the part that I always have problems with, the idea that the
structure or syntax of the identifier has any impact on whether it
meets requirements such as long term resolution.

The only URI that is guaranteed to resolve to the signified content
unconditionally is the DATA method.

The only URIs that are shorter than the signified data that can claim
to be permanent are indexical, in most cases based on one way
functions such as 'hashes', 'fingerprints' and 'digests'.

Its not the syntax of a naming infrastructure that gives it longevity,
it is the political and business context in which it operates.


> Sadly, some of these same arguments --including the implied "I
> am right, you don't count, and I don't need to listen" tone of a
> subset-- go back to the original URI WG and some of the reasons
> I shut it down in 1995 (and resolved, unsuccessfully, to stay
> out of this area after that).

I don't think it was one side of the argument guilty of that.

Most of my objections to various URN schemes come from the confusion
of requirements and mechanism. If someone is saying that we must
recognize a set of URIs as 'special' because of a particular set of
requirements then I want to see a demonstration that

1) The particular set of requirements can be met

2) The distinction insisted on helps meet them


> It has become clear in URNBIS WG
> discussions that some of those in other communities sincerely
> believe that RFC 3986 doesn't represent consensus, only an
> example of how a determined minority can outlast and then
> overwhelm others (and, from their point of view, reason and
> experience).

Yep


> I'm still convinced that the IETF's experience, perspective, and
> scope still have useful things to bring to this discussion.
> Maybe I'm naive.  But it seems to me that the choice at this
> particular time isn't between how broadly URIs can reach, how
> much hair-splitting we can perform about "persistent" or
> "locator versus object identifier" but about whether we can
> separate things sufficiently to let the two (or more)
> communities go their own ways under a broad IETF umbrella or
> whether we prefer standardization work in this set of areas to
> be done elsewhere, most likely (given trends in W3C and WHATWG
> as well as in URNBIS) with most of the relevant groups agreeing
> only the 3956 is not relevant to their needs and plans.

Which is precisely why I suggest dividing the world up into 'that
which the IETF is authoritative on' and 'that which the IETF is not
authoritative on'.

-- 
Website: http://hallambaker.com/