Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
John C Klensin <john-ietf@jck.com> Fri, 25 April 2014 17:51 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 24C131A02F2 for <urn@ietfa.amsl.com>; Fri, 25 Apr 2014 10:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.872
X-Spam-Level:
X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jx2Fz44O1jcM for <urn@ietfa.amsl.com>; Fri, 25 Apr 2014 10:51:21 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 676041A026A for <urn@ietf.org>; Fri, 25 Apr 2014 10:51:21 -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 1WdkHD-0001H5-4O; Fri, 25 Apr 2014 13:51:07 -0400
Date: Fri, 25 Apr 2014 13:51:02 -0400
From: John C Klensin <john-ietf@jck.com>
To: Edward Summers <ehs@pobox.com>, Mark Nottingham <mnot@mnot.net>
Message-ID: <11B3A42537CE2D687E206A34@JcK-HP8200.jck.com>
In-Reply-To: <FAB32F8D-4BE4-4E49-AE8E-022D322C3BCC@pobox.com>
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> <FAB32F8D-4BE4-4E49-AE8E-022D322C3BCC@pobox.com>
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/zVz8DaL-p7cL_TC4pAmnqYZ1OFM
Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, urn@ietf.org, Graham Klyne <GK@ninebynine.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, 25 Apr 2014 17:51:25 -0000
(apps-discuss removed) --On Friday, April 25, 2014 04:45 -0400 Edward Summers <ehs@pobox.com> wrote: >> While people don't want to consider it in-scope for this >> discussion, I also think that doing so will make the >> situation with WHATWG and W3C more manageable. > > I agree that, as distasteful as it might seem, it's quite > important to discuss the organizational (and personal) > politics involved, to the best of our ability, in a respectful > and constructive way. Pushing them off the table is just a way > of making them an implicit part of any work that we do, which > can result in difficulty in interpreting decisions later > on...which can be expressed as angels dancing on pins. If > possible I would like to hear how the proposed changes could > help make the WHATWG/W3C situation more manageable. Let me try to respond to this issue only, at least for the moment. I will do so in as balanced a way as I can, but you should understand, as you probably do already, that passions run high in this area. There has always [1] been a position that locators, in the form of URLs, are all that is needed and that, if more persistence is needed, that is an operational problem, not a conceptual one. For nearly as long, there have been positions that having a consistent and unified parsing model for all identifiers, or all identifiers used with the web, is a really good idea. Perhaps as a corollary to the latter, perhaps independently, there have been efforts to create a Grand Unified Identifier syntax, sometimes in the very restricted "scheme:<stuff>" form that Phillip proposed, sometimes with a lot of reserved characters and associated semantics, and sometimes in between. Some of those efforts have involved theorizing about how to solve (or that assume solutions to) problems that have been with us a very long time, even if not "always" [2], such as a unified model for naming. The tensions among those points of view have led to different communities talking past each other, sometimes thinking they agree and later discovering they don't and sometimes having discussions ended by exhaustion of one set of parties, leaving the others to claim consensus for publishing a document that more or less reflects their views. There is a separate, almost orthogonal, debate among views of what all of this is about. At one extreme, there is a community that says "The Internet is moving forward, growing, and reaching ever-increasing populations. The web is just part of it, although, at present, an important part. If we discover that we have gotten things wrong, or even severely sub-optimal, then it is appropriate to go back and get them right for the benefit of the next two billion, or, including extraplanetary use, the next hundred billion, uses even if that involves some short-term pain." At the other extreme, there is a community that says "The only part of the Internet that is really important to anyone is the web; everything else is either obsolescent or low-level transport technology that could be swapped out. Stability of the web is important and therefore the only meaningful standards are set by what people are doing (or have done) and that has worked. Speculation or theorizing about 'right' or 'best' ways of doing things is largely meaningless if it conflicts, or might conflict, with current practice". That debate and the tensions it causes are not limited to URIs. We see much the same patterns when, e.g., we start talking about internationalization issues, some security issues, and advanced user interfaces of various sorts. There are lots of positions between those two; on most issues, no one takes the most extreme positions. One can look at the present situation in at least three ways: (i) There is a community, perhaps the whole URN-ish community and perhaps only a subset with many years [3] of experience in cataloging, object, identification and the issues involved in talking about conceptual objects, including objects that exist in multiple copies and whether an object can exist in multiple media, different languages, etc., that have found the syntax and semantic constraints unreasonably restrictive given their perceived needs. From that perspective, that is the problem; the debate ought to be able solutions. Whatever else is going on with the community, it thinks it is right and cites centuries of experience to back up that claim. (ii) There is a community, perhaps closely related to the community that created RFC 3986 and perhaps not, that is determined to defend the concepts that underlay that model, syntax, semantics, and all. (iii) There is another community that is very dedicated to making the web work well and that has adopted some of the "it is all about the web" view caricatured above. They are sincere in their beliefs. And, while they may agree with the community in (i) about almost nothing else, they don't find RFC 3986 (and the boundary between it and 3987) appropriate to their needs. >From that set of perspectives, the problem that Mark and I have described in WHATWG/W3C terms (not entirely fair) could have a partial solution in common -- moving away from 3986/3987 as a an overarching and constraining identifier definition. If that happened, it could be a convenient side-effect. It is not, at least for me, a major goal. best, john [1] Measured in web time, i.e., a decade or two. [2] Consider archeological time, not web time. [3] Library/museum time, think many centuries.
- [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