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

John C Klensin <john-ietf@jck.com> Fri, 18 April 2014 19:53 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F2B1A0139; Fri, 18 Apr 2014 12:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.172
X-Spam-Level:
X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk6OH0NSAECp; Fri, 18 Apr 2014 12:53:28 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E00611A002E; Fri, 18 Apr 2014 12:53:27 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WbEqP-000DNP-77; Fri, 18 Apr 2014 15:53:05 -0400
Date: Fri, 18 Apr 2014 15:53:00 -0400
From: John C Klensin <john-ietf@jck.com>
To: Mark Nottingham <mnot@mnot.net>
Message-ID: <E0E032D69C38D6405A505541@JcK-HP8200.jck.com>
In-Reply-To: <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/cXlsriuac9CFWm2kQwxaNtARjC0
Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, urn@ietf.org, Graham Klyne <GK@ninebynine.org>, apps-discuss@ietf.org
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Apr 2014 19:53:31 -0000

--On Friday, April 18, 2014 11:44 +1000 Mark Nottingham
<mnot@mnot.net> 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.  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:

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

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

There is an additional potential discussion about what choices
we would make if we could turn the clock back to 1994 or 1996 or
about how things would have been defined in a better world
(perhaps turning some other clocks back to the 12th century or
earlier).  I think that discussion would be interesting and
educational, but that, for the IETF right now, it is just a
distraction, best injected into the two questions above only if
one's goal is to prevent progress.  Of course, some people may
disagree with that position and probably do.

Those who are not interested in the details of my thinking about
the first issue and the reasons why we are in this position can
safely stop reading now.

       -----------

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

More recently, Martin cites a number of articles and says
"Please don't come back here before you have read it!".  Some
members of another community consider some of the statements in
those articles to be a big joke, a massive demonstration of lack
of understanding, or worse.  Other statements help demonstrate
that we aren't making progress (for example, the 1998 "Model
Consequences" document Martin cites identifies the "views of URI
syntax" as a contrast between the "name ':' anything" approach
that Phillip brought up as the only reasonable possibility and
"uniform sharing of URI syntax to the extent it may make sense".


What seems to be different now from a few years ago is that
people in some of those other communities have reached the point
of being willing to do their own standards work, reflecting
their perceived needs, because they view their needs as real and
based on real experience and the IETF community as hopelessly
paralyzed and not listening.    Independent of whether they are
in-scope, the WHATWG and W3C efforts, and maybe the lack of
consensus and diminishing energy in the IETF IRI WG, may be
symptoms of that trend.   

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.

   john