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
- [urn] URNs are not URIs (another look at RFC 3986) John C Klensin
- Re: [urn] URNs are not URIs (another look at RFC … Julian Reschke
- Re: [urn] URNs are not URIs (another look at RFC … John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Martin J. Dürst
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Graham Klyne
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Graham Klyne
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Larry Masinter
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Julian Reschke
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Julian Reschke
- Re: [urn] URNs are not URIs (another look at RFC … Dale R. Worley
- Re: [urn] URNs are not URIs (another look at RFC … Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Mark Nottingham
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Graham Klyne
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Scott Brim
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Mark Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] URNs are not URIs (another look at RFC … John C Klensin
- Re: [urn] URNs are not URIs (another look at RFC … Barry Leiba
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Scott Brim
- Re: [urn] URNs are not URIs (another look at RFC … John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Barry Leiba
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Mark Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Martin J. Dürst
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Martin J. Dürst
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Larry Masinter
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Tony Finch
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Maurizio Lunghi
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- [urn] R: [apps-discuss] URNs are not URIs (anothe… Maurizio Lunghi
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Larry Masinter
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Edward Summers
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… jehakala
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Juha Hakala
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Svensson, Lars
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… SM
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… jehakala
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… SM
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Henry S. Thompson
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Henry S. Thompson