From nobody Mon Apr 7 14:31:43 2014 Return-Path: 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 7B7221A07F7; Mon, 7 Apr 2014 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ptpcm65QB6WR; Mon, 7 Apr 2014 14:31:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B084A1A07C6; Mon, 7 Apr 2014 14:31:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140407213135.31812.9436.idtracker@ietfa.amsl.com> Date: Mon, 07 Apr 2014 14:31:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/haDjzUpfY9NBSmKsOOEUAIStac4 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-urns-are-not-uris-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 21:31:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Names are Not Locators and URNs are Not URIs Author : John C Klensin Filename : draft-ietf-urnbis-urns-are-not-uris-00.txt Pages : 7 Date : 2014-04-07 Abstract: Experience has shown that identifiers associated with persistent names are quite different from identifiers associated with the locations of objects. This is especially true when such names are are expected to be stable for a very long time or when they identify large and complex entities. In order to allow Uniform Resource Names (URNs) to evolve to meet the needs of the Informational Sciences community and other users, this specification separates the syntax for URNs from the generic syntax for Uniform Resource Identifiers (URIs) specified in RFC 3986, updating the latter specification accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-urns-are-not-uris/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 7 14:47:13 2014 Return-Path: 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 AD06A1A02CB for ; Mon, 7 Apr 2014 14:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 Y227wmIv_Wx8 for ; Mon, 7 Apr 2014 14:47:02 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E4F6C1A027A for ; Mon, 7 Apr 2014 14:47:01 -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 ) id 1WXHNY-000JOS-7c for urn@ietf.org; Mon, 07 Apr 2014 17:46:56 -0400 Date: Mon, 07 Apr 2014 17:46:51 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <5851702C574A854E3EB322CA@JcK-HP8200.jck.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/PbtYIcClEN4iTy9arG4eZlkLSfo Subject: [urn] Explanation of draft-ietf-urnbis-urns-are-not-uris- and call for review X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 21:47:08 -0000 Hi. Noting that, even though I've edited a few documents and contributed to some others, I have no "official" position in the WG and speak only for myself. That said, as everyone has probably noticed, things have been stalled. Like others, I've been trying to get them unstuck (that should be no surprise to anyone following the list in the last several months). My analysis of where we have been and where we are is: * A major source of the blockage has been difficulties in figuring out how one can think about queries on, or portions of, a resource or its metadata while remaining consistent with the syntax and definitions of RFC 3986. Arguments about fragments have been very much part of the problem thinking and discussions. * After a number of private discussions, several of us came to the conclusion that the root of the problem has been the conflation of 3986 (with its roots in URLs) with URNs and persistent identifiers. * We have therefore prepared a draft that explains the issues and that asserts that considering URNs as a member of the set of generic URIs is inappropriate (and has been since RFC 3986 was published). If approved, it will remove URNs from the scope of RFC 3986 Generic URIs. That draft has been posted as draft-ietf-urnbis-urns-are-not-uris-00. * If the WG agrees with that approach, the next step will be to revise 2141bis to be self-contained (rather than depending on 3986) and to provide a framework for extensions appropriate to URNs. Obviously the next step is WG review and comments on the new draft. I/we expect significant pushback to this "URNs are not URIs" move so, if the WG isn't sure it wants it, the idea is going nowhere... and people need to come up with some other idea as to how to make progress and/or why Barry shouldn't shut us down for failure to do so. john From nobody Wed Apr 9 09:52:44 2014 Return-Path: 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 D36C71A03B5 for ; Wed, 9 Apr 2014 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 9Q_mMelxcUzx for ; Wed, 9 Apr 2014 09:21:14 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 0635A1A03B9 for ; Wed, 9 Apr 2014 09:21:08 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta08.westchester.pa.mail.comcast.net with comcast id npWj1n0041wpRvQ58sM8th; Wed, 09 Apr 2014 16:21:08 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta18.westchester.pa.mail.comcast.net with comcast id nsM71n00q1KKtkw3esM815; Wed, 09 Apr 2014 16:21:08 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s39GL7gV012490; Wed, 9 Apr 2014 12:21:07 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s39GL5Xp012482; Wed, 9 Apr 2014 12:21:05 -0400 Date: Wed, 9 Apr 2014 12:21:05 -0400 Message-Id: <201404091621.s39GL5Xp012482@hobgoblin.ariadne.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: John C Klensin In-reply-to: <5851702C574A854E3EB322CA@JcK-HP8200.jck.com> (john-ietf@jck.com) References: <5851702C574A854E3EB322CA@JcK-HP8200.jck.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397060468; bh=hEJA544SSWCXpYeC3CiR62ujHWyIAV3qoLcq5cWSUlE=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=O9wUvvJdvYrRWdCdIr1eHVH1yRcOf6RD2A5Qj/wgL5Rg2Y8Yb4gVGXbBieE1io3nT Ra6KOOaBQCMkUlb3qNSCfRrlCo14ExkL8+LjUGwUD4ozZVg1JlyREYvzzrId6Fb8H9 NLz8iuPZp+PvFweQae0B+Rs06geQhMfPtyT3Rjt7WLeeiAvyalLSRdrFs04pZuYytp 7qA3mxLLxoYQVphoxgD/6VJWSCdszsbraNC17UGCoD6vsxpDQqrFlWQUOqfJ6HJ4P4 aHEGO6Qf+nBMTkHry40PLVUfw+ymVeS2QWO8y2ENORawOVsAXRAhqqUe95oOzncEY2 fbwc0HIPILorw== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/p2USKBguneyuIZhLJ4VRDVtDJko X-Mailman-Approved-At: Wed, 09 Apr 2014 09:52:41 -0700 Cc: urn@ietf.org Subject: Re: [urn] Explanation of draft-ietf-urnbis-urns-are-not-uris- and call for review X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 16:21:15 -0000 I'm not sure I see the significance of this draft. My understanding of "URIs" is: (1) A URI "indicates" some "resource" -- with both quoted words having a very broad range of meaning. (2) All URIs conform to a particular syntax, and in particular, the "schema" part of a URI is well-defined. (3) The semantics of a generalized URI is not defined, other than that the schema specifies how the remainder of the URI is to be interpreted. (3) Some URIs are "locators" and are called "URLs", which provide adequate information to access the resource over the network. Certain URI schemas are considered to consistently indicate URLs. (4) Some URIs are "names" and are called "URNs", which provide unique and persistent indicators for well-defined resources. URIs with the "urn" schema are all URNs. Essentially, the only thing all URIs share is a syntax and that the schema tells how to interpret the remainder of the string. The fact that URIs all share the same syntax seems to be useful, because there are situations where you don't want to have to specify a priori that only URLs or URNs may be used. E.g., "Namespaces in XML 1.0", section 2.1: "Definition: An XML namespace is identified by a URI reference [RFC3986]", where both urn: and http: URIs are popular as namespace names in practice. This draft is arguing that the *syntax specification* of URNs should be decoupled from the syntax specification of URLs, but it doesn't seem to make any claims that the URI *syntax* is inadequate for URNs. Of course, the semantics of URNs and URNs are quite different, but that doesn't seem to have any bearing on the syntax question. Dale From nobody Wed Apr 9 10:43:30 2014 Return-Path: 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 289581A02C2 for ; Wed, 9 Apr 2014 10:43:28 -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 Qb126LkK3-0G for ; Wed, 9 Apr 2014 10:43:26 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2D05E1A02EE for ; Wed, 9 Apr 2014 10:43:25 -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 ) id 1WXwWx-000MgO-W1; Wed, 09 Apr 2014 13:43:23 -0400 Date: Wed, 09 Apr 2014 13:43:18 -0400 From: John C Klensin To: "Dale R. Worley" Message-ID: In-Reply-To: <201404091621.s39GL5Xp012482@hobgoblin.ariadne.com> References: <5851702C574A854E3EB322CA@JcK-HP8200.jck.com> <201404091621.s39GL5Xp012482@hobgoblin.ariadne.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/7IGIa93W2s8c8gIfWN4XLx1gBzk Cc: urn@ietf.org Subject: Re: [urn] Explanation of draft-ietf-urnbis-urns-are-not-uris- and call for review X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 17:43:28 -0000 --On Wednesday, April 09, 2014 12:21 -0400 "Dale R. Worley" wrote: > I'm not sure I see the significance of this draft. > > My understanding of "URIs" is: > > (1) A URI "indicates" some "resource" -- with both quoted > words having a very broad range of meaning. > > (2) All URIs conform to a particular syntax, and in > particular, the "schema" part of a URI is well-defined. > > (3) The semantics of a generalized URI is not defined, > other than that the schema specifies how the remainder of > the URI is to be interpreted. 3986 goes a little beyond that in that semantics (or at least partial semantics) _are_ assigned to certain pieces of syntax. To take a handy example that has become part of the URN problem/ argument (at least as several of us have read 3986), if there is a "#" out there in the right end of a generic URI [1], it is required to be treated as a fragment identifier with the requirement that the resource be approved and then the fragment identifier be interpreted. Certainly the semantics of what that identifier "means" is at least a function of the URI type/schema and may be a function of the resource itself. But the whole concept of "retrieve all of it and then sort the fragment identifier out" may be completely wrong for persistent, abstracted-name-based, identifiers of digital objects, specifically when those identifiers have nothing to do with locations on the web. > (3) Some URIs are "locators" and are called "URLs", which > provide adequate information to access the resource over > the network. Certain URI schemas are considered to > consistently indicate URLs. Note (3) twice. I'm not sure what "consistently indicate URLs" means, especially in the light of other recent developments [2] > > (4) Some URIs are "names" and are called "URNs", which > provide unique and persistent indicators for well-defined > resources. URIs with the "urn" schema are all URNs. > > Essentially, the only thing all URIs share is a syntax and > that the schema tells how to interpret the remainder of the > string. If that were actually true, the draft would be unnecessary. Instead, RFC 3986 effectively says "if these characters appear in the syntax, they have the following meaning and must be interpreted in the following way". What follows doesn't specify complete semantics, but is complete enough to be a big problem if one departs from network-based locators to provide identifiers (as that term is understood by the library, information science, and related communities) for digital and non-digital objects of various sorts. > The fact that URIs all share the same syntax seems to be > useful, because there are situations where you don't want to > have to specify a priori that only URLs or URNs may be used. > E.g., "Namespaces in XML 1.0", section 2.1: "Definition: An > XML namespace is identified by a URI reference [RFC3986]", > where both urn: and http: URIs are popular as namespace names > in practice. Viewed from that perspective, yes, as long as it doesn't force conditions on the URNs which make them unsuitable for their purpose. (and as long as it doesn't force unreasonable constraints on URLs either [2]). A different way to say both what I'm saying and what WHATWG and maybe W3C are saying is that, it trying to define a generic syntax with partial semantics that would apply to a very range of "identifiers" (some of which, in information sciences terms, probably aren't) was overreaching from the state of our understanding at the time. Especially in the light of other work [2], producing a spec as an alternative to this one that would have said "3986 overreached, it applies only to URLs and that only temporarily" would have been an alternative to this one, but it would clearly have been beyond the scope of a URNBIS WG and would probably have gotten everything thoroughly bogged down. In the example you give, the processor (or comparison action) has to know how to handle http URLs and URNs differently today. For it, this changes nothing other than the vocabulary. Conversely, if you tell me that the generic URI spec provides enough information to compare those namespace identifiers against a fixed or stored string for identity, I'll claim it is further evidence that there are semantics in the supposedly semantic-free generic spec. > This draft is arguing that the *syntax specification* of URNs > should be decoupled from the syntax specification of URLs, but > it doesn't seem to make any claims that the URI *syntax* is > inadequate for URNs. Yes, it does. I didn't want to spell that out more than I did (the above "fragment" issue is just one example) because that seemed a job for 2141bis. I also didn't spell something else out: this WG or its successors would be insane to allow new URNs that do not conform to the syntax of 2141 much less to invalidate any now-valid one. The question is how to create and integrate extensions for functionality that now seems necessary. A few of those functions were explicitly anticipated in 2141, and that is where problems start to arise. Of course, if the WG agrees to the principle but wants more text in one place or the other, that is easily done. > Of course, the semantics of URNs and URNs are quite different, > but that doesn't seem to have any bearing on the syntax > question. See above. Thanks for reading it and commenting. john [1] Deliberately avoiding use of the specific 3986 terminology here. [2] It is not an issue for this WG, but there are efforts in WHATWG and elsewhere to redefine URLs and IRIs (IRLs?) in a way that, apparently, would partially subsume the latter into the former and then fork both from the 3986/398y specs. From nobody Thu Apr 10 20:36:02 2014 Return-Path: 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 D7EEF1A0020 for ; Thu, 10 Apr 2014 20:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_21=0.6] autolearn=no 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 QzgnklSXc0cM for ; Thu, 10 Apr 2014 20:35:51 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id F04AE1A001D for ; Thu, 10 Apr 2014 20:16:05 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id oT8y1n0011vXlb855TFx8W; Fri, 11 Apr 2014 03:15:57 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta17.westchester.pa.mail.comcast.net with comcast id oTFw1n00H1KKtkw3dTFwxb; Fri, 11 Apr 2014 03:15:57 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3B3FtTI018405; Thu, 10 Apr 2014 23:15:55 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3B3FsZs018403; Thu, 10 Apr 2014 23:15:54 -0400 Date: Thu, 10 Apr 2014 23:15:54 -0400 Message-Id: <201404110315.s3B3FsZs018403@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: John C Klensin In-reply-to: (john-ietf@jck.com) References: <5851702C574A854E3EB322CA@JcK-HP8200.jck.com> <201404091621.s39GL5Xp012482@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397186157; bh=Kv73Hb2+K835pygdbkLmnw2JLoiTFYsWJ1Ey1yMQnz8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=FGcm1uNLoXcYx1v1/r2BtHW34Tk+LJS+noUMazC7jfszg6LfX4CvggD8C0qEyelAs sH76ax4C1LVTlMTcj01K+0yEeKKPMQygb4MPSfnQcbYUr9QMTYE2ZPfLvzKBO1a/Ww 415Bl+gjODw2BN5eTVSLWcPh6DOp+lliXSXnTioZB8yk6o9phzdu8SVLSaok0lvD0p Mb91vYhF3CLboKmKSDrmQq0Pd2M/wYtFA9zn/nFlNBkWocKHb4azypUspn/PNXPpC3 PJVopB5WCoTaE85waBo8QOFLBeJY9U4ly4a+BTr70gt5I+f2OwXxIZNINGBN+ipgxy QmSCiFrzvlltA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/j1UbANPINakRs-kbIMRlDFFn2Cc Cc: urn@ietf.org Subject: Re: [urn] Explanation of draft-ietf-urnbis-urns-are-not-uris- and call for review X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 03:36:00 -0000 > From: John C Klensin > 3986 goes a little beyond that in that semantics (or at least > partial semantics) _are_ assigned to certain pieces of syntax. > To take a handy example that has become part of the URN problem/ > argument (at least as several of us have read 3986), if there is > a "#" out there in the right end of a generic URI [1], it is > required to be treated as a fragment identifier with the > requirement that the resource be approved and then the fragment > identifier be interpreted. Certainly the semantics of what that > identifier "means" is at least a function of the URI type/schema > and may be a function of the resource itself. But the whole > concept of "retrieve all of it and then sort the fragment > identifier out" may be completely wrong for persistent, > abstracted-name-based, identifiers of digital objects, > specifically when those identifiers have nothing to do with > locations on the web. Aye, yes. I've spent quite a bit of time with the ABNF of 3986 but never had to deal with the bits that discuss semantics. And despite its title of "Uniform Resource Identifier (URI): Generic Syntax", there is text about semantics. One semantic part is the process of interpreting relative URLs, which forms a constraint on the semantics of any URI which can have a "/" after the "scheme:". But URNs are prohibited from doing that, so that's not relevant for URNs. Or rather, the "urn" scheme is prohibited from doing that and it is not relevant for them. Which leads to a subsidiary question, are there going to be other URN schemes than "urn"? The semantic part that seems problematic is the "fragment". The text of section 3.5 is somewhat vague but does make it clear that the use of the fragment is determined by the media type of the object referenced by the base URI, not by the scheme: "Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." That's problematic if URNs want to use the fragment in any other way. But I don't see any other problems. It seems to me that the problem is to decouple the *semantics* of URNs from what little is said about semantics in 3986. We really, really do want to constrain future URNs to stay within the 3986 syntax, or whatever the future syntax is for the whole set of UR*s. > I'm not sure what "consistently indicate URLs" means, especially in > the light of other recent developments [2] I was thinking of "http:". > > Essentially, the only thing all URIs share is a syntax and > > that the schema tells how to interpret the remainder of the > > string. > > If that were actually true, the draft would be unnecessary. > Instead, RFC 3986 effectively says "if these characters appear > in the syntax, they have the following meaning and must be > interpreted in the following way". What follows doesn't specify > complete semantics, but is complete enough to be a big problem > if one departs from network-based locators to provide > identifiers (as that term is understood by the library, > information science, and related communities) for digital and > non-digital objects of various sorts. Is there any problem other than the fragment? Comparing the draft to 3986, I don't see it make a forceful argument that there are any others. > > This draft is arguing that the *syntax specification* of URNs > > should be decoupled from the syntax specification of URLs, but > > it doesn't seem to make any claims that the URI *syntax* is > > inadequate for URNs. > > Yes, it does. I didn't want to spell that out more than I did > (the above "fragment" issue is just one example) because that > seemed a job for 2141bis. I'm not tracking here. The draft advocates for "this specification separates the syntax for URNs from the generic syntax for Uniform Resource Identifiers (URIs) specified in RFC 3986, updating the latter specification accordingly." But I don't see the argument for it. I can certainly see the argument for separating the *semantics*, especially in regard to the fragment (if people have plans for its use in URNs). BTW, are there plans for URNs to use fragment for some other purpose? Why can't URNs simply not use fragment at all? (Which is pretty much what they do now, although I suppose a fragment is now defined if the URN happens to specify a particular representation of a media object.) Perhaps the point is that this draft is the output of a long discussion which I haven't seen. But in that case, why does it include the "critical issues include" section? It really reads as if it's the beginning of a discussion, not the end of one. > I also didn't spell something else > out: this WG or its successors would be insane to allow new URNs > that do not conform to the syntax of 2141 much less to > invalidate any now-valid one. True, but it seems to me those are the *most important* constraints on change going forward, and it is important to list them. Dale From nobody Thu Apr 10 22:02:30 2014 Return-Path: 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 AF7731A02CB for ; Thu, 10 Apr 2014 22:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.126 X-Spam-Level: * X-Spam-Status: No, score=1.126 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 LdREC3ocZWQG for ; Thu, 10 Apr 2014 22:02:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E61A11A0280 for ; Thu, 10 Apr 2014 22:02:25 -0700 (PDT) Received: from aither.local (unknown [71.94.217.18]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8578940352; Thu, 10 Apr 2014 23:02:23 -0600 (MDT) Message-ID: <5347775D.1010808@stpeter.im> Date: Thu, 10 Apr 2014 22:02:21 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Dale R. Worley" , John C Klensin References: <5851702C574A854E3EB322CA@JcK-HP8200.jck.com> <201404091621.s39GL5Xp012482@hobgoblin.ariadne.com> <201404110315.s3B3FsZs018403@hobgoblin.ariadne.com> In-Reply-To: <201404110315.s3B3FsZs018403@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/6TtDNcP-Vl5jkNH5cZRHZR2EcT0 Cc: urn@ietf.org Subject: Re: [urn] Explanation of draft-ietf-urnbis-urns-are-not-uris- and call for review X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 05:02:29 -0000 On 4/10/14, 8:15 PM, Dale R. Worley wrote: >> From: John C Klensin > >> 3986 goes a little beyond that in that semantics (or at least >> partial semantics) _are_ assigned to certain pieces of syntax. >> To take a handy example that has become part of the URN problem/ >> argument (at least as several of us have read 3986), if there is >> a "#" out there in the right end of a generic URI [1], it is >> required to be treated as a fragment identifier with the >> requirement that the resource be approved and then the fragment >> identifier be interpreted. Certainly the semantics of what that >> identifier "means" is at least a function of the URI type/schema >> and may be a function of the resource itself. But the whole >> concept of "retrieve all of it and then sort the fragment >> identifier out" may be completely wrong for persistent, >> abstracted-name-based, identifiers of digital objects, >> specifically when those identifiers have nothing to do with >> locations on the web. > > Aye, yes. I've spent quite a bit of time with the ABNF of 3986 but > never had to deal with the bits that discuss semantics. And despite > its title of "Uniform Resource Identifier (URI): Generic Syntax", > there is text about semantics. > > One semantic part is the process of interpreting relative URLs, which > forms a constraint on the semantics of any URI which can have a "/" > after the "scheme:". But URNs are prohibited from doing that, so > that's not relevant for URNs. Or rather, the "urn" scheme is > prohibited from doing that and it is not relevant for them. RFC 2141 says: RFC 1630 [2] reserves the characters "/", "?", and "#" for particular purposes. The URN-WG has not yet debated the applicability and precise semantics of those purposes as applied to URNs. Therefore, these characters are RESERVED for future developments. Namespace developers SHOULD NOT use these characters in unencoded form, but rather use the appropriate %-encoding for each character. So "prohibited" seems a bit strong. > Which leads to a subsidiary question, are there going to be other URN > schemes than "urn"? I don't think so. > The semantic part that seems problematic is the "fragment". The text > of section 3.5 is somewhat vague but does make it clear that the use > of the fragment is determined by the media type of the object > referenced by the base URI, not by the scheme: "Fragment identifier > semantics are independent of the URI scheme and thus cannot be > redefined by scheme specifications." That's problematic if URNs want > to use the fragment in any other way. > > But I don't see any other problems. It seems to me that the problem > is to decouple the *semantics* of URNs from what little is said about > semantics in 3986. We really, really do want to constrain future URNs > to stay within the 3986 syntax, or whatever the future syntax is for > the whole set of UR*s. I think that's the question here, or one of them. One thing that emerged from earlier discussion in the URNBIS WG is that there very well might be a need for something like a fragment identifier (or a pointer to a constituent part of an object), and whether it's best to do that with "#" or with something else (at one point the only character we found that would work was "/"). >> I'm not sure what "consistently indicate URLs" means, especially in >> the light of other recent developments [2] > > I was thinking of "http:". > >>> Essentially, the only thing all URIs share is a syntax and >>> that the schema tells how to interpret the remainder of the >>> string. >> >> If that were actually true, the draft would be unnecessary. >> Instead, RFC 3986 effectively says "if these characters appear >> in the syntax, they have the following meaning and must be >> interpreted in the following way". What follows doesn't specify >> complete semantics, but is complete enough to be a big problem >> if one departs from network-based locators to provide >> identifiers (as that term is understood by the library, >> information science, and related communities) for digital and >> non-digital objects of various sorts. > > Is there any problem other than the fragment? Comparing the draft to > 3986, I don't see it make a forceful argument that there are any > others. > >>> This draft is arguing that the *syntax specification* of URNs >>> should be decoupled from the syntax specification of URLs, but >>> it doesn't seem to make any claims that the URI *syntax* is >>> inadequate for URNs. >> >> Yes, it does. I didn't want to spell that out more than I did >> (the above "fragment" issue is just one example) because that >> seemed a job for 2141bis. > > I'm not tracking here. The draft advocates for "this specification > separates the syntax for URNs from the generic syntax for Uniform > Resource Identifiers (URIs) specified in RFC 3986, updating the latter > specification accordingly." But I don't see the argument for it. > I can certainly see the argument for separating the *semantics*, > especially in regard to the fragment (if people have plans for its use > in URNs). > > BTW, are there plans for URNs to use fragment for some other purpose? > Why can't URNs simply not use fragment at all? (Which is pretty much > what they do now, although I suppose a fragment is now defined if the > URN happens to specify a particular representation of a media object.) There has been much discussion of this topic (on and off) in this WG. > Perhaps the point is that this draft is the output of a long > discussion which I haven't seen. But in that case, why does it > include the "critical issues include" section? It really reads as if > it's the beginning of a discussion, not the end of one. Yes. Peter From nobody Fri Apr 11 12:40:33 2014 Return-Path: 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 D41641A0337 for ; Fri, 11 Apr 2014 12:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.428 X-Spam-Level: X-Spam-Status: No, score=0.428 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_21=0.6, 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 6XmkM4SPrZdM for ; Fri, 11 Apr 2014 12:40:26 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E89791A0763 for ; Fri, 11 Apr 2014 12:40:19 -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 ) id 1WYhJ6-0000UH-H9; Fri, 11 Apr 2014 15:40:12 -0400 Date: Fri, 11 Apr 2014 15:40:07 -0400 From: John C Klensin To: Peter Saint-Andre , "Dale R. Worley" Message-ID: <8E1BFC070E8FE70BC48A6EDD@JcK-HP8200.jck.com> In-Reply-To: <5347775D.1010808@stpeter.im> References: <5851702C574A854E3EB322CA@JcK-HP8200.jck.com> <201404091621.s39GL5Xp012482@hobgoblin.ariadne.com> <201404110315.s3B3FsZs018403@hobgoblin.ariadne.com> <5347775D.1010808@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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/GImzov57Azjx-r0LC1-VhultdEM Cc: urn@ietf.org Subject: Re: [urn] Explanation of draft-ietf-urnbis-urns-are-not-uris- and call for review X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:40:31 -0000 For convenience, I'm responding to Peter's note (and leaving things out that I think he has covered more than adequately) although most of the comments are actually to Dale. So consider this a bit of perspective from the guy who held the pen on this particular draft. This note is over-long and parts of it probably belong in -01. Apologies for that, but the questions seem to deserve thorough answers. Help in identifying those parts would be appreciated (and is easier than the usual "send text" request). --On Thursday, April 10, 2014 22:02 -0700 Peter Saint-Andre wrote: > On 4/10/14, 8:15 PM, Dale R. Worley wrote: >>> From: John C Klensin >>=20 >>> 3986 goes a little beyond that in that semantics (or at = least >>> partial semantics) _are_ assigned to certain pieces of >... >> Aye, yes. I've spent quite a bit of time with the ABNF of >> 3986 but never had to deal with the bits that discuss >> semantics. And despite its title of "Uniform Resource >> Identifier (URI): Generic Syntax", there is text about >> semantics. >>=20 >> One semantic part is the process of interpreting relative >> URLs, which forms a constraint on the semantics of any URI >> which can have a "/" after the "scheme:". But URNs are >> prohibited from doing that, so that's not relevant for URNs. >> Or rather, the "urn" scheme is prohibited from doing that and >> it is not relevant for them. =20 > RFC 2141 says: >=20 > RFC 1630 [2] reserves the characters "/", "?", and "#" for > particular > purposes. The URN-WG has not yet debated the applicability > and > precise semantics of those purposes as applied to URNs. > Therefore, > these characters are RESERVED for future developments. > Namespace > developers SHOULD NOT use these characters in unencoded > form, but > rather use the appropriate %-encoding for each character. >=20 > So "prohibited" seems a bit strong. Without debating "prohibited", the key issue that has constrained the WG is that 2141 defined only what, for lack of a better term, I'll call qualifier-free URNs and reserved some bits of syntax for those future developments. We are now in the future. Developments require some qualifiers and syntax for them. And the "Generic URI" (actually, I now believe, "Generalized URL") syntax (both gURL below) and semantics made that impossible. >> Which leads to a subsidiary question, are there going to be >> other URN schemes than "urn"? >=20 > I don't think so. There are actually two different questions in the above, at least IMO. One is whether there are actually types of Generic URIs other than URLs and, at least until now, URNs. That question goes back to discussions in the original and mostly-unlamented URI WG, but there is at least some case to be made for a three-way split among locators (for books, think library shelf locations), categories (think the Dewey, LC, and other systems), and persistent names (e.g., ISBNs and, with the understanding that "persistent" doesn't necessarily require "unambiguous and unique", titles and associated author(s)). I don't want to start a discussion of URCs or other types now, but it seems to me that we may be helping make progress by saying "you can't start with URLs, wave your hands madly, and then start making assertions about fully generic resource-thingies that span the entire relevant space or set of spaces. The other answer is that, if we don't allow the functionality of URNs to expand as anticipated in 2141 and as experience has demonstrated is necessary, we are almost certain to end up with some other form of persistent identifier that does that same job but that isn't under IETF change control and perhaps isn't upward compatible from 2141. The reality of the Internet, as we have seen over and over again, is that, if there is a real and legitimate need, the IETF doesn't get to prevent its being satisfied by saying "no, evil" or "we are in charge". IMO, that would be a drastic and unfortunate solution. In a way, this step is an alternative to a URx which is like a URN but with non-gURL syntax and semantics. I think that, if we were to design a new URN successor today, it would not conform to the gURL syntax and semantics even to the extent that 2141 does -- from what we know from programming languages, etc., 3986 is really a pretty bad syntax model, showing all of the disadvantages of something that started out simple without a lot of insight into future needs and that then growing by accretion and patchwork add-ons, and with confidence that the next required addition would be the last. Just IMO, of course. >> The semantic part that seems problematic is the "fragment". >> The text of section 3.5 is somewhat vague but does make it >> clear that the use of the fragment is determined by the media >> type of the object referenced by the base URI, not by the >> scheme: "Fragment identifier semantics are independent of >> the URI scheme and thus cannot be redefined by scheme >> specifications." That's problematic if URNs want to use the >> fragment in any other way. >>=20 >> But I don't see any other problems. It seems to me that the >> problem is to decouple the *semantics* of URNs from what >> little is said about semantics in 3986. We really, really do >> want to constrain future URNs to stay within the 3986 syntax, >> or whatever the future syntax is for the whole set of UR*s. >=20 > I think that's the question here, or one of them. One thing > that emerged from earlier discussion in the URNBIS WG is that > there very well might be a need for something like a fragment > identifier (or a pointer to a constituent part of an object), > and whether it's best to do that with "#" or with something > else (at one point the only character we found that would work > was "/"). I agree with Peter, but let me give you a different, complementary, answer. "We" have been at this Uniform Resource {Whatever] business for somewhat over two decades and, in some parts of the work, have done a pretty good job of demonstrating how na=C3=AFve we are about all of it (see "patchwork add-ons" above). The library/ museum/ information management/ information sciences communities, who have many hundreds (perhaps even a few thousand) years of experience with these subjects are telling us that mixing and confusing locator-things with persistent identifiers of "objects" is a _really_ bad idea. Juha's example (in Section 2 of the draft unless I screwed it up) of the difference between ISBNs and shelf locations was very helpful to me and might be to others. >... >> Is there any problem other than the fragment? Comparing the >> draft to 3986, I don't see it make a forceful argument that >> there are any others. We don't know. As you suggest below, one could also deal with this by some patching of, and of implied semantic restrictions from, the generic URI spec (3986). Didn't seem on balance like a good idea... see below. >>>> This draft is arguing that the *syntax specification* of >>>> URNs should be decoupled from the syntax specification of >>>> URLs, but it doesn't seem to make any claims that the URI >>>> *syntax* is inadequate for URNs. >>>=20 >>> Yes, it does. I didn't want to spell that out more than I >>> did (the above "fragment" issue is just one example) because >>> that seemed a job for 2141bis. >>=20 >> I'm not tracking here. The draft advocates for "this >> specification separates the syntax for URNs from the generic >> syntax for Uniform Resource Identifiers (URIs) specified in >> RFC 3986, updating the latter specification accordingly." >> But I don't see the argument for it. I can certainly see the >> argument for separating the *semantics*, especially in regard >> to the fragment (if people have plans for its use in URNs). Pragmatic decision. Options similar to that were considered and this one chosen. In particular: (i) If one accepts the argument that the fundamental problem is that URLs and URNs were never part of the same creature and didn't belong together (an argument that is outlined in the draft), then that argument for as little separation as possible just doesn't seem relevant. Indeed, there are arguments for making them look as different as they actually are and the burden ought to be on demonstrating why they should be kept as similar as possible.=20 (ii) I admit to a personal bias that we are still close to the dawn of a growing Internet with a long future ahead of it. If we decide that a particular construction is broken, I believe that we should, insofar as possible, learn from our mistakes, move beyond it, and build a solid foundation for the future. Piling more patches and kludges on top of other kludges and patches just doesn't seem to be the right way to proceed, especially if we can make changes that do not invalid existing uses. (iii) Even if you disagree with the above (and reasonable people may do so), my explorations of alternatives suggested that saying "ok, 3986 doesn't apply to URNs any more" was straightforward and each to get right". Peeling the semantics out of 3986 for URNs only --semantics that are sufficiently subtle that, on first glance, many people don't believe they are there at all-- is a much more difficult task with no greater payoff. If you (or anyone else on this list) believe that work is worth doing, please post a draft that does things that way and make a case for it. As you consider doing so, please consider two things: First, you may write faster than I do, but the current draft took me a couple of weeks after thinking about it for a month or two. A "separate out the semantics" approach is, I believe, more work. The stated intent of the WHATWG effort is to obsolete 3986 entirely (in part because at least some of those involved don't believe in URNs at all and never have), so an effort to fine-tune 3986 would be likely to be embroiled in considerable, time-consuming, controversy. >> BTW, are there plans for URNs to use fragment for some other >> purpose? Why can't URNs simply not use fragment at all? >> (Which is pretty much what they do now, although I suppose a >> fragment is now defined if the URN happens to specify a >> particular representation of a media object.) =20 > There has been much discussion of this topic (on and off) in > this WG. To elaborate very slightly, "fragment", as defined in 3986, is just the wrong model for various types of persistent identifiers, in part because of the types and levels of abstraction involved. While one could change the 3986-defined semantics and overload the syntax a bit, that would not only be confusing but would immediately lead to a need for various types of semi-fragments, meta-fragments, and fragment-like things, each of which would either need its own syntax or some horrible kludge. One can, by the way, make the same argument about queries (with or without fragments). As Peter say, the WG has been down that path and several of the options (or, in retrospect, kludges) have been proposed. >> Perhaps the point is that this draft is the output of a long >> discussion which I haven't seen. But in that case, why does >> it include the "critical issues include" section? It really >> reads as if it's the beginning of a discussion, not the end >> of one. >=20 > Yes. From nobody Mon Apr 14 06:11:38 2014 Return-Path: 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 A64F81A0476; Mon, 14 Apr 2014 06:11: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 MWXyUYlRIfWC; Mon, 14 Apr 2014 06:11:26 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4F11A03EC; Mon, 14 Apr 2014 06:11:26 -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 ) id 1WZgfT-0004rL-Up; Mon, 14 Apr 2014 09:11:23 -0400 Date: Mon, 14 Apr 2014 09:11:18 -0400 From: John C Klensin To: apps-discuss@ietf.org Message-ID: 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/OHPvBRTFVvz-TSathfMCF7J5PQY Cc: urn@ietf.org Subject: [urn] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 13:11:32 -0000 Hi. It seems wise to call the attention of this broader group to something that is going on in URNBIS (and more generally). This message is a personal opinion. It summarizes some discussions in and around that WG but is not an attempt to report on any sort of consensus. RFC 3986 on Generic URI Syntax was an attempt to create a general syntax (and, despite its title, partial semantics) for an extremely general set of resource identifiers, using experience with and developments from URLs as a starting point. The general URI concept was intended to including URLs, URNs, and possible future types. That approach worked for URNs as long as they preserved the very narrow definitions and syntax of RFC 2141 but without taking advantage of any of the provisions for extensibility ("future use") in that specification. In the nearly 20 years since RFC 2141 was published, experience with URNs in various communities has demonstrated the need, with some URN types (NIDs), to be able to specify operations or retrieval of metadata as well as objects and for partial retrieval or other operations on either metadata of the objects themselves. At the same time, there have been forceful discussions in information science, library, museum, and publisher communities about the fundamental differences between locators and names (which much of that community calls "identifiers", excluding locators from that category) and the disadvantages of mixing the two concepts. That might be mostly a theoretical issue except that the URNBIS WG has found it impossible to define the functionality it needs while remaining within the syntax and semantic constraints of RFC 3986 (at least without creating obvious and very ugly kludges). The WG is now considering draft-ietf-urnbis-urns-are-not-uris-00, which proposes to separate URNs from RFC 3986, presumably leaving the latter with URLs and name-like things that are not URNs. It may be worth noting that there is now work in W3C and WHATWG on a new URL definition. The intent of that work includes eventually superceding 3986 (and 3987), at least for URLs, so there are multiple forces working to dismember RFC 3986. However, the URNBIS draft is intended to narrowly focus on the needs of URNs, rather than trying to boil the URI ocean. Those who are interested in this topic should probably take a look at the draft and the discussions during the last week or so on the URN mailing list (http://www.ietf.org/mail-archive/web/urn/). That list has been fairly low-volume, so looking at those messages should not be burdensome. Discussion should also occur on that list unless there are very broad issues that belong here. thanks, john From nobody Mon Apr 14 07:14:17 2014 Return-Path: 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 DCCCB1A02C4; Mon, 14 Apr 2014 07:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 P8sEQA_YRM27; Mon, 14 Apr 2014 07:14:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6301A011A; Mon, 14 Apr 2014 07:14:13 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M51eM-1Wtquz2A3C-00zBmm; Mon, 14 Apr 2014 16:13:48 +0200 Message-ID: <534BED18.9090009@gmx.de> Date: Mon, 14 Apr 2014 16:13:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John C Klensin , apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fdSQ1g5Ld39d+OkVhzTZ8XleYoSPQsbbU6+Z5Hir8SOAd1PSQd7 ZRpCxmPm8VznWl0W8G4AoUN6WmrHE6ojH8iyhx1wbJBEmVAJjOvuiy+KWwigiHxytSZuG9C ZXNYpuyw/BT0lc0fO7jlRvRr4hVhUzH8dGyomw5FuKXDqB773srMFsIszmCEvAeWqfa0F5u hZ3Ma4ipYV8LEtZnG481A== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Udg4V5dLe9VuKEMKqmxvV_k-Rr8 Cc: urn@ietf.org Subject: Re: [urn] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:14:15 -0000 On 2014-04-14 15:11, John C Klensin wrote: > ... One remark: I don't think it's helpful to mix *this* discussion with the WHAT/W3C/IETF discussion about the "URL specification" (which essentially is about error-tolerant parsing) And one question: If you followed this path, would you still be able to use RFC3986-conforming libraries to handle URNs? Best regards, Julian From nobody Mon Apr 14 07:36:05 2014 Return-Path: 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 419AB1A03D7; Mon, 14 Apr 2014 07:36:01 -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 Zutebk6W3x9i; Mon, 14 Apr 2014 07:35:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 585571A047E; Mon, 14 Apr 2014 07:35:56 -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 ) id 1WZhzF-0004yO-P0; Mon, 14 Apr 2014 10:35:53 -0400 Date: Mon, 14 Apr 2014 10:35:48 -0400 From: John C Klensin To: Julian Reschke , apps-discuss@ietf.org Message-ID: <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> In-Reply-To: <534BED18.9090009@gmx.de> References: <534BED18.9090009@gmx.de> 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/e01rb7_dIt-Cu8sbulg29-YvU5o Cc: urn@ietf.org Subject: Re: [urn] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:36:01 -0000 --On Monday, April 14, 2014 16:13 +0200 Julian Reschke wrote: > On 2014-04-14 15:11, John C Klensin wrote: >> ... > > One remark: > > I don't think it's helpful to mix *this* discussion with the > WHAT/W3C/IETF discussion about the "URL specification" (which > essentially is about error-tolerant parsing) Agreed (although I would characterize parts of that discussion differently). The draft is strictly about the URN issues and doesn't do that. I just wanted to provide a little extra context about other things that are going on to head off a conversation about how 3986 must be inviolate ... a discussion to which those other discussions would be relevant. > And one question: > > If you followed this path, would you still be able to use > RFC3986-conforming libraries to handle URNs? Depends on what that means. For a URN NID that is 2141-conformant (a small subset of what 3986 allows) any library that can handle it today will handle it after this change. But what is driving this change is not theory, it is a need for new functionality that just doesn't fit into the locator-oriented 3986 model. That new functionality will require either new syntax or old syntax with different semantics than those specified in 3986. Just as there is no such thing as a 3986-conforming library that can completely and generally handle queries (other than parsing the query away from other components and dispatching it properly), such libraries are not likely to be able to fully process URNs. Another piece of that issue is that comparison of two URNs for equality is, in the general case, a rather different kind of operation than comparison of two URLs; I would not expect a URL-based algorithm (e.g., a RFC3986-conformant library) to be able to get URN comparisons right, at least without NID-specific action routines. I'm being a little vague about this only because the WG hasn't gotten into the syntax to be used for those new functions. I think every effort will be made to keep as much compatibility as possible, at least short of horrible and obvious kludges, but how far 3986 libraries can be pushed will depend on those decisions. Some of this is explored from a slightly different perspective in a few recent notes on the WG mailing list; please have a look. best regards, john From nobody Tue Apr 15 04:29:07 2014 Return-Path: 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 3AF011A079F; Tue, 15 Apr 2014 04:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.337 X-Spam-Level: *** X-Spam-Status: No, score=3.337 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no 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 LVZDE6jBJVpA; Tue, 15 Apr 2014 04:29:02 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id E0A331A02B2; Tue, 15 Apr 2014 04:29:01 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 628DA32E576; Tue, 15 Apr 2014 20:28:57 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 6c4f_0ded_2d3c4f7b_4ba8_40f1_be16_729f44ea9415; Tue, 15 Apr 2014 20:28:56 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 8162FC0374; Tue, 15 Apr 2014 20:28:56 +0900 (JST) Message-ID: <534D17EB.7010700@it.aoyama.ac.jp> Date: Tue, 15 Apr 2014 20:28:43 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John C Klensin , apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/d3cqXHPqoB3_OG_djbG_sMVEs2o Cc: urn@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 11:29:04 -0000 Hello John, others, On 2014/04/14 22:11, John C Klensin wrote: > Hi. > > It seems wise to call the attention of this broader group to > something that is going on in URNBIS (and more generally). > This message is a personal opinion. It summarizes some > discussions in and around that WG but is not an attempt to > report on any sort of consensus. First, it may help to give a direct pointer to an actual draft: http://www.w3.org/DesignIssues/ModelConsequences > RFC 3986 on Generic URI Syntax was an attempt to create a > general syntax (and, despite its title, partial semantics) for > an extremely general set of resource identifiers, using > experience with and developments from URLs as a starting point. > The general URI concept was intended to including URLs, URNs, > and possible future types. For crucial background reading, please see http://www.w3.org/DesignIssues/ModelConsequences. Please don't come back here before you have read it! > That approach worked for URNs as > long as they preserved the very narrow definitions and syntax of > RFC 2141 but without taking advantage of any of the provisions > for extensibility ("future use") in that specification. Please have a look at http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/. This was worked out and written in collaboration with people from the IETF and from the library community. > In the nearly 20 years since RFC 2141 was published, experience > with URNs in various communities has demonstrated the need, with > some URN types (NIDs), to be able to specify operations or > retrieval of metadata as well as objects and for partial > retrieval or other operations on either metadata of the objects > themselves. At the same time, there have been forceful > discussions in information science, library, museum, and > publisher communities about the fundamental differences between > locators and names (which much of that community calls > "identifiers", excluding locators from that category) and the > disadvantages of mixing the two concepts. When it comes to books, and therefore in the library community, such a distinction is very natural. But there are still many use cases where it may make sense to be able to use one or the other kind of identifier in the same field. That's what URIs are all about. To use an (of course incomplete) analogy, it's a bit like the Internet and IP numbers: Before the Internet, there were various networks, and they used various different ways to identify their nodes. The Internet integrated them into a single address space, leading to great network effects. URIs do very much the same, just on a different level. > That might be mostly > a theoretical issue except that the URNBIS WG has found it > impossible to define the functionality it needs while remaining > within the syntax and semantic constraints of RFC 3986 (at least > without creating obvious and very ugly kludges). Your draft in question mentions quite a few requirements, but doesn't discuss at all how they would lead to kludges. Actually reading through the requirements, except for a couple of them, I have difficulties seeing even a shadow of needs for separate syntax. The conclusion of your draft comes out of the blue if it were not for the title. > The WG is now considering > draft-ietf-urnbis-urns-are-not-uris-00, which proposes to > separate URNs from RFC 3986, presumably leaving the latter with > URLs and name-like things that are not URNs. It may be worth > noting that there is now work in W3C and WHATWG on a new URL > definition. The intent of that work includes eventually > superceding 3986 (and 3987), at least for URLs, so there are > multiple forces working to dismember RFC 3986. As Julian already said, the WHATWG work is of a completely different nature and cannot and should not be used as a justification for creating more confusion. > However, the > URNBIS draft is intended to narrowly focus on the needs of URNs, > rather than trying to boil the URI ocean. Focusing narrowly on perceived differences in a specific case isn't the way to move forward. > Those who are interested in this topic should probably take a > look at the draft and the discussions during the last week or so > on the URN mailing list > (http://www.ietf.org/mail-archive/web/urn/). That list has > been fairly low-volume, so looking at those messages should not > be burdensome. Discussion should also occur on that list unless > there are very broad issues that belong here. Trying to split URI syntax is to the Web as e.g. claiming that servers and clients should be assigned different types of IP addresses. As such, this is in and of itself a broad issue that shouldn't be left to a list with limited coverage. Regards, Martin. From nobody Tue Apr 15 07:27:14 2014 Return-Path: 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 A93211A0660; Tue, 15 Apr 2014 06:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 r4r8NnBo9Gnq; Tue, 15 Apr 2014 06:31:41 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id B34001A046C; Tue, 15 Apr 2014 06:31:41 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Wa3SZ-0005kr-ap; Tue, 15 Apr 2014 14:31:35 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Wa3SY-0003tx-2p; Tue, 15 Apr 2014 14:31:35 +0100 Message-ID: <534D31B6.8080307@ninebynine.org> Date: Tue, 15 Apr 2014 14:18:46 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bbI_SW3FxPJyCBZbNnuzKTmd6kY X-Mailman-Approved-At: Tue, 15 Apr 2014 07:27:11 -0700 Cc: urn@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:31:46 -0000 Hi John, I've just taken a look at http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00, and have some comments. I find myself asking what is gained by removing URNs from the scope of what we call URIs? At heart, the argument seems to be that not all locators are good names, and not all names are useful locators. I can't disagree with that. But that's not the same as saying all locators are not good names, or, conversely, all names are not useful locators. An example that comes to mind is the use of DOIs for academic research outputs, and in particular for research data sets (e.g. Datacite [6]). DOIs are conceived as names, and have the appropriate management processes around them applicable to names. But I have observed that in recent times, the preferred form for presenting DOIs to the Web has increasingly been in the form "http://dx.doi.org/..." or similar (see also: [1]). I think this exemplifies something that MAY be used as both identifier and name. One of the goals and strengths of URIs in the web has been that they encompass other systems of identification [2]. A key notion is that for some thing to be "on the web" it should have an assigned URI (or several). URNs regarded as a form of URI allow things that are named by other means, such as ISBN, DOI, etc., to be "on the web". http://tools.ietf.org/html/rfc2141 (appendix A) alludes to this by noting "The URN syntax has been defined so that URNs can be used in places where URLs are expected" (terminology that predates RFC3986) - so there is some recognized value here in being able to use names as URIs. For the Web, blurring the distinction between names and locators enables an incremental deployment of "follow your nose" information discovery, which in turn enables information discovery at a scale far beyond that which can be encompassed by any single managed namespace. Particularly when we consider a web of agents (and things), where we can create names that are also machine actionable without prior bilateral or multilateral agreement (beyond the existing ones that underpin the web itself). Ed Summers (who, among other things, put the LoC subject headings on the web [4]) offers this example [3]: [[ One of the benefits of linking data in this way is the “follow your nose” effect. When a person in their browser or an automated agent runs across the creator in the above triple they are able to dereference the URL and retrieve more information about this creator. For example when a software agent dereferences a URL for NISO. [...] This ability for humans and automated crawlers to follow their noses in this way makes for a powerfully simple data discovery heuristic. The philosophy is quite different from other data discovery methods, such as the typical web2.0 APIs of Flickr, Amazon, YouTube, Facebook, Google, etc., which all differ in their implementation details and require you to digest their API documentation before you can do anything useful. Contrast this with the Web of Data which uses the ubiquitous technologies of URIs and HTTP plus the secret sauce of the RDF triple. ]] At the level of technical implementation, the distinction between names and locators is, if not artificial, not as hard-and-fast as a fixed distinction (such as requiring that URNs are not URIs) would suggest. You point out that a key feature of names is that their meanings persist. Tim Berners-Lee has pointed out [5] that naming is a social and contractual issue, and that persistence is really a quality of service matter rather than something fundamentally apart from location. In summary, the qualities you require of a name *could* be applied to many forms of URI, especially http: URIs, subjected to appropriate policies and management practices. In conclusion, I am not seeing any practical way in which declaring URNs to be not-URIs actually helps to achieve the goals of URNs. I don't see any specific constraints imposed by RFC3986 that are inimical to being names. I'm not seeing any legal aspect of a URN (per http://tools.ietf.org/html/rfc2141) that isn't also allowed in a generic URI. (I think there are other reasons why URNs have not enjoyed widespread uptake, such as unnecessarily restrictive syntax, and in some cases an over-strict interpretation of persistence.) As they stand, having URNs as part of the URI "family" means that we have an assured way of using names that do satisfy the stated properties in a way that their referents may be first-class members of the class of entities that the Web, in all its richness, can describe. ... Nits: the RFC3986 link in the body text at http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00#section-3 is incorrectly linked. #g -- [1] http://www.doi.org/doi_handbook/2_Numbering.html#2.6 [2] http://www.w3.org/DesignIssues/Axioms.html#uri [3] http://inkdroid.org/journal/2008/01/04/following-your-nose-to-the-web-of-data/ [4] http://id.loc.gov/authorities/subjects.html (nee lcsh.info) [5] http://www.w3.org/DesignIssues/NameMyth.html [6] https://www.datacite.org On 14/04/2014 14:11, John C Klensin wrote: > Hi. > > It seems wise to call the attention of this broader group to > something that is going on in URNBIS (and more generally). > This message is a personal opinion. It summarizes some > discussions in and around that WG but is not an attempt to > report on any sort of consensus. > > RFC 3986 on Generic URI Syntax was an attempt to create a > general syntax (and, despite its title, partial semantics) for > an extremely general set of resource identifiers, using > experience with and developments from URLs as a starting point. > The general URI concept was intended to including URLs, URNs, > and possible future types. That approach worked for URNs as > long as they preserved the very narrow definitions and syntax of > RFC 2141 but without taking advantage of any of the provisions > for extensibility ("future use") in that specification. > > In the nearly 20 years since RFC 2141 was published, experience > with URNs in various communities has demonstrated the need, with > some URN types (NIDs), to be able to specify operations or > retrieval of metadata as well as objects and for partial > retrieval or other operations on either metadata of the objects > themselves. At the same time, there have been forceful > discussions in information science, library, museum, and > publisher communities about the fundamental differences between > locators and names (which much of that community calls > "identifiers", excluding locators from that category) and the > disadvantages of mixing the two concepts. That might be mostly > a theoretical issue except that the URNBIS WG has found it > impossible to define the functionality it needs while remaining > within the syntax and semantic constraints of RFC 3986 (at least > without creating obvious and very ugly kludges). > > The WG is now considering > draft-ietf-urnbis-urns-are-not-uris-00, which proposes to > separate URNs from RFC 3986, presumably leaving the latter with > URLs and name-like things that are not URNs. It may be worth > noting that there is now work in W3C and WHATWG on a new URL > definition. The intent of that work includes eventually > superceding 3986 (and 3987), at least for URLs, so there are > multiple forces working to dismember RFC 3986. However, the > URNBIS draft is intended to narrowly focus on the needs of URNs, > rather than trying to boil the URI ocean. > > Those who are interested in this topic should probably take a > look at the draft and the discussions during the last week or so > on the URN mailing list > (http://www.ietf.org/mail-archive/web/urn/). That list has > been fairly low-volume, so looking at those messages should not > be burdensome. Discussion should also occur on that list unless > there are very broad issues that belong here. > > thanks, > john > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Tue Apr 15 07:27:15 2014 Return-Path: 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 26C7F1A046C; Tue, 15 Apr 2014 06:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 bMEpHtrZiwOZ; Tue, 15 Apr 2014 06:31:46 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 384FB1A0658; Tue, 15 Apr 2014 06:31:44 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Wa3Sa-00043R-i6; Tue, 15 Apr 2014 14:31:36 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Wa3Sa-0003u0-19; Tue, 15 Apr 2014 14:31:36 +0100 Message-ID: <534D3410.50607@ninebynine.org> Date: Tue, 15 Apr 2014 14:28:48 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John C Klensin References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> In-Reply-To: <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/p8_bb69l415gc4j7Oh1KOBBRySU X-Mailman-Approved-At: Tue, 15 Apr 2014 07:27:11 -0700 Cc: Julian Reschke , urn@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 13:31:48 -0000 John, Further to my other comments... On 14/04/2014 15:35, John C Klensin wrote: > ... But > what is driving this change is not theory, it is a need for new > functionality that just doesn't fit into the locator-oriented > 3986 model. That new functionality will require either new > syntax or old syntax with different semantics than those > specified in 3986. Maybe this is part of what is missing from your draft. RFC3986 semantics are pretty minimal/malleable, so I'm struggling to understand what you might need to add that violates RFC3986. (The main possible problem I can see would be possible interference with relative reference resolution, but that's not a problem if you avoid using '/' - which urns currently do) > ... Just as there is no such thing as a > 3986-conforming library that can completely and generally handle > queries (other than parsing the query away from other components > and dispatching it properly), such libraries are not likely to > be able to fully process URNs. > > Another piece of that issue is that comparison of two URNs for > equality is, in the general case, a rather different kind of > operation than comparison of two URLs; I would not expect a > URL-based algorithm (e.g., a RFC3986-conformant library) to be > able to get URN comparisons right, at least without NID-specific > action routines. So there's nothing new there. RFC3986 parsing is just a start - URI schemes all tend to have their own specific behaviours. (Which is part of why there is some push-back against arbitrary introduction of new schemes.) I'm not yet seeing the problem of adding NID-specific action routines as long as they don't vilate (minimal) RFC 3986 constraints. #g -- From nobody Tue Apr 15 09:25:49 2014 Return-Path: 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 D1FA51A049C; Tue, 15 Apr 2014 09:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 VjqsngOioaRz; Tue, 15 Apr 2014 09:25:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 06AEE1A06C8; Tue, 15 Apr 2014 09:25:40 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.918.8; Tue, 15 Apr 2014 16:25:36 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0918.000; Tue, 15 Apr 2014 16:25:36 +0000 From: Larry Masinter To: Graham Klyne , John C Klensin Thread-Topic: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPWK8rf7UtytEgU0K4KmCUcXljmZsS2Rqw Date: Tue, 15 Apr 2014 16:25:36 +0000 Message-ID: <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> In-Reply-To: <534D3410.50607@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 0182DBBB05 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(99286001)(54356999)(85852003)(77096999)(50986999)(76176999)(74316001)(99396002)(80022001)(66066001)(83072002)(33646001)(81542001)(4396001)(15975445006)(20776003)(92566001)(74662001)(77982001)(74502001)(46102001)(86362001)(15202345003)(83322001)(80976001)(79102001)(19580395003)(31966008)(76482001)(87936001)(224303002)(2656002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:BC0BF004.8DF2D4C9.865C9E77.6D1F3F0.20227; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/qp3CL8e4CMdFBorJ_I05PogwGUI Cc: "julian.reschke@gmx.de" , "urn@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 16:25:46 -0000 The only thing that makes something a name 'persistsent' is the existance o= f a name resolution service or method which persists. The syntax or namespace is irrelevant. 'persistent' isn't binary, it's jus= t "how long". Everything has a life-time. http://masinter.blogspot.com/2010/03/ozymandias-uri.html The meaning of a URI depends on the agreement of the community of a way of = resolving URIs of that form. http URIs meant using http/0.9, 1.0, 1.1, and now extended to encompass SPD= Y and HTTP/2. =20 Nominally, a URN is a URI that has some organization/resolution authority/r= esolution method, where the authority is believed to be persistent, and ava= ilable in the future to help resolve disputes, should they arise. =20 So when A communicates with B and wants to talk about something they both c= an see (a 'resource') A uses a URI or URN or URL. And B understands what A = meant because they both agree on what the UR* refers to. As the time betwee= n A sending and B reading and interpreting grows, the more important the pe= rsistence of the method by which B will understand what A meant. Is it time to revive http://tools.ietf.org/html/draft-masinter-dated-uri an= d finally get it to RFC? Larry -- http://larry.masinter.net From nobody Tue Apr 15 11:21:04 2014 Return-Path: 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 CF0751A069A; Tue, 15 Apr 2014 11:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.283 X-Spam-Level: ** X-Spam-Status: No, score=2.283 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=no 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 pK0fjsPAjua4; Tue, 15 Apr 2014 11:20:57 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 938DB1A069C; Tue, 15 Apr 2014 11:20:57 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wa7S6-0007Dt-Hf; Tue, 15 Apr 2014 13:47:22 -0400 Date: Tue, 15 Apr 2014 13:47:22 -0400 From: John C Klensin To: Larry Masinter , Graham Klyne Message-ID: <952E89C207E59D25CD5953D6@JCK-EEE10> In-Reply-To: <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 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/Q47JfQBfEeemOgHEOPf8GP_ZNLA Cc: julian.reschke@gmx.de, urn@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 18:21:02 -0000 Hi. Just wanted to tell folks that I'm on a very poor connection (if on at all) for the next couple of days and probably won't be able to give careful answers until Thursday and probably should not try. But one very quick observation in response to part of Larry's note... --On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter wrote: > The only thing that makes something a name 'persistsent' is > the existence of a name resolution service or method which > persists. The syntax or namespace is irrelevant. 'persistent' > isn't binary, it's just "how long". Everything has a = life-time. >=20 > http://masinter.blogspot.com/2010/03/ozymandias-uri.html I think the above largely misses the point and that, in a sense, your blog posting illustrates the point although not in the way you probably intend. "Persistent identifier" entered the IETF vocabulary a long time ago but may not be very look terminology. Some objects -- like stone statues if one doesn't care whether they remain intact and standing-- have very long life expectancies. Others, like people, have shorter ones. But URIs (with or within including URNs) aren't objects, they are object reference that, like most good references, involve some degree of abstraction. Now, "Ozymandias" is a very long-persistent reference. It isn't the object. It is a somewhat ambiguous reference because it can refer to the statue, the poem, your blog posting, and probably several other things, but has a long duration, perhaps one that is long enough to survive the objects it references (just like titles of long-lost books). But, as a reference, it is that persistent because it is not bound to a retrieval mechanism that has its own persistence properties.=20 Whatever its other properties, http://masinter.blogspot.com/2010/03/ozymandias-uri.html is lousy as a persistent identifier. It depends on the availability of "http" (or something called that) as a retrieval mechanism. It depends on there being a DNS, on there being a TLD named "com" an SLD named "blogspot", and both of them having certain properties of which HTTP can take advantage. "Ozymandias", and even the potential URN urn:poems:Shelley/Ozymandias are more persistent because they represent a higher level of abstraction and are not tied to either a location or a retrieval/access method. Use of a hypothetical ISPN (International Standard Poem Identifier) in the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or might not be more persistent: it would be an exact identifier of something and makes equivalence comparison more feasible and less ambiguous, but it is probably tied to a database to actually identify an object and such databases may be more or less available and persistent than access methods and/or the DNS (which is, after all, just another database). Regardless of what one calls them, I suggest that access-method-dependent identifiers (http:..., NineTrackTape:??42.3744=C2=B0?N,?71.1169=C2=B0?W?123456 (where = "?" represents one or more carefully-chosen delimiters that may not have RFC 3986 semantics), ...) are different kinds of creatures than either the objects to which they refer or names of those objects that are not, in the sense of the above, method or location-model dependent. More soon. john From nobody Tue Apr 15 11:33:42 2014 Return-Path: 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 C72201A036F; Tue, 15 Apr 2014 10:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 oP5cJGUIGbcv; Tue, 15 Apr 2014 10:38:15 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DA31F1A02E3; Tue, 15 Apr 2014 10:38:14 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so7237466lbj.31 for ; Tue, 15 Apr 2014 10:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8SpoLdBcRNNdL82kdfywka2u3Evq7kV6wtWBu4unzIo=; b=OU+FuBg5CRmYSs7AwTfH4KuPgopavOC9kS/K2suOsgEqZwIDsfSYR2t7VdbBjkHNi8 oyMlcXpANHskf9XJ0gorgq+YYrugl3HLolcjTwk/ztNjchWdYed2aw+ehufA0yl+cZVi hqdoKjk0myw2A3PwJLUDmJJhw3p6fKdIr+cw/oLhlPqticU420fAs+qJkZSW3fNR8DrN jVI/XQ25HtjlRl3rIv/MTCJ85IWuEA0yj+GHRJH2rLCW2ERoQAcfFESlRIFxUZrtQNEO +cDNRqz0nup7u0JRixAeVpE+O7pwMXAs6gzhkdYFG/ZPokqV5nrgnb+oCZYg3QRHHnU9 Ssjg== MIME-Version: 1.0 X-Received: by 10.112.254.163 with SMTP id aj3mr2037713lbd.20.1397583491328; Tue, 15 Apr 2014 10:38:11 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 15 Apr 2014 10:38:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 20:38:10 +0300 Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/J112mUyG0ancDE37vadhhD8qPx0 X-Mailman-Approved-At: Tue, 15 Apr 2014 11:33:40 -0700 Cc: urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 17:38:20 -0000 I disagree strongly. A URI is any string that fits in the URI slot in existing protocols and will continue to be so regardless of decisions made here. We should redefine the syntax of URIs to be a label followed by a colon followed by any sequence of non-whitespace characters. URI = label ':' anything label = [a-z, 1-9, A-Z] + anything = [not-whitespace]* That should give the URN world more than enough scope. All they need to do is to make sure their URN encoding escapes significant whitespace which is probably an essential success criteria in any case. The syntax I give is pretty much the definition of a URI used in pretty much all code that attempts to turn text into hyperlinks that is not limited to http and https. On Mon, Apr 14, 2014 at 4:11 PM, John C Klensin wrote: > Hi. > > It seems wise to call the attention of this broader group to > something that is going on in URNBIS (and more generally). > This message is a personal opinion. It summarizes some > discussions in and around that WG but is not an attempt to > report on any sort of consensus. > > RFC 3986 on Generic URI Syntax was an attempt to create a > general syntax (and, despite its title, partial semantics) for > an extremely general set of resource identifiers, using > experience with and developments from URLs as a starting point. > The general URI concept was intended to including URLs, URNs, > and possible future types. That approach worked for URNs as > long as they preserved the very narrow definitions and syntax of > RFC 2141 but without taking advantage of any of the provisions > for extensibility ("future use") in that specification. > > In the nearly 20 years since RFC 2141 was published, experience > with URNs in various communities has demonstrated the need, with > some URN types (NIDs), to be able to specify operations or > retrieval of metadata as well as objects and for partial > retrieval or other operations on either metadata of the objects > themselves. At the same time, there have been forceful > discussions in information science, library, museum, and > publisher communities about the fundamental differences between > locators and names (which much of that community calls > "identifiers", excluding locators from that category) and the > disadvantages of mixing the two concepts. That might be mostly > a theoretical issue except that the URNBIS WG has found it > impossible to define the functionality it needs while remaining > within the syntax and semantic constraints of RFC 3986 (at least > without creating obvious and very ugly kludges). > > The WG is now considering > draft-ietf-urnbis-urns-are-not-uris-00, which proposes to > separate URNs from RFC 3986, presumably leaving the latter with > URLs and name-like things that are not URNs. It may be worth > noting that there is now work in W3C and WHATWG on a new URL > definition. The intent of that work includes eventually > superceding 3986 (and 3987), at least for URLs, so there are > multiple forces working to dismember RFC 3986. However, the > URNBIS draft is intended to narrowly focus on the needs of URNs, > rather than trying to boil the URI ocean. > > Those who are interested in this topic should probably take a > look at the draft and the discussions during the last week or so > on the URN mailing list > (http://www.ietf.org/mail-archive/web/urn/). That list has > been fairly low-volume, so looking at those messages should not > be burdensome. Discussion should also occur on that list unless > there are very broad issues that belong here. > > thanks, > john > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Website: http://hallambaker.com/ From nobody Tue Apr 15 11:41:02 2014 Return-Path: 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 D9BDE1A0322; Tue, 15 Apr 2014 11:41:00 -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 L_xSJgno9UBE; Tue, 15 Apr 2014 11:40:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8224E1A0503; Tue, 15 Apr 2014 11:40:56 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wa8Hm-0007KV-Ct; Tue, 15 Apr 2014 14:40:46 -0400 Date: Tue, 15 Apr 2014 14:40:46 -0400 From: John C Klensin To: Phillip Hallam-Baker Message-ID: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> In-Reply-To: References: 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: ::1 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/DdhnDyXCwLeJlm2EPKiYyU1l1fA Cc: urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 18:41:01 -0000 Actually, we don't disagree on anything but language and tactics. Specifically, the underlying problem is that there are semantic (and maybe syntax) constraints in RFC 3986 that make it, and its definition of "URI" unsuitable for some plausible and important class of identifiers (especially those, or a subset of them, whose "methods" are not tied to a particular retrieval or processing protocol (note that "SIP:" and "Mailto" are really no different from "http" in that regard). One can avoid recognizing that it is problem and try to force all identifiers into the Procrustean bed defined by 3986. That isn't working well. Its ultimate result is almost certain to be the development of object identifier standards away from the IETF and W3C and the need to adapt to that bed. Indeed, that has already occurred; note the Handle System and the closely-related DOIs. Or one can recognize the problem and try to deal with it. It seems to me that there are several ways that problem can be addressed, in more or less decreasing order of drasticness. (1) Discard RFC 3986 entirely, adopt the syntax convention you suggest (URI = label ':' anything), and leave each method definition to its own devices. (2) Revise and replace 3986 in a way that removes all of the semantic definitions and constraints, leaving only the generic syntax. I think that the result would be workable but, unlike the "every method defines its own syntax within 'anything'" model above, I can't prove it. And, having explored that option, it turns out that removing the subtle semantic constraints from 3986 is not easy. (See the thread in the URN mailing list for more about this.) (3) Redefine 3986 as applying only to URLs. If you have a URI type (i.e., a method) and define it as a URL, you get to incorporate 3986 by reference and use its syntax and semantics without repeating them. If you don't make that declaration, you are on your own, much as in (1) above. (4) Come up with a new typology of URIs and then remove one or more of types from the scope of 3986. Of course, as Larry's insistence that there is really no such things as a persistent identifier shows, coming up with such a typology and reaching agreement about it is not straightforward. (5) Remove URNs from the scope of 3986, leaving everything that doesn't use the pseudo-method "urn:" within the scope of 3986 until and unless they demonstrate why they should be removed too. Approach (5) is the one suggested in the draft, not because I think it would be optimal in the best of all possible worlds, but because it appears to be something that the URNBIS WG can do and that would allow it to move forward. FWIW, the practical difference among some of those approaches is ultimately the old issue about the difference between inclusion-based and exclusion-based models. RFC 3986 effectively says "all identifiers are URIs and should (or must) conform to this model. As soon as we get to "except those that don't", one can either identify those that don't or those that do. Of course, if we were to shift to the much more generic model of (1), number of things that would need to be excluded would presumably be far fewer. best, john --On Tuesday, 15 April, 2014 20:38 +0300 Phillip Hallam-Baker wrote: > I disagree strongly. > > A URI is any string that fits in the URI slot in existing > protocols and will continue to be so regardless of decisions > made here. > > We should redefine the syntax of URIs to be a label followed > by a colon followed by any sequence of non-whitespace > characters. > > URI = label ':' anything > > label = [a-z, 1-9, A-Z] + > anything = [not-whitespace]* > > That should give the URN world more than enough scope. All > they need to do is to make sure their URN encoding escapes > significant whitespace which is probably an essential success > criteria in any case. > > The syntax I give is pretty much the definition of a URI used > in pretty much all code that attempts to turn text into > hyperlinks that is not limited to http and https. > > On Mon, Apr 14, 2014 at 4:11 PM, John C Klensin > wrote: >> Hi. >> >> It seems wise to call the attention of this broader group to >> something that is going on in URNBIS (and more generally). >> This message is a personal opinion. It summarizes some >> discussions in and around that WG but is not an attempt to >> report on any sort of consensus. >> >> RFC 3986 on Generic URI Syntax was an attempt to create a >> general syntax (and, despite its title, partial semantics) for >> an extremely general set of resource identifiers, using From nobody Thu Apr 17 07:05:28 2014 Return-Path: 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 9CAE21A02AF; Wed, 16 Apr 2014 11:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 s9jxmfkxme3d; Wed, 16 Apr 2014 11:58:36 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id E723D1A02C2; Wed, 16 Apr 2014 11:58:30 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id n15so8526025lbi.13 for ; Wed, 16 Apr 2014 11:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IKWc6KTMmk2Zld9RPrjkzenS8PmjgvFrx8G8AxH499w=; b=AR0jOxwXm+gA5WBZVS+cmzr0p2CJG62PQipGkeJs2Vpp7/aeynR9bP6jXiKaiQzUAT L/dlB2Pj9HGSLV42kC/lR4J9ZSIF9cLDLtx9kLt4jvocyjweribwsu5szNZ+T44NzBtP debUC+t83No2m2cCFvXLAqk1fBBfhT51BwcjR/gA7TN7dt3VLvWOiIj07Q+RAiv8+699 fkd9NdNKP6vm8b0YCVOd6D8Q7i6BAbyDGXWatq7pdjei/oJnoBtY6xMM+KQ+2Llb6TmO NZuN6Nx6bFLC41pHqXm2ZSYEz+KAIuK6L4ZyeIqnbNYO74HfzDzre42qGYPMi/VOAVzn i3sw== MIME-Version: 1.0 X-Received: by 10.152.205.98 with SMTP id lf2mr2086064lac.60.1397674706749; Wed, 16 Apr 2014 11:58:26 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Wed, 16 Apr 2014 11:58:26 -0700 (PDT) In-Reply-To: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> Date: Wed, 16 Apr 2014 21:58:26 +0300 Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/AsaPQ6zhOSKlHaDKDNJ7_DD7sCg X-Mailman-Approved-At: Thu, 17 Apr 2014 07:05:27 -0700 Cc: urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 18:58:41 -0000 On Tue, Apr 15, 2014 at 9:40 PM, John C Klensin wrote: > Actually, we don't disagree on anything but language and tactics. I understood that. It is a specification so language is rather important. I don't like the suggestion that the URI slot in the existing protocols no longer includes URNs. But I am more than happy to toss virtually the entire URI syntax out. I am also rather suspicious of the idea that the difference between URNs and URLs is that one is a name and the other is an index. Both are both. The real difference is that a URL must contains a DNS name and a URN probably does not. I don't believe in the 'persistent identifier' notion except for the limited case involving SHA-256 and the like > Specifically, the underlying problem is that there are semantic > (and maybe syntax) constraints in RFC 3986 that make it, and its > definition of "URI" unsuitable for some plausible and important > class of identifiers (especially those, or a subset of them, > whose "methods" are not tied to a particular retrieval or > processing protocol (note that "SIP:" and "Mailto" are really no > different from "http" in that regard). Then replace RFC 3986 with one that says 'this is the URI syntax and the semantics are defined by the scheme'. I agree that tying http: to the HTTP protocol seems rather antiquated now. Unfortunately NAPTR is also unhelpful. > One can avoid recognizing that it is problem and try to force > all identifiers into the Procrustean bed defined by 3986. That > isn't working well. Its ultimate result is almost certain to be > the development of object identifier standards away from the > IETF and W3C and the need to adapt to that bed. Indeed, that > has already occurred; note the Handle System and the > closely-related DOIs. > > Or one can recognize the problem and try to deal with it. It > seems to me that there are several ways that problem can be > addressed, in more or less decreasing order of drasticness. > > (1) Discard RFC 3986 entirely, adopt the syntax convention you > suggest (URI = label ':' anything), and leave each method > definition to its own devices. That would be my choice if it meant less argument. > (2) Revise and replace 3986 in a way that removes all of the > semantic definitions and constraints, leaving only the generic > syntax. I think that the result would be workable but, unlike > the "every method defines its own syntax within 'anything'" > model above, I can't prove it. And, having explored that > option, it turns out that removing the subtle semantic > constraints from 3986 is not easy. (See the thread in the URN > mailing list for more about this.) I would be fine with URLs being a syntactic subset of URIs. Possibly we could define the method:/// and method:@ patterns as the 'URL patterns and declare all else to be a URN. > (3) Redefine 3986 as applying only to URLs. If you have a URI > type (i.e., a method) and define it as a URL, you get to > incorporate 3986 by reference and use its syntax and semantics > without repeating them. If you don't make that declaration, you > are on your own, much as in (1) above. OK > (4) Come up with a new typology of URIs and then remove one or > more of types from the scope of 3986. Of course, as Larry's > insistence that there is really no such things as a persistent > identifier shows, coming up with such a typology and reaching > agreement about it is not straightforward. I don't think that the persistent identifier problem is insoluble. I just haven't seen a convincing solution yet. And in the real world any persistent identifier scheme has to cope with copyright and kiddie porn takedown issues. I have an interesting attack on the BitCoin blockchain. The attacker encrypts some kiddie porn and dumps it into the blockchain. Then a little while later they drop the key into the blockchain. Then when the chain is final they call the cops, anyone with a bitcoin wallet is now carrying kiddie porn. Hows that for a DoS attack? > (5) Remove URNs from the scope of 3986, leaving everything that > doesn't use the pseudo-method "urn:" within the scope of 3986 > until and unless they demonstrate why they should be removed too. > > Approach (5) is the one suggested in the draft, not because I > think it would be optimal in the best of all possible worlds, > but because it appears to be something that the URNBIS WG can do > and that would allow it to move forward. Removing URNs from scope is not quite the same thing as saying that they are not URIs. > FWIW, the practical difference among some of those approaches is > ultimately the old issue about the difference between > inclusion-based and exclusion-based models. RFC 3986 > effectively says "all identifiers are URIs and should (or must) > conform to this model. As soon as we get to "except those that > don't", one can either identify those that don't or those that > do. Of course, if we were to shift to the much more generic > model of (1), number of things that would need to be excluded > would presumably be far fewer. We split specs apart all the time. Just present this as a piecemeal rollout of URI/2.0 doing the URN space now and the locators 'at a later time'. I don't want to deal with the locators at the moment because the only way to fix locators properly is to make use of DNS in ways that people tell me are currently impossible due to the infrastructure constraints right up to the point when I suggest changes when they tell me that the protocol is perfect[1]. And of course for those of us who built an Internet scale PKI twenty years ago that is working pretty well all things considered[2], the whole point of deploying DNSSEC was always to enable security policy information to be deployed through the DNS. So I would not want to open up discussion of URL/2.0 right now. [1] Fortunately fixing the last mile issue of DNSSEC forces us to fix the client-resolver loop and so does Edward Snowden. [2] Folk who disagree need to sign the DNS root with a key longer than RSA1024 before throwing stones at others. -- Website: http://hallambaker.com/ From nobody Thu Apr 17 07:40:25 2014 Return-Path: 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 090E11A018D; Thu, 17 Apr 2014 07:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 i2MxTH0oEl3q; Thu, 17 Apr 2014 07:40:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 74FFE1A0088; Thu, 17 Apr 2014 07:40:18 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MAy40-1WiSSs3OBo-009zNY; Thu, 17 Apr 2014 16:40:10 +0200 Message-ID: <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 16:39:56 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , John C Klensin References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hnMpq0k9iEQXWxdEZMBN9CvKbaA/vyBax4m4LfRpotEuHC03sQy itM7j6zJAa4f47U1cW6erI3iW2S5WK7hAuEOKZa/SzG0dZe215WIzNcPi/RPAj0hBgP96nh WuHCoNLl3MdvWUAjdW9AKs0L3EwK/gzHAuYd0ubwkWZlW2aoyvCbsAN0/f/mvj7rJbopa2s K39zE1bVFAH9L08xvyZvw== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Z1k_IE7xGD3FNNwXttXMGhiFILk Cc: urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 14:40:23 -0000 On 2014-04-16 20:58, Phillip Hallam-Baker wrote: > On Tue, Apr 15, 2014 at 9:40 PM, John C Klensin wrote: >> Actually, we don't disagree on anything but language and tactics. > > I understood that. It is a specification so language is rather important. > > I don't like the suggestion that the URI slot in the existing > protocols no longer includes URNs. But I am more than happy to toss > virtually the entire URI syntax out. > > I am also rather suspicious of the idea that the difference between > URNs and URLs is that one is a name and the other is an index. Both > are both. > > The real difference is that a URL must contains a DNS name and a URN > probably does not. > ... Not true. It doesn't need to be a DNS name. > ... Best regards, Julian From nobody Thu Apr 17 08:48:14 2014 Return-Path: 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 7DC241A01B9; Thu, 17 Apr 2014 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 tjPpJgWkfJ_t; Thu, 17 Apr 2014 08:42:21 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 577F31A01CD; Thu, 17 Apr 2014 08:42:13 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id D0C56318064; Thu, 17 Apr 2014 08:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=BkDYJ8xnQ2pAbFEJxuy9 szH5/aI=; b=FsmGL+Sn2F/aQerToUxqrrhXJycRaEQc7eQWUCU9vdeWpazX3YuQ VOYix4Vp4+ixIvyd0wtJD9ES87Ec84H+zof9iu3t3ZnDAxiXAnAWSzz2F74Wk5jx aVE3l+Ojin3d0Q1ABmhNpXdhdi7j3561DReeXyXJA/ukaoOgenVVNrM= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 54FA2318059; Thu, 17 Apr 2014 08:42:09 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so592372wgh.23 for ; Thu, 17 Apr 2014 08:42:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr12886369wib.42.1397749327929; Thu, 17 Apr 2014 08:42:07 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 08:42:07 -0700 (PDT) In-Reply-To: <534FE7BC.4070002@gmx.de> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 10:42:07 -0500 Message-ID: From: Nico Williams To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/sxZZj58q6DeTXa9rYy9ctMd4fi4 X-Mailman-Approved-At: Thu, 17 Apr 2014 08:48:11 -0700 Cc: urn@ietf.org, Phillip Hallam-Baker , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:42:25 -0000 On Thu, Apr 17, 2014 at 9:39 AM, Julian Reschke wrote: > On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >> The real difference is that a URL must contains a DNS name and a URN >> probably does not. >> ... > > Not true. It doesn't need to be a DNS name. The difference is blurry, but I like to think of it as: a URN is just a name and there needn't even be a mechanism to resolve one to a resource -- heck, there needn't even be a resource. Whereas a URL is a name that indicates how to resolve it in order to locate a resource; the location part might not -need not- be stable. Nico -- From nobody Thu Apr 17 09:05:12 2014 Return-Path: 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 EEB471A0220; Thu, 17 Apr 2014 09:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 nS36HPD3lWxm; Thu, 17 Apr 2014 09:05:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 762C41A021A; Thu, 17 Apr 2014 09:05:06 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MhNk6-1WMyvB3Pvu-00MYch; Thu, 17 Apr 2014 18:04:59 +0200 Message-ID: <534FFB98.5040607@gmx.de> Date: Thu, 17 Apr 2014 18:04:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Nico Williams References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:37SK7/gynTTWpRrJZ8iczqp7/37gZXVaQWU8ehIqDwqT2PPjhx+ K9cK/mO0e7GD42CXIP979+N+YrTPotMSeYwtvVNoOeBsaZb1HBI+WZYWy6Z7nm8V6i5O5TS /Q1tuzNkwW+C4kF15EZcaDmdrpW74Po8wdgAeu7nP8yLTu47KePTDbHYWy9rsWYpcLvq5xB HOXhc3xNJ81Djxq61z2+A== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/6ooNheJ9AIgD1eKbP2wlOGrQyBs Cc: urn@ietf.org, Phillip Hallam-Baker , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:05:11 -0000 On 2014-04-17 17:42, Nico Williams wrote: > On Thu, Apr 17, 2014 at 9:39 AM, Julian Reschke wrote: >> On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >>> The real difference is that a URL must contains a DNS name and a URN >>> probably does not. >>> ... >> >> Not true. It doesn't need to be a DNS name. > > The difference is blurry, but I like to think of it as: a URN is just > a name and there needn't even be a mechanism to resolve one to a > resource -- heck, there needn't even be a resource. Whereas a URL is If "it" has a URN then "it" is a resource. By definition. > a name that indicates how to resolve it in order to locate a resource; > the location part might not -need not- be stable. But it's good as it is. A URL is a locator which might be a stable name as well. A URN is a name that may act as a locator later on. Best regards, Julian From nobody Thu Apr 17 12:48:37 2014 Return-Path: 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 D29621A0054 for ; Thu, 17 Apr 2014 12:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 A5dFLwHKJpfp for ; Thu, 17 Apr 2014 12:48:34 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4161A0011 for ; Thu, 17 Apr 2014 12:48:33 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta06.westchester.pa.mail.comcast.net with comcast id r1sf1n0070vyq2s567oWll; Thu, 17 Apr 2014 19:48:30 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta05.westchester.pa.mail.comcast.net with comcast id r7oV1n00R1KKtkw3R7oVmQ; Thu, 17 Apr 2014 19:48:30 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3HJmTLr005064 for ; Thu, 17 Apr 2014 15:48:29 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3HJmTVr005063; Thu, 17 Apr 2014 15:48:29 -0400 Date: Thu, 17 Apr 2014 15:48:29 -0400 Message-Id: <201404171948.s3HJmTVr005063@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org In-reply-to: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> (john-ietf@jck.com) References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397764110; bh=i3KXQsVjdeXCbtTz6XpETSmVbXBiQ2ajobikJui7i4w=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=TXAK10qMOI/8jUxSjvZVX4qePuf6YFyzrYuN7XtMixxU7T0bFPxcpJa8azOaCk87p Yjr/dW/j2JnB6UBQjEAxVtKLe+laLA/nzJ0pkCfd6MF0LEIQisTPQUJ72RyVSyT2Bc UN2srJ91mSmT+DixAfI3g/nhBni9W4RoOx42VBIb4NYn2nNkAWxUj91QcYM9aFWoHn mfEs1rmqqsArwpC5awar6pwDP+zHf+Qrmdmtj3nbUj1Bnz4ZPAsGoJDnErvDIKPcym /XxXKIYMtcqvRpGq0GfHjDRbWExc+15nS5af7ndzdE4N9i/OVTuoLenhtmMPYeEypn tClaHsAtuIACA== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UFuZigLvCXD1WC37geXArv6RqzE Subject: Re: [urn] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:48:36 -0000 I think some of the questions that we're dealing with are fairly deep and they're not being addressed well. What is really under debate is overhauling URNs. That is, producing a a new syntax (and possibly semantics) of URNs that is not necessarily upward-compatible with RFC 2141. But what I'm not seeing is a discussion of the factors that would drive such a decision: - Why is the current framework inadequate? - How will use of URNs of the new type coexist with URNs of the old type? In particular, I've seen repeated statements that the current framework is inadequate for the future development of URNs, but I haven't seen even a summary of the discussion, nor any pointer to the record of the discussion discussion itself, nor how to participate in that discussion. Dale From nobody Thu Apr 17 12:49:25 2014 Return-Path: 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 0325E1A0054 for ; Thu, 17 Apr 2014 12:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 h4cQ8psB2iAq for ; Thu, 17 Apr 2014 12:49:19 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8377B1A0011 for ; Thu, 17 Apr 2014 12:49:19 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id qzvW1n0030vyq2s537pFrl; Thu, 17 Apr 2014 19:49:15 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta05.westchester.pa.mail.comcast.net with comcast id r7pF1n00D1KKtkw3R7pFuX; Thu, 17 Apr 2014 19:49:15 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3HJnFbg005147 for ; Thu, 17 Apr 2014 15:49:15 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3HJnE6R005146; Thu, 17 Apr 2014 15:49:14 -0400 Date: Thu, 17 Apr 2014 15:49:14 -0400 Message-Id: <201404171949.s3HJnE6R005146@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org In-reply-to: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> (john-ietf@jck.com) References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397764155; bh=Vkz7aynBuNqzW6q+EpnuEoRDs/zmunU2QqLy9IGeCos=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=C5ED7YjWtm1E5i7Eq2rl9jvvtmShN8K4+avbjyJAu7isBTzG50J1HDNYwL5QpUxOF 7Z+JYza1AspUGGlAy8rVOqIWzWKIhufw4E/TFKzRzrmdK5dEMJ/b73rrn2/1RpAxbV qzqrC+EGxqoeVzoHxhRW2vPlkadJj8ofgEhAKiyWxUmFuO9peMv1AUOBOLKcdxga/O btZxNtU2ptU/HTX4NTmfJWfqpl3j4mcPrkwxRytGLwZySBHdZeT+YgxM+nlTF6gmuG 4ZN2k6Pr+NrdCavBy35PbSzehEOW9rM9fUGAHqFods8jS3uujtRTQ2CWUhyOxUH/3+ Mlkxr9BYPi9Vg== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/mI-S1gXGFEj4ukZKKPmRHR6UJs8 Subject: Re: [urn] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:49:23 -0000 One the other hand, if we are considering URNs as they are now constituted, then I can give some specific comments: draft-ietf-urnbis-urns-are-not-uris-00 is written in an unusual format: it gives a good list of issues, gives a sketch of discussion and reasoning, and ends by stating a very specific solution. So I was rather confused as to exactly how I-D was to be interpreted -- Is it the basis from which a discussion will be made? (If so, why does it specify the conclusion?) Is it the final document? (If so, why does it describe the issues, but not give the reasoning which leads to the stated solution?) After seeing the ensuing discussion on the mailing list, it's clearer what the purpose of the I-D is, and I'd like to present my opinions again in a better-organized way. First, let me enumerate some secondary issues that would clutter the discussion of the main points: I conceive that URLs and URNs are two subsets of URIs. In principle, they may overlap, and also there are URIs that are neither URLs or URNs (e.g., the "tag" scheme). In practice, I see neither of these facts as being significant, as there are no practical consequences of either fact, beyond that specific schemes may be defined to be URLs and/or URNs. (This is the "Contempory View" of http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/, but I arrived at it before reading that document.) Currently, all URNs are in the scheme "urn". But it has never been specified that all URNs must be of the "urn" scheme. The lack of clarity on this point may lead to people making the assumption that because a URI is a URN, it must be of the "urn" scheme. I can see the philosophical distinction between URNs and URLs, but I don't see that that necessitates that they are handled differently at the protocol level. This is despite that I'm a mathematician by training and have a strong sense that the proper structuring of systems is aided by having clearly organized concepts. In particular, both URLs and URNs can be used for the operation of "designating a resource". Generic "designating a resource" can be useful in at least two situations: (1) when the use of the URI is opaque, and much of the processing in question can be done without consideration of what the resource is in particular, and (2) when the processor can resolve the URN into a concrete representation of the resource. In the latter case, the URN allows the processor to access an object in the much same way as a URL, and URN acts as a subclass of URL. As RFC 2141 says, "The URN syntax has been defined so that URNs can be used in places where URLs are expected." If we are seriously concerned with persistence of objects, we should standardize on the most-proven technology available, viz., translating the object into Sumerian, transcribing it into cuneiform on a clay tablet, firing the tablet, and then burying it in suitable dry soil. In particular, I haven't seen any reference to "Ozymandias" being made persistent in this way. However, that should be put into a different I-D, as it is out of scope for this one. ----- Getting back to the main issues: Looking at RFC 3986, I see that despite its title "Uniform Resource Identifier (URI): Generic Syntax", it does contain certain specifications of the generic semantics of URIs, and these specifications have some consequences for defining URNs. (The fact that these consequences exist is essentially admitting that the concerns of http://www.w3.org/DesignIssues/ModelConsequences must be met. Again, I had come to these conclusions before reading that document.) 1) Paths: the use of '/', '.', '..', and how relative URIs are resolved into absolute URIs These rules describe how relative URIs are to be interpreted, and in doing so, specify that a URI is divided into "segments" by '/', and how a new absolute URI is assembled from the segments of a base URI and the relative URI. As a consequence of this process, the use of '.' and '..' as segments must be avoided in absolute URIs. I don't see this as significantly restrictive of URNs -- If a URN scheme wants to take advantage of the relative URI mechanism, it can do so by conforming to the generic syntax, and if it does not want to use the relative URI mechanism, it can avoid using '/'. 2) Query: the use of '?' A URI containing a query part is related to the URI created by deleting the query part in some manner, but the manner seems to be entirely left for definition by the scheme definition: The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). That appears to me to be a non-constraint in any practical sense. 3) Fragment: the use of '#' The use of the fragment part has much more semantic content: The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications. Individual media types may define their own restrictions on or structures within the fragment identifier syntax for specifying different types of subsets, views, or external references that are identifiable as secondary resources by that media type. If the primary resource has multiple representations, as is often the case for resources whose representation is selected based on attributes of the retrieval request (a.k.a., content negotiation), then whatever is identified by the fragment should be consistent across all of those representations. Each representation should either define the fragment so that it corresponds to the same secondary resource, regardless of how it is represented, or should leave the fragment undefined (i.e., not found). In short, the full process of dereferencing a URI must be factorable into three phases: - dereference the URI with the fragment part removed to provide a set of representations - select one of the representations - from or based on the selected representation, derive the fragment part and while the first phase is scheme-dependent, the third phase may only depend on the chosen representation and its media type. The degree of constraint this places on URNs is not clear to me. If one wishes a URN-without-fragment to designate a resource whose representation is a media type whose fragment-access is already defined, the URN is constrained. (I know that fragment-access is defined for HTML documents; is it defined for any other media type?) If one is free to have one's URN-without-fragment designate a new media type, the semantics of the fragment part is nearly unlimited, as long as the base resource representation contains all the information needed for fragment resolution, as specified by its media type. 4) Syntactic compatibility A question which seems to me to be getting insufficient attention is that of semantic compatibility of all URIs, that is, that all current and future URIs should conform to the currently set syntax for URIs. This is required for upward-compatibility with current systems that validate URIs for syntactic conformity. In regard to this, it seems to me to be undesirable to decouple the syntax specification of URNs (or rather, the "urn" scheme) from RFC 3896 -- because we have a de-facto requirement that URNs remain within 3896, formally disconnecting the two will lose formal specification of this requirement. However, there is a caveat (vide Phillip Hallam-Baker's remarks): [That] may not be backward-compatible with the specification, but it is backward-compatible with reality. -- Francois Audet There is a very real question of the degree to which any existing system validates data that are considered to be "generic URIs". If systems in practice don't validate URIs beyond "having a scheme", then we are free to update the URI syntax (and consequently the URN syntax) very broadly. Similarly, we have to worry about changes to the syntax of the "urn" scheme. RFC 2141 states that '/', '?', and '#' are "reserved for particular purposes". But in fact, they don't appear in the BNF, so the "urn" definition can't be expanded to include them without risking breaking any software that validates URNs against the BNF of 2141. Again, the degree to which this a practical problem is not clear. 5) Equality testing One feature of RFC 3986 that may have turned out to be a bad idea is that testing for equality of two URIs cannot be done without specific information regarding their scheme. 3986 does define that certain URIs (that is, certain character sequences that conform to the BNF) must be "the same" (and thus have equivalent functionality for all purposes). But each scheme is permitted to define equality in a coarser sense, that is, to combine those groups of equal URIs into larger groups. This makes it impossible for a processor to index something based on URIs that does not have specific knowledge of the URI schemes involved, but still handles all equal URIs in the same way. However, it's not clear how much that matters in practice -- most URI schemes have de-facto canonical forms. It's also not clear that this situation can be avoided if we want to regularly incorporate pre-existing identifier systems as URI schemes, as other identifier systems frequently have their own rules for identifier equality. Dale From nobody Thu Apr 17 13:31:35 2014 Return-Path: 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 AF65B1A011C; Thu, 17 Apr 2014 09:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 yZBQBg_JugX7; Thu, 17 Apr 2014 09:13:07 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF511A00FB; Thu, 17 Apr 2014 09:13:07 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id 10so558307lbg.35 for ; Thu, 17 Apr 2014 09:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4nYW9ORLqcbHvDk/4P/Up3I6eKl9CmaY0DjvPJ/3cgs=; b=d1/gvKAdkascuCGNpIKhay3U79/ZvIoZ+f4zoUrJn6k+Nin6+YVLjrTWGaaiKTfxLe 35bBGaSvw4chv1cm4ev3MDTI651x5Wq8JylPYec2efJilvVeJ746PkMhs/fESA4VK7I2 Qx5VqCUmWQdMy1gAFSPhJUDiH24RcO3NSTHH2BKtOhPbdOHV65BA/Vus4CSyo1UjgoB+ uq+UT4RgB7kWufMZ1rfMGMQ1NWe37X3mZL3bu9BqVu9m9FycOtog6XMEjI0/Wzn98XRX hARFHwxkkwFzNVdAS/3wm6wx1S2ebW7dnl96gjyu54dIwVjqpqUsAVKI+kcCVW/9zGpW 5Jxg== MIME-Version: 1.0 X-Received: by 10.152.4.41 with SMTP id h9mr2142103lah.43.1397751183071; Thu, 17 Apr 2014 09:13:03 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Thu, 17 Apr 2014 09:13:02 -0700 (PDT) In-Reply-To: <534FE7BC.4070002@gmx.de> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 19:13:02 +0300 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/WYnWi3684WAr01_BITKGpg_cuU0 X-Mailman-Approved-At: Thu, 17 Apr 2014 13:31:32 -0700 Cc: urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:13:12 -0000 On Thu, Apr 17, 2014 at 5:39 PM, Julian Reschke wrote: > On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >> >> On Tue, Apr 15, 2014 at 9:40 PM, John C Klensin wrote: >>> >>> Actually, we don't disagree on anything but language and tactics. >> >> >> I understood that. It is a specification so language is rather important. >> >> I don't like the suggestion that the URI slot in the existing >> protocols no longer includes URNs. But I am more than happy to toss >> virtually the entire URI syntax out. >> >> I am also rather suspicious of the idea that the difference between >> URNs and URLs is that one is a name and the other is an index. Both >> are both. >> >> The real difference is that a URL must contains a DNS name and a URN >> probably does not. >> ... > > > Not true. It doesn't need to be a DNS name. Why bother with anything else? Its all legacy now or going to be soon enough. X.500 has never been a viable directory. Telephone numbers are the only other widespread locator. We have some names that don't use the URN prefix and we have some stuff like about: and data: But if we take a look at this as a semiotics problem. We have Noh's three classes: Firstness: The identifier is the thing identified (e.g. data) Secondness: The identifier is an index of the identified (http, mailto: etc.) Thirdness: The relationship between the identifier and identified is purely conventional (i.e. arbitrary, i.e. a 'name'). It does not have to have a URN prefix to be a name. Nameness comes from whether it has the property of thirdness or not. news: URIs have always been URNs, so are message IDs. [OK I'll accept IP address literals and I will accept DNS names that may not resolve on the Internet due to split horizon DNS.] -- Website: http://hallambaker.com/ From nobody Thu Apr 17 13:31:38 2014 Return-Path: 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 0C62C1A01C5; Thu, 17 Apr 2014 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 PrbqMIkJvi1l; Thu, 17 Apr 2014 09:21:09 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C1C401A01C2; Thu, 17 Apr 2014 09:21:09 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 4BA161DE05D; Thu, 17 Apr 2014 09:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6x8IjIYhGdbbi94KApu9 6SeAbbA=; b=o7XRfmapPZdSTFeWQ72fO6lbq5zoL1OLQ2HN9iI5EHJ9aA6GneEM vZrAiNdTTbck5Ck+xo/HDTFZNa3wa5JnUHH1YowvOFk4gd2tH8czeqJblNS+853A jG/NV/m+3nEGOIad0X0wAN9S+vLNnf5SsArZ1bTi1D7qwmUQ66aXGf8= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id C28B91DE059; Thu, 17 Apr 2014 09:21:05 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id t60so659544wes.33 for ; Thu, 17 Apr 2014 09:21:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr13028260wib.42.1397751664347; Thu, 17 Apr 2014 09:21:04 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 09:21:04 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 11:21:04 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/lhpJSIImESigU8t3hlVulOY4CjM X-Mailman-Approved-At: Thu, 17 Apr 2014 13:31:32 -0700 Cc: Julian Reschke , urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:21:14 -0000 On Thu, Apr 17, 2014 at 11:13 AM, Phillip Hallam-Baker wrote: > On Thu, Apr 17, 2014 at 5:39 PM, Julian Reschke wrote: >> On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >>> The real difference is that a URL must contains a DNS name and a URN >>> probably does not. >>> ... >> >> Not true. It doesn't need to be a DNS name. > > Why bother with anything else? Its all legacy now or going to be soon > enough. X.500 has never been a viable directory. Telephone numbers are > the only other widespread locator. With the caveat that "DNS name" need not be the same as a hostname (FQDN). It might be a domainname for use as starting point for service location. Can we use URLs for geocaching? For locating resources on satellites? .. From nobody Thu Apr 17 13:31:40 2014 Return-Path: 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 8B4B31A0243; Thu, 17 Apr 2014 09:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 LUmRugSt5o0Y; Thu, 17 Apr 2014 09:30:59 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65C1A0241; Thu, 17 Apr 2014 09:30:57 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id c6so574624lan.31 for ; Thu, 17 Apr 2014 09:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dARVjCWcOMcZNsT0Y9FPjmzoCccWbcfY9NeCseIuzsA=; b=Hg4G8m3APUYJFnUyUCAsuzc8XhpIqg394LULdEE1nGPCndFhnbInq0ArvXWMaeqVdA kZcy1Wf3UKSkq26ng5rZnIv5Fq4yvdO4G2n6/irSztRpMyFA+zsbgAOxP9RPAr1GCWDG w9aK2FGsZnk75uULs8fh3aAiW8tqWhg53+KQsozfZ9yGfg672vDv5x10vhaht7e/+Xu1 +RAoltYrccZyrQkUQZLRk2mmaxu7Iycni+YG2xn45+i6b6JnIFlRW3uoBoaXgA9BwIET 1AjWvSRKDSdKGEfJv+FJ2UBMNh3XvDUwd9+NAua+QDa5DPQMvmcw/K4yKZ0/GF5JOWO9 3afQ== MIME-Version: 1.0 X-Received: by 10.152.120.168 with SMTP id ld8mr10659911lab.12.1397752252949; Thu, 17 Apr 2014 09:30:52 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Thu, 17 Apr 2014 09:30:52 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Thu, 17 Apr 2014 19:30:52 +0300 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Tdmf93sD8QDNaPJV5y7Q2ySMikY X-Mailman-Approved-At: Thu, 17 Apr 2014 13:31:32 -0700 Cc: Julian Reschke , urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:31:03 -0000 On Thu, Apr 17, 2014 at 7:21 PM, Nico Williams wrote: > On Thu, Apr 17, 2014 at 11:13 AM, Phillip Hallam-Baker wrote: >> On Thu, Apr 17, 2014 at 5:39 PM, Julian Reschke wrote: >>> On 2014-04-16 20:58, Phillip Hallam-Baker wrote: >>>> The real difference is that a URL must contains a DNS name and a URN >>>> probably does not. >>>> ... >>> >>> Not true. It doesn't need to be a DNS name. >> >> Why bother with anything else? Its all legacy now or going to be soon >> enough. X.500 has never been a viable directory. Telephone numbers are >> the only other widespread locator. > > With the caveat that "DNS name" need not be the same as a hostname > (FQDN). It might be a domainname for use as starting point for > service location. > > Can we use URLs for geocaching? For locating resources on satellites? .. We can certainly use URIs. The issue here is whether we claim it has 'name like' semantics or 'locator like'. Since most of the people who talk about names don't seem to be familiar with the relevant literature, I think the best approach is to limit URLs to locators where we specify the naming infrastructure (DNS, IP, hosts.txt) . That is a distinction we can agree on. -- Website: http://hallambaker.com/ From nobody Fri Apr 18 07:00:49 2014 Return-Path: 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 72E601A01F5; Thu, 17 Apr 2014 18:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 T22mgzKQSuZg; Thu, 17 Apr 2014 18:42:32 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D71781A022F; Thu, 17 Apr 2014 18:42:31 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.32.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 25C7D509B8; Thu, 17 Apr 2014 21:42:22 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Mark Nottingham In-Reply-To: <952E89C207E59D25CD5953D6@JCK-EEE10> Date: Fri, 18 Apr 2014 11:44:32 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> To: John C Klensin X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/urn/rRWe0W3C_-TF7bwVwgvfJM7KRvU X-Mailman-Approved-At: Fri, 18 Apr 2014 07:00:47 -0700 Cc: "Julian F. Reschke" , urn@ietf.org, Graham Klyne , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 01:42:36 -0000 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.=20 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. Cheers, On 16 Apr 2014, at 3:47 am, John C Klensin wrote: > Hi. >=20 > Just wanted to tell folks that I'm on a very poor connection (if > on at all) for the next couple of days and probably won't be > able to give careful answers until Thursday and probably should > not try. But one very quick observation in response to part of > Larry's note... >=20 > --On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter > wrote: >=20 >> The only thing that makes something a name 'persistsent' is >> the existence of a name resolution service or method which >> persists. The syntax or namespace is irrelevant. 'persistent' >> isn't binary, it's just "how long". Everything has a life-time. >>=20 >> http://masinter.blogspot.com/2010/03/ozymandias-uri.html >=20 > I think the above largely misses the point and that, in a sense, > your blog posting illustrates the point although not in the way > you probably intend. "Persistent identifier" entered the IETF > vocabulary a long time ago but may not be very look terminology. >=20 > Some objects -- like stone statues if one doesn't care whether > they remain intact and standing-- have very long life > expectancies. Others, like people, have shorter ones. But URIs > (with or within including URNs) aren't objects, they are object > reference that, like most good references, involve some degree > of abstraction. Now, "Ozymandias" is a very long-persistent > reference. It isn't the object. It is a somewhat ambiguous > reference because it can refer to the statue, the poem, your > blog posting, and probably several other things, but has a long > duration, perhaps one that is long enough to survive the objects > it references (just like titles of long-lost books). But, as a > reference, it is that persistent because it is not bound to a > retrieval mechanism that has its own persistence properties.=20 >=20 > Whatever its other properties, > http://masinter.blogspot.com/2010/03/ozymandias-uri.html > is lousy as a persistent identifier. It depends on the > availability of "http" (or something called that) as a retrieval > mechanism. It depends on there being a DNS, on there being a > TLD named "com" an SLD named "blogspot", and both of them having > certain properties of which HTTP can take advantage. > "Ozymandias", and even the potential URN > urn:poems:Shelley/Ozymandias are more persistent because they > represent a higher level of abstraction and are not tied to > either a location or a retrieval/access method. Use of a > hypothetical ISPN (International Standard Poem Identifier) in > the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or > might not be more persistent: it would be an exact identifier of > something and makes equivalence comparison more feasible and > less ambiguous, but it is probably tied to a database to > actually identify an object and such databases may be more or > less available and persistent than access methods and/or the DNS > (which is, after all, just another database). >=20 > Regardless of what one calls them, I suggest that > access-method-dependent identifiers (http:..., > NineTrackTape:??42.3744=B0?N,?71.1169=B0?W?123456 (where "?" > represents one or more carefully-chosen delimiters that may not > have RFC 3986 semantics), ...) are different kinds of creatures > than either the objects to which they refer or names of those > objects that are not, in the sense of the above, method or > location-model dependent. >=20 > More soon. >=20 > john >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From nobody Fri Apr 18 07:00:51 2014 Return-Path: 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 8C7C01A024A; Fri, 18 Apr 2014 00:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, RCVD_IN_DNSWL_MED=-2.3] 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 6wOH3sMn6KN4; Fri, 18 Apr 2014 00:43:47 -0700 (PDT) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD6E1A019A; Fri, 18 Apr 2014 00:43:47 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Wb3SS-0005A9-ob; Fri, 18 Apr 2014 08:43:36 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Wb3SS-0007qQ-7Q; Fri, 18 Apr 2014 08:43:36 +0100 Message-ID: <534F4321.2020802@ninebynine.org> Date: Thu, 17 Apr 2014 03:57:37 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Larry Masinter References: <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> In-Reply-To: <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/mH4Ah6oGNZ6TvQ_FFJmG6TX4a8U X-Mailman-Approved-At: Fri, 18 Apr 2014 07:00:47 -0700 Cc: "julian.reschke@gmx.de" , "urn@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 07:43:50 -0000 On 15/04/2014 17:25, Larry Masinter wrote: > Is it time to revive http://tools.ietf.org/html/draft-masinter-dated-uri and finally get it to RFC? I think so. But I also don't see sufficient head of unrequited need to get this progressed as a standards action. YMMV. My suggestion would be to request informational, maybe ISE, RFC publication with provisional URI scheme registrations. That creates an available and persistent (sic) reference that developers might think about using if it meets a need (e.g. in Memento [1] implementations?). Then, if it does become widely used, there's a ready point of departure for a standards action. #g -- [1] http://tools.ietf.org/html/rfc7089 From nobody Fri Apr 18 07:52:54 2014 Return-Path: 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 5086C1A03A8; Fri, 18 Apr 2014 07:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Lu6NK14ntBZN; Fri, 18 Apr 2014 07:48:46 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0890B1A03A7; Fri, 18 Apr 2014 07:48:45 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so1862068oag.14 for ; Fri, 18 Apr 2014 07:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CgPPm4qdKiXdk+Ar1lGgQBy0iwLx8aiLkQQPsZFuq5U=; b=htq9yMTNVgAyv0EWyZh15WW4IllxK5zpmKMYlnicws0p+rhn37dWIAwldkkSwQWnXa YTjvGlYWmU+qEhSmxyY1lULHTlsvwhtV6zgs+mVnoUbfuLrEQvyQiBAjLuWdMmyMMzCB qe8O1DCu4BZtmEUR9AR5fTTv7eZWNR4Qba5Q31XB/edy7sZkliOEtyt5dbEPxBDsvM5j gUQZC/whOnLYUHqewXqzTwy+FKLglkOn84/p6CIon8DOm0rt7NtubEYxwcvq9HqcUwI2 HN+E+VcyC3ooNUrgtG6kzzm0Leva1j1KxE93J6zA/kkTJx8s+OM/rU6Dc9etrhWtFmtm wVjg== X-Received: by 10.60.62.178 with SMTP id z18mr1229919oer.61.1397832522074; Fri, 18 Apr 2014 07:48:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.153.6 with HTTP; Fri, 18 Apr 2014 07:48:21 -0700 (PDT) In-Reply-To: <534FFB98.5040607@gmx.de> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <534FFB98.5040607@gmx.de> From: Scott Brim Date: Fri, 18 Apr 2014 10:48:21 -0400 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c20decef101804f7523e9a Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ZAe9BWBG6y2wvsV41H__HNRngUQ X-Mailman-Approved-At: Fri, 18 Apr 2014 07:52:52 -0700 Cc: Nico Williams , urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 14:48:47 -0000 --001a11c20decef101804f7523e9a Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 12:04 PM, Julian Reschke wrote: > A URL is a locator which might be a stable name as well. > > A URN is a name that may act as a locator later on. I would be careful about trying to take the network locator/identifier discussion into UR* space. A locator in the network gives you a network attachment point, not the object attached to it. Also there are many identifiers that are unrelated to any locators. The mapping to app space isn't very good and using locator/identifier could produce confusing results. Perhaps you could think of URLs as naming "instances"? Scott --001a11c20decef101804f7523e9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 17, 2014 at 12:04 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
A URL is a locator which mig= ht be a stable name as well.

A URN is a name that may act as a locator later on.

I would be careful about trying to take the network locator/identi= fier discussion into UR* space. A locator in the network gives you a networ= k attachment point, not the object attached to it. Also there are many iden= tifiers that are unrelated to any locators. The mapping to app space isn= 9;t very good and using locator/identifier could produce confusing results.=

Perhaps you could think of URLs as naming "instanc= es"?=C2=A0

Scott

--001a11c20decef101804f7523e9a-- From nobody Fri Apr 18 09:35:28 2014 Return-Path: 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 94A841A0372 for ; Fri, 18 Apr 2014 08:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 NmQjhmDc5U0F for ; Fri, 18 Apr 2014 08:20:01 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 62C1D1A01EF for ; Fri, 18 Apr 2014 08:20:01 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id up15so1565694pbc.20 for ; Fri, 18 Apr 2014 08:19:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2KEXzUWcGAURlWhW/17fah2GSaEVtQ19zY94vps/f1Q=; b=Ib/UnVyyFPENyiOQuz3P+BlILtNR5v65hCy3hfVNf1pRCiXaty94KG9OriSuSv4/Fm kdK5UNmqDJVojp+QzXiKOTBlQ1Ee7DLsJ0Uh0GZ4MLwapb5m5uenlafGmnjvPDattJur 2xteIkIn+5MqKbGDKSvVcBPJtZ8hXt2evwIZLhuSNgDymcDQ+gAFhcTtud2LY/OvBVFd wglmbw8/cyEOGQhFoNOTDLulc520a8fifAwjxrWB+hXOq6zkDFEu0TMrMt3KTsXNIy1a HYtoVx6I2VsDXis/iDIt0JR2dlBxgD2mzPcHifn5BMHu/wPdp4VdjAsogGo8T1l2ETyT 37PA== X-Gm-Message-State: ALoCoQmMCJ9PO6y3Hdhk0HaZDXqRbYdch9y8DMZEPnOrsjH8PN2run30WYVd3C+MgR1ukMbiJelm MIME-Version: 1.0 X-Received: by 10.66.233.9 with SMTP id ts9mr22609383pac.37.1397834397463; Fri, 18 Apr 2014 08:19:57 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.103.164 with HTTP; Fri, 18 Apr 2014 08:19:56 -0700 (PDT) X-Originating-IP: [192.0.216.13] Received: by 10.70.103.164 with HTTP; Fri, 18 Apr 2014 08:19:56 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Fri, 18 Apr 2014 11:19:56 -0400 X-Google-Sender-Auth: TnAnqne-w8uqd70W1sJaEij93vE Message-ID: From: Mark Baker To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7b111c53b74b7c04f752ae32 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/3FZYzP3p8sOvGo1qGsEBSmpjz1Y X-Mailman-Approved-At: Fri, 18 Apr 2014 09:35:26 -0700 Cc: Julian Reschke , Nico Williams , urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 15:20:03 -0000 --047d7b111c53b74b7c04f752ae32 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker wrote: > We can certainly use URIs. The issue here is whether we claim it has > 'name like' semantics or 'locator like'. Whether it's a name or a locator is not an intrinsic property of the string, but depends solely upon the presence or absence of a local resolution mechanism for that string. A string that *you* might *today* call a "name", might already be a "locator" to somebody who's rigged a private resolution service. Ten years from now, that "name" might be a "locator" to all of us. Mark. --047d7b111c53b74b7c04f752ae32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> We can certainly use URIs. The issue here is whether we claim it has > 'name like' semantics or 'locator like'.

Whether it's a name or a locator is not an intrinsic pro= perty of the string, but depends solely upon the presence or absence of a l= ocal resolution mechanism for that string.

A string that *you* might *today* call a "name", m= ight already be a "locator" to somebody who's rigged a privat= e resolution service. Ten years from now, that "name" might be a = "locator" to all of us.

Mark.

--047d7b111c53b74b7c04f752ae32-- From nobody Fri Apr 18 12:53:32 2014 Return-Path: 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 ) 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 To: Mark Nottingham Message-ID: In-Reply-To: <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> References: <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" , urn@ietf.org, Graham Klyne , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 19:53:31 -0000 --On Friday, April 18, 2014 11:44 +1000 Mark Nottingham 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 From nobody Fri Apr 18 15:00:43 2014 Return-Path: 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 1995E1A01D3 for ; Fri, 18 Apr 2014 15:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.472 X-Spam-Level: X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 96yQbzelIGhy for ; Fri, 18 Apr 2014 15:00:37 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9401A01CE for ; Fri, 18 Apr 2014 15:00:37 -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 ) id 1WbGpk-000DVT-O9; Fri, 18 Apr 2014 18:00:32 -0400 Date: Fri, 18 Apr 2014 18:00:27 -0400 From: John C Klensin To: "Dale R. Worley" , urn@ietf.org Message-ID: In-Reply-To: <201404171948.s3HJmTVr005063@hobgoblin.ariadne.com> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <201404171948.s3HJmTVr005063@hobgoblin.ariadne.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/rZatTTYX1WC3OS--1XUIuyq2NhM Subject: Re: [urn] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 22:00:42 -0000 Dale has raised several issues that really are about the URN question, rather than URI hair-splitting. I want to address some of them here; others really require either some fairly extensive changes to the "URNs are not URIs" spec or to 2141. I've tried to note those below. --On Thursday, April 17, 2014 15:48 -0400 "Dale R. Worley" wrote: > I think some of the questions that we're dealing with are > fairly deep and they're not being addressed well. > What is really under debate is overhauling URNs. That is, > producing a a new syntax (and possibly semantics) of URNs that > is not necessarily upward-compatible with RFC 2141. There are perhaps three ways to interpret "upward-compatible with RFC 2141": (i) Compatible as long as no syntax is used that either violates 2141 or requires the "reserved for future use" elements. (ii) Compatible, but assigning some purpose and semantics to syntax 2141 reserved for future use. (iii) Compatible, but requiring syntax and semantics that 2141 did not explicitly reserve for future use or that is incompatible with those reservatons. I haven't heard from anyone who feels a need to violate interpretation (i). Whether we can stick with (ii) or need (iii) is still an open question, but my own guess is that we can stick with (ii) and should probably do so. That is definitely a topic for the WG to discuss. > But what I'm not seeing is a discussion of the factors that > would drive such a decision: > > - Why is the current framework inadequate? > > - How will use of URNs of the new type coexist with URNs of > the old type? These topics have actually been extensively discussed on this WG's mailing list. They are hinted at in the "URNs are not URIs" draft, but only as hints. I would welcome specific suggestions as to what text should be added or changed there, but believe that specific syntax and the justification for it should go in 2141bis because that is about URNs, not about separating URNs from RFC 3986. I hope Juha and others can refine what follows. As an _extremely_ quick and superficial summary, in a number of uses, including at least some applications from what the draft calls "memory organizations", a URN actually has a multiple role. There are a couple of different ways to look at that. Personally, I've been dealing with "metadata" issues in various sorts of databases for enough years to become deeply suspicious of the term: I've noticed that, very often, someone stays "it is metadata" and then starts handwaving furiously. But, if one assumes that a particular URN can be treated as a formal name for an object, the URN by itself actually isn't useful for very much other than, e.g., to determine whether that name matches a name/string in a database. Things become interesting when one can ask about information --some persistent, some not-- that might be bound to the name. For example, one can ask where a copy of the named object can be located, a question that might reasonably be qualified by enough geographical or network information to make options like "nearest" possible. One could ask any of a whole series of questions about the object that don't involve its location or retrieval: size, weight, number of pages, language, other editions or translations, conditions for use, and so on. In each case, the mechanism for obtaining that information might be different from the mechanism for obtaining a location for the object (and knowing the location is more likely to involve a locator with its own associated retrieval/access Method than the object itself). There are multiple difficulties with "locators" in the URL sense. The first was, if I recall, one of the fundamental justifications for creating URLs in the first place. A hypothetical URN, urn:USA-historical-document:US-Declaration-of-Independence identifies several signed originals (on paper, multiple locations), a bunch of URLs that point to facsimiles of that document, a bunch of other URLs that point to digital incarnations of its text. One could model those different things as a series of different URNs (with different NIDs), but each one would still have multiple instances. In traditional reference librarian-land, attempting to exercise (the most neutral word I can think of at the moment) might yield which instance (across category) was the most handy or might produce a request for more information about what was needed. In the latter case, one would then want to be able to qualify the URN with category, location preference, etc., information. Now, the RFC 3986 URI model provides only two tools (bits of syntax) for specifying those types of information. One is a query. There is no practical way to define categories of queries, e.g. for URNs, to handle a request for object location information in a standard way. And, more generally, 3986 imposes some implicit semantics on queries that are related to the assumption that a scheme name - authority pair will point to the location and retrieval method for a particular object to which the query is to be applies and that schemes that don't use syntax to invoke an authority are still a surrogate for that relationship [1]. Because of the "information about a name" issues described above, queries are not a very good fit unless one can model a query as a category, possibly some subcategories, a question, and values for that question, and the 3986 model is not very friendly to that approach. The second mechanism is a fragment and its is worse because the semantics in 3986 appear to require that the object be retrieved (which may not be meaningful for some URNs) and then processed to turn the fragment identifier into a pointer into, or subset of, that retrieved object. > In particular, I've seen repeated statements that the current > framework is inadequate for the future development of URNs, > but I haven't seen even a summary of the discussion, nor any > pointer to the record of the discussion discussion itself, nor > how to participate in that discussion. See above. With luck, that summary --which has, I'm certain, its own set of problems-- can act as a starting point (perhaps one of several) to get the discussion started again. The question for you and the WG is how much of it needs to go into an I-D at this point and, if so, which one ("urns-are-not-uris" and 2141bis are the obvious possibilities, but there are other things we could do). best, john [1] That point is debatable and has been extensively debated. Whether it is taken to be correct or not seems to me to have more to do with the question of whether URN-ish things can be forced into the Generic URI mold than with some fundamental and provable principle of information science or knowledge engineering. From nobody Fri Apr 18 15:55:09 2014 Return-Path: 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 AEF9F1A01F0 for ; Fri, 18 Apr 2014 15:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 F4hQ2rhHZ-mH for ; Fri, 18 Apr 2014 15:55:04 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6D68F1A03C7 for ; Fri, 18 Apr 2014 15:55:03 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db11so3833749veb.21 for ; Fri, 18 Apr 2014 15:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=rzHkbKj2BGCvvZUMgvzaksofdMYyd/ZZX63ncvhy4tI=; b=of7jE4Qk1HK+kT8cVTdYg7bmdfWZM1I7aYLo3FdltymkovtoIcgtmoaRC4fGDjI1Ii mwNW0WvLO+w/lwb+qh5h7Sm9skw/CyKuVdlseI8ZSXC7WpcRQJF5VAzesx0dJ8+SRUkH HAnyKWs4W8q6N+b3zIzXNcrzyXb26drZSkZciuB03PgO+0e3WS3UqCAv041vNrC6Z7tf xfsId2mSJTQ6oYq3CsdQEdsgbXi+/3QHSHxsVAJSjhxwSmsgfu36jO+M35QehTcsTPJ0 RKcXBopqBHRs/KdR7Zo6L8TXW4Vs9b3XyxEvkB/j6/vzaor230TKfBfBN6OV+1oYm9sA REyg== MIME-Version: 1.0 X-Received: by 10.52.119.197 with SMTP id kw5mr14052091vdb.5.1397861699143; Fri, 18 Apr 2014 15:54:59 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Fri, 18 Apr 2014 15:54:59 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <201404171948.s3HJmTVr005063@hobgoblin.ariadne.com> Date: Fri, 18 Apr 2014 18:54:59 -0400 X-Google-Sender-Auth: 6vrFrpARkkSVp809tW6XGUOIoxo Message-ID: From: Barry Leiba To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/GJLEt3umM6qmkRJO6BDA5apDmOk Subject: Re: [urn] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 22:55:08 -0000 I'm replying to one of John's messages for convenience, but this isn't directly in response to that (for those who are following in a threaded mail client). I want to untangle one thing that's come up a number of times: persistence. We seem to have a lot of confusion because we have things called "URNs", and we have a URI scheme "urn:". Note that we do not have URI schemes "uri:" or "url:". That means that it's easy to talk about URIs and URLs without confusion, but talking about URNs gets us wrapped around an axle. There's a type of identifier that we call a "name", which has certain characteristics that distinguish it from identifiers that we'll call "locators". In particular, the name is just a name, like "Barry Leiba". That name identifies me (and perhaps other people, but that doesn't matter for now). It doesn't tell you where to find me. It doesn't tell you anything else about me. "barryleiba@computer.org" also identifies me, but it *does* tell you some of those other things (it tells you where to send email to me; in URI terms, we'd say "mailto:barryleiba@computer.org"). The name "Barry Leiba" can be more or less "persistent". Reg Dwight's parents might have thought his name would persist for his entire lifetime, at least, but now he's Elton John. I dare say that name will persist long after his life is over. So with URNs: their persistence varies. RFC 2141 defines a type of URN, a type of name, that begins with "urn:". It tells us that these names that begin with "urn:" "are intended to serve as persistent, location-independent, resource identifiers," and it tells us something of what that means. But there are other URNs, other URIs that are names, which do not (necessarily) have that characteristic, and which are not covered under RFC 2141. "ni:", for instance [RFC6920], defines names -- they are most clearly NOT locators. There are others. Now, the notion of persistence varies from one type of URN, one type of name, to another. For "urn:", RFC 2141 describes it. But it's clear that "ni:" is meant to be used to name transient resources, as well as long-lived ones. Let's not get too stuck on this, and let's be clear what the scope is. I think we did ourselves a disservice by creating a generic name ("URN") and a scheme ("urn:") that can be so confused. Barry From nobody Fri Apr 18 19:34:53 2014 Return-Path: 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 0508B1A0224; Fri, 18 Apr 2014 19:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 SMjM555Vu9Te; Fri, 18 Apr 2014 19:34:45 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id ED5E21A021E; Fri, 18 Apr 2014 19:34:44 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id p9so1790857lbv.4 for ; Fri, 18 Apr 2014 19:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lSa50wEseoxWj3d2gaF2XEnoV5izdqZTv91UroGlh4o=; b=wyXObgy81MA+NdOpYPK9f3UXS8/49T8UpwZBCjhOduZD+Axw45Kw6oNbqHrhdsq46w VIfCpAtKRjxCw95tHfvIdukNCEws1GPcTtfWb934Q7RgNos1+NnrSSFWq208I0I+wenI FLN535m6nOkomgG0YpvY2FVkHJoYF9xAhWzJ/6r7FevbzG9LtPYyT9Vivl/ZA9koqqJp hKHKfzBYme4wtL4DwTZRQtmgNk66ev7rgVNdRIqPORgwmRxu155ux0kWmJkKnSD17Dbr 0fclqVlN14S5+s1ny0ISgQRfZ1RBAFK/bkYbrWiC7RxqmitHPQ/+kl5r2pqlLSnVu9Pc X5Tg== MIME-Version: 1.0 X-Received: by 10.112.61.199 with SMTP id s7mr1688934lbr.25.1397874880095; Fri, 18 Apr 2014 19:34:40 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Fri, 18 Apr 2014 19:34:40 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Fri, 18 Apr 2014 22:34:40 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/xxID1FLXu20T5z6hkhXJc39vE7s Cc: Julian Reschke , Nico Williams , urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 02:34:50 -0000 On Fri, Apr 18, 2014 at 11:19 AM, Mark Baker wrote: > > On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker > wrote: >> We can certainly use URIs. The issue here is whether we claim it has >> 'name like' semantics or 'locator like'. > > Whether it's a name or a locator is not an intrinsic property of the string, > but depends solely upon the presence or absence of a local resolution > mechanism for that string. > > A string that *you* might *today* call a "name", might already be a > "locator" to somebody who's rigged a private resolution service. Ten years > from now, that "name" might be a "locator" to all of us. Which is exactly what I was saying. For example, UPC code for a can of baked beans is a URN. But if you go to Amazon you can use it as a locator, albeit mediated via UPS rather than TCP/IP. -- Website: http://hallambaker.com/ From nobody Sat Apr 19 06:00:12 2014 Return-Path: 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 5ADED1A0201; Sat, 19 Apr 2014 06:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 wtdW4uKcRrLq; Sat, 19 Apr 2014 06:00:05 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 795271A0194; Sat, 19 Apr 2014 06:00:05 -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 ) id 1WbUs6-000F0s-0f; Sat, 19 Apr 2014 08:59:54 -0400 Date: Sat, 19 Apr 2014 08:59:49 -0400 From: John C Klensin To: Phillip Hallam-Baker , Mark Baker Message-ID: <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> 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/XiJwGZ4BH8abY_uudrcs0RDOeVo Cc: Julian Reschke , Nico Williams , urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 13:00:08 -0000 --On Friday, April 18, 2014 22:34 -0400 Phillip Hallam-Baker wrote: >> A string that *you* might *today* call a "name", might >> already be a "locator" to somebody who's rigged a private >> resolution service. Ten years from now, that "name" might be >> a "locator" to all of us. > > Which is exactly what I was saying. > > For example, UPC code for a can of baked beans is a URN. > > But if you go to Amazon you can use it as a locator, albeit > mediated via UPS rather than TCP/IP. As Mark Nottingham suggested and I tried to elaborate, this particular discussion may be interesting (or not), but, in the current context, isn't worth the energy it takes. First, a UPC code for a can of beans isn't a URN. If an identifier for those were documented and registered as an NID, or if it were treated as part of an identifier sub-space within the "epc" NID specified in RFC 5134, _that_ would be a URN. As a URN, the defining materials would presumably come with a lot of information about what it was and what operations could be performed with it. For a URN based on that UPC associated with a can of beans, those operations might include whether its purpose is just to distinguish one brand or can-size of beans from another or whether it can be used to retrieve a product (see below). That set of distinctions is not just pedantry. If "URN" mean whatever someone claims it means at a given moment, then we don't have a specific category of identifier, we just have a very generic term for some variety of identifier. For the information it contains, one might as well have the above statement read "UPC code for a can of baked beans is an Ironduck". Even ignoring whether it is a URN or not, a UPC doesn't act as a UPS-mediated locator, any more than urn:isbn:0-88175-188-X is a TCP-medidated locator. It is an identifier of an abstraction of a class of objects. To get the object to your doorstep, it is typically necessary to resolve it to a different product abstraction, to a warehouse and location in it, to a shelf-picking mechanism, and so on, typically through several step before a particular can-instance is finally chosen, boxed, labeled, and handed over to UPS (or some other transit carrier whose choice might be another item in the list of abstraction-resolutions. In addition, like many URNs (see my notes on the URN list), there are other useful questions that apply to the generically-named object and not to the particular can that might be located. For example, "what is the size of the can associated with that code" is a question about the generic named object. "What is the sell-by date" probably still doesn't apply to a particular can that needs to be located and retrieved before the question can be answered -- perhaps it is sufficient to locate a case of cans and to do so in an appropriate database. So I suggest they are still different from http-type URLs in more ways than the [retrieval] method. But, again as Mark Nottingham pointed out, it may be that the greatest value of this proposed separation is to get around the situation of different communities talking past each other and being unwilling to accept each other's perspective and legitimacy even to the extent needed to have a real conversation. john From nobody Sat Apr 19 14:19:11 2014 Return-Path: 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 EE92B1A00FA; Sat, 19 Apr 2014 14:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 8CJMydaS6ukV; Sat, 19 Apr 2014 14:19:02 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id EC1831A00F4; Sat, 19 Apr 2014 14:19:01 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id uz6so560211obc.14 for ; Sat, 19 Apr 2014 14:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BI3BYlVC4lq/Bk+hkDDA+69Ibb5wiB60ySj/oYF5O0Q=; b=0yBh7CKQSimAbCkvL5tPO2glee2cPR4nfJffPynmgC4G0NL8sEc43K/TS2bcfRPUe1 vf+5AN+goNb9mtaFqPEtPJYiIbfTE61/y42mn0qTj2T6I/E650/AfkbtP1LpdkJBB/Ps rzJTDw6n7/5fWXMM/00zCPRTMbnW52+RWhKC2kPJ/OXEt8MZncsu+WAD7AJrx3lArRYJ jDtjxwM8lO29CD9J0pvOvsuwjS5/3MTh0RdrGy7mE4nJlTc65UqMyoEdCIYWmhVtvwu+ 3AV0mDwN2mG9PCj7Q2IYBcp1vIBqp/zrr0RauHIVOogRyqb0kdGcb8/Fr783T7y07TBb OnWQ== MIME-Version: 1.0 X-Received: by 10.182.225.194 with SMTP id rm2mr3635924obc.49.1397942337470; Sat, 19 Apr 2014 14:18:57 -0700 (PDT) Received: by 10.183.6.196 with HTTP; Sat, 19 Apr 2014 14:18:57 -0700 (PDT) Received: by 10.183.6.196 with HTTP; Sat, 19 Apr 2014 14:18:57 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Sat, 19 Apr 2014 17:18:57 -0400 Message-ID: From: Scott Brim To: Mark Baker Content-Type: multipart/alternative; boundary=001a11c2ef1c7105f704f76bd0a8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/pBpZRDTFGkOzZtsYJEeRx8u0ymE Cc: Julian Reschke , urn@ietf.org, Phillip Hallam-Baker , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 21:19:04 -0000 --001a11c2ef1c7105f704f76bd0a8 Content-Type: text/plain; charset=UTF-8 The inverse way of looking this is that identity-related functions can use anything they want since they can treat it opaquely ... and do ... while location-related functions are limited to tokens they understand the semantics of. On Apr 18, 2014 11:20 AM, "Mark Baker" wrote: > > On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker > wrote: > > We can certainly use URIs. The issue here is whether we claim it has > > 'name like' semantics or 'locator like'. > > Whether it's a name or a locator is not an intrinsic property of the > string, but depends solely upon the presence or absence of a local > resolution mechanism for that string. > > A string that *you* might *today* call a "name", might already be a > "locator" to somebody who's rigged a private resolution service. Ten years > from now, that "name" might be a "locator" to all of us. > > Mark. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --001a11c2ef1c7105f704f76bd0a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The inverse way of looking this is that identity-related fun= ctions can use anything they want since they can treat it opaquely ... and = do ... while location-related functions are limited to tokens they understa= nd the semantics of.

On Apr 18, 2014 11:20 AM, "Mark Baker"= <distobj@acm.org> wrote:


On Thu, Apr 17, 2014 at 12:30 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> We can certainly use URIs. The issue here is whether we claim it has > 'name like' semantics or 'locator like'.

Whether it's a name or a locator is not an intrinsic pro= perty of the string, but depends solely upon the presence or absence of a l= ocal resolution mechanism for that string.

A string that *you* might *today* call a "name", m= ight already be a "locator" to somebody who's rigged a privat= e resolution service. Ten years from now, that "name" might be a = "locator" to all of us.

Mark.


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--001a11c2ef1c7105f704f76bd0a8-- From nobody Sat Apr 19 15:23:28 2014 Return-Path: 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 9E45F1A0064 for ; Sat, 19 Apr 2014 15:23:26 -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 PMzwDa7iWhfk for ; Sat, 19 Apr 2014 15:23:25 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAB01A00C3 for ; Sat, 19 Apr 2014 15:23:24 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WbdfF-000Fo0-Kw; Sat, 19 Apr 2014 18:23:13 -0400 Date: Sat, 19 Apr 2014 18:23:13 -0400 From: John C Klensin To: Barry Leiba , urn@ietf.org Message-ID: <0AA27476D31271A2A5908F40@[192.168.1.128]> In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <201404171948.s3HJmTVr005063@hobgoblin.ariadne.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: ::1 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/ecXAf8AyKd9bKtXCPxcXgMxpG-s Subject: Re: [urn] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 22:23:27 -0000 --On Friday, 18 April, 2014 18:54 -0400 Barry Leiba wrote: > I'm replying to one of John's messages for convenience, but > this isn't directly in response to that (for those who are > following in a threaded mail client). I want to untangle one > thing that's come up a number of times: persistence. > > We seem to have a lot of confusion because we have things > called "URNs", and we have a URI scheme "urn:". Note that we > do not have URI schemes "uri:" or "url:". That means that > it's easy to talk about URIs and URLs without confusion, but > talking about URNs gets us wrapped around an axle. >... > Now, the notion of persistence varies from one type of URN, > one type of name, to another. For "urn:", RFC 2141 describes > it. But it's clear that "ni:" is meant to be used to name > transient resources, as well as long-lived ones. > > Let's not get too stuck on this, and let's be clear what the > scope is. I think we did ourselves a disservice by creating a > generic name ("URN") and a scheme ("urn:") that can be so > confused. Indeed. While I would describe the distinction a bit differently than Barry does (and that may be part of the confusion), my draft is about the "urn:" scheme. In addition, I believe that anything else is out of scope for this WG. If I need to revise the draft to make that distinction more clear, I will do so.. real soon now. Obviously, an alternative would be to create an entirely new scheme, perhaps called "urf" (for "fooey"), make it upward-compatible except for the scheme name with RFC 2141, never use the term "URN" to describe it, and make it clear from the onset that, whatever RFC 3986 describes and whatever resemblance it bears to some of the things RFC 3986 describes, it just isn't one of those. I really, really, hope we don't have to go there because it would probably create even more confusion. But, if it is the only way to get unstuck... john From nobody Sat Apr 19 15:39:10 2014 Return-Path: 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 9D24E1A0104; Sat, 19 Apr 2014 15:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 rUiMsRoOfctl; Sat, 19 Apr 2014 15:39:04 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A1D741A0100; Sat, 19 Apr 2014 15:39:04 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 1E32721DE59; Sat, 19 Apr 2014 15:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=UcHPKy6zX4Sr7f+ZWIlN Uno6V2w=; b=UJz3u5Z+XJNUjBJcIaoG9l5oXx//DqyYpijB9gnLTNtl7kDunA7/ gDnYuttGdgKxHYA24CgTN9FoJRQKju4nOXdep7Q7tDp9bZZ8R8k4nPxOXzgJ5XrP npZ/jhgJgZgTDjFNSb/smmlEB5DDxFfXtxC6mjkytsqhEnx+OzHi8a8= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 9A34521DE58; Sat, 19 Apr 2014 15:38:59 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so690566wiv.7 for ; Sat, 19 Apr 2014 15:38:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.160.166 with SMTP id xl6mr7886420wib.42.1397947138372; Sat, 19 Apr 2014 15:38:58 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sat, 19 Apr 2014 15:38:58 -0700 (PDT) In-Reply-To: <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> Date: Sat, 19 Apr 2014 17:38:58 -0500 Message-ID: From: Nico Williams To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/wYrtUEgijowMXBKE3I7VLx9gj2Q Cc: Julian Reschke , Mark Baker , urn@ietf.org, Phillip Hallam-Baker , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 22:39:08 -0000 On Sat, Apr 19, 2014 at 7:59 AM, John C Klensin wrote: > That set of distinctions is not just pedantry. If "URN" mean > whatever someone claims it means at a given moment, then we > don't have a specific category of identifier, we just have a > very generic term for some variety of identifier. For the > information it contains, one might as well have the above > statement read "UPC code for a can of baked beans is an > Ironduck". In GSS land we've switched (for new interfaces) from using ASN/1 OIDs to using URNs. Our OIDs name no objects and our URNs no resources. They are merely identifiers with reasonable namespaces and name allocation policies. URNs are much easier to use for this purpose (one look at how the GSS-API C language bindings handle OIDs should make this clear!). Is this an abuse of URNs? Does/should anyone care? IMO: "no", and "no". But it helps to have registered identifiers, so we can find the specifications (or at least some information) that describe their semantics. Or perhaps our uses of OIDs/URNs do in fact name objects/resources, if we give specific behaviors/semantics the honor of being objects/resources. For me, all that matters when it comes to URNs is that we agree to namespace partitioning and registries for those uses that warrant them. If you want to call URNs "Ironducks", so be it. Nico -- From nobody Sat Apr 19 15:45:09 2014 Return-Path: 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 36DB81A00FD; Sat, 19 Apr 2014 15:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no 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 pP7isNqb6Y0p; Sat, 19 Apr 2014 15:45:02 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4B61A0090; Sat, 19 Apr 2014 15:45:02 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 51B4A9405C; Sat, 19 Apr 2014 15:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=PBgHZCPz4akIa6NVw9w8 fw1oje0=; b=FyD8CfLyI9Lrhz7hSihuNQwBQdggVB/BzubuXRpwPnu/Pme1MiPe FBRjYDYfsIU6BGStnM8kEWKMOK9NYVvoSTjX8NqgiJG9yXizgQ72s7OysRQMHGvR PIA9GtQgrXRa/X46TzrpfE5GA2zMV2wa1fV+iPShQs0FVwCKysPOOrM= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id D279494059; Sat, 19 Apr 2014 15:44:57 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id y10so1574127wgg.25 for ; Sat, 19 Apr 2014 15:44:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.76.10 with SMTP id g10mr257116wjw.67.1397947496541; Sat, 19 Apr 2014 15:44:56 -0700 (PDT) Received: by 10.216.29.200 with HTTP; Sat, 19 Apr 2014 15:44:56 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Sat, 19 Apr 2014 17:44:56 -0500 Message-ID: From: Nico Williams To: Scott Brim Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/A4QpkDTxrw3q1RAKMJUCP6b0Pww Cc: Julian Reschke , Mark Baker , urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 22:45:06 -0000 On Sat, Apr 19, 2014 at 4:18 PM, Scott Brim wrote: > On Apr 18, 2014 11:20 AM, "Mark Baker" wrote: >> Whether it's a name or a locator is not an intrinsic property of the >> string, but depends solely upon the presence or absence of a local >> resolution mechanism for that string. >> >> A string that *you* might *today* call a "name", might already be a >> "locator" to somebody who's rigged a private resolution service. Ten years >> from now, that "name" might be a "locator" to all of us. Yes. Consider a use of URNs as opaque identifiers of optional behaviors. Add a registry of such URNs listing their specifications. But now they are both names and locators, since they can be used to locate specifications in the corresponding registries. Now, if there's no way to automate this location, and/or if it's only useful to implementors, then such URNs remain names. Names for what? For behaviors. > The inverse way of looking this is that identity-related functions can use > anything they want since they can treat it opaquely ... and do ... while > location-related functions are limited to tokens they understand the > semantics of. Yes. We could construct a URN namespace where location of specifications via [IANA, say] registry lookups turns them into locators. Just not locators useful to most people. In the end URNs are really just opaque identifiers. Some of them name real resources (e.g., there's a way to name RFCs using URNs); some will not. We should not demand that every URN name a "resource" in that sense! Nico -- From nobody Sat Apr 19 15:49:24 2014 Return-Path: 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 F12531A0106; Sat, 19 Apr 2014 15:49:20 -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 rm7GASgwpA8o; Sat, 19 Apr 2014 15:49:19 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 984461A0100; Sat, 19 Apr 2014 15:49:19 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Wbe4N-000FqC-15; Sat, 19 Apr 2014 18:49:11 -0400 Date: Sat, 19 Apr 2014 18:49:10 -0400 From: John C Klensin To: Nico Williams Message-ID: <9B60F36DE9B614859C913A16@[192.168.1.128]> In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <7F56813812D9F654C3EF271E@JcK-HP8200.jck.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: ::1 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/fbf3Och_pK4_ngsTI2stJoLkihk Cc: Julian Reschke , Mark Baker , urn@ietf.org, Phillip Hallam-Baker , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 22:49:21 -0000 Nico, (top post) Referring to Barry's recent note on the URN mailing list and my response, are you referring the URNs-the-category or urns-the-scheme? If the former, I agree that I don't care, no one else should either. More important, the new I-D isn't about that. If the latter, then I expect that you really should go through the registration procedure described in RFC 3406 if you have not done so. john --On Saturday, 19 April, 2014 17:38 -0500 Nico Williams wrote: > On Sat, Apr 19, 2014 at 7:59 AM, John C Klensin > wrote: >> That set of distinctions is not just pedantry. If "URN" mean >> whatever someone claims it means at a given moment, then we >> don't have a specific category of identifier, we just have a >> very generic term for some variety of identifier. For the >> information it contains, one might as well have the above >> statement read "UPC code for a can of baked beans is an >> Ironduck". > > In GSS land we've switched (for new interfaces) from using > ASN/1 OIDs to using URNs. Our OIDs name no objects and our > URNs no resources. They are merely identifiers with reasonable > namespaces and name allocation policies. URNs are much easier > to use for this purpose (one look at how the GSS-API C > language bindings handle OIDs should make this clear!). Is > this an abuse of URNs? Does/should anyone care? IMO: "no", > and "no". But it helps to have registered identifiers, so we > can find the specifications (or at least some information) > that describe their semantics. Or perhaps our uses of > OIDs/URNs do in fact name objects/resources, if we give > specific behaviors/semantics the honor of being > objects/resources. > > For me, all that matters when it comes to URNs is that we > agree to namespace partitioning and registries for those uses > that warrant them. If you want to call URNs "Ironducks", so > be it. From nobody Sun Apr 20 08:17:26 2014 Return-Path: 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 B235E1A0011; Sun, 20 Apr 2014 08:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 MtRQAaf3y7b2; Sun, 20 Apr 2014 08:17:17 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 921361A0197; Sun, 20 Apr 2014 08:17:17 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jx11so6345040veb.31 for ; Sun, 20 Apr 2014 08:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VjrnfURWjK1zTHdnsl0VsM3H12FhJ56If7esZ7vCsS8=; b=fmdsC4ogpgBhK0Hg+KJ8ZLeWOqc32mHgrQB+RfWHj3F3dERhVB4trv5HQ8kXRwTWI9 aavgw3SYsjGgCxbNbbokjv6VP8LNcqhjKOfUhr940IrVECjfEF5y/BJqBRJnlfvdgQq3 OEi4RbliHxbQQT8hpplcxnhOnICEDj8sf04u8pLEQ8Bf1EAoKxj0ndN+/giarohkFh18 V+fXfqsbJg4PthzrOAuZyl0OgFStlemzifCQHYU4aL4gA0EKTt6mE6qTrNsNuonXXUp0 YfpNJOeEeAK4/x0Om8LRaHslXKiTHYcfaKkb8OUCDXKReAkwMj5+PuzUFtjqPtGPnXM8 YX1g== MIME-Version: 1.0 X-Received: by 10.220.161.8 with SMTP id p8mr25588790vcx.4.1398007032641; Sun, 20 Apr 2014 08:17:12 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Sun, 20 Apr 2014 08:17:12 -0700 (PDT) In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Sun, 20 Apr 2014 11:17:12 -0400 X-Google-Sender-Auth: Xb4aQg7oaiHWcX1Y174vhUqSkOo Message-ID: From: Barry Leiba To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/-5h9TWFzwS07nXovU4v-DzUjNd4 Cc: General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 15:17:24 -0000 Again, addressing just one point here: Graham said this: > DOIs > are conceived as names, and have the appropriate management processes > around them applicable to names. But I have observed that in recent times, > the preferred form for presenting DOIs to the Web has increasingly been in > the form "http://dx.doi.org/..." or similar (see also: [1]). I think this > exemplifies something that MAY be used as both identifier and name. Phill said this: >> A string that *you* might *today* call a "name", might already be a >> "locator" to somebody who's rigged a private resolution service. Ten years >> from now, that "name" might be a "locator" to all of us. > > Which is exactly what I was saying. > For example, UPC code for a can of baked beans is a URN. > But if you go to Amazon you can use it as a locator, albeit mediated > via UPS rather than TCP/IP. I think both of these confuse the issue. Given a name, we can often turn it into a locator. That's clear, and that's one thing that makes names useful. But I think we still need to keep in mind that the names *aren't* locators. If I can always take "urn:doi:xyz-abc", transform it to "http://dx.doi.org/find/xyz-abc", and get a valid locator for the thing named, that's great. But it's still the case that the former is a name and *not* a locator. And if dx.doi.org goes away at some point, the thing is still named by "urn:doi:xyz-abc", even though I can no longer use that locator. It's rather like using "Barry Leiba" to talk about me, and that's fine as long as it's a reference. But as soon as you need to *find* me, you have to get a locator. The locator might or might not contain my name; it could be "barryleiba@computer.org", it could be my phone number, it could be a URL for my web site, or it could be a suggestion that you look here on a Friday evening. Again, for the purposes of abstraction, let's be sure to remember the distinction, and to be clear about the scope of what we're discussing. Barry From nobody Sun Apr 20 22:42:09 2014 Return-Path: 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 5D71B1A0049 for ; Sun, 20 Apr 2014 22:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 yrObjJj9Gpcm for ; Sun, 20 Apr 2014 22:42:01 -0700 (PDT) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF021A0043 for ; Sun, 20 Apr 2014 22:42:01 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id md12so3374189pbc.23 for ; Sun, 20 Apr 2014 22:41:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mlbO7uV1uCH4UqeZ+orU65Mil6qHRAjB9iL74TSBxV0=; b=JB+EgRyOf1qLTWAsYAAYRr5GynkkRkMny6+9/OCq5F5CsT1Z4n/uBooaqy4412QCfW xJa6GC3abq3iTx+k0qBHIcNdfqmuiDJlHH3s/6Qu0GpGzA9cajE6YFfTAAdQCzm4kbXf CAzXZRy6vHk653nzEM1A2ZaIPPXPoNAf5Q/WJzGsvbCwavCfjoCy9+pRcdT8WsgLvwau f+HKzujx2OGI9DejIiNnSSrfFf3pRUddzqgVYveohrLrrIlU5ZjWI55kb2l5555W2whb 6vvwqosB3+pmvnAJ1sMJLaQPapIcfh8fTaCcfQJ8Uzr0+nEtB7hNv/tgTH6mEdDshQy8 3How== X-Gm-Message-State: ALoCoQl0dgrMnDpGu0b93FnlDya0b9nkUzxKPRW7RUED6b1QVJYrren54sAqeLAjw1WmFiNCkVQ2 MIME-Version: 1.0 X-Received: by 10.66.136.71 with SMTP id py7mr36406264pab.2.1398058916377; Sun, 20 Apr 2014 22:41:56 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.103.164 with HTTP; Sun, 20 Apr 2014 22:41:56 -0700 (PDT) X-Originating-IP: [192.0.216.13] In-Reply-To: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> Date: Mon, 21 Apr 2014 01:41:56 -0400 X-Google-Sender-Auth: 7rqPW21TOeMeRy-X8QFLPc6wSsI Message-ID: From: Mark Baker To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/0F5Yn4Ki0GReHL8lZsUOJ06unek Cc: "urn@ietf.org" , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 05:42:05 -0000 On Sun, Apr 20, 2014 at 11:17 AM, Barry Leiba wrote: > Again, addressing just one point here: > > Graham said this: >> DOIs >> are conceived as names, and have the appropriate management processes >> around them applicable to names. But I have observed that in recent times, >> the preferred form for presenting DOIs to the Web has increasingly been in >> the form "http://dx.doi.org/..." or similar (see also: [1]). I think this >> exemplifies something that MAY be used as both identifier and name. > > Phill said this: >>> A string that *you* might *today* call a "name", might already be a >>> "locator" to somebody who's rigged a private resolution service. Ten years >>> from now, that "name" might be a "locator" to all of us. >> >> Which is exactly what I was saying. >> For example, UPC code for a can of baked beans is a URN. >> But if you go to Amazon you can use it as a locator, albeit mediated >> via UPS rather than TCP/IP. > > I think both of these confuse the issue. Given a name, we can often > turn it into a locator. That's clear, and that's one thing that makes > names useful. But I think we still need to keep in mind that the > names *aren't* locators. If I can always take "urn:doi:xyz-abc", > transform it to "http://dx.doi.org/find/xyz-abc", and get a valid > locator for the thing named, that's great. We are not talking about transformation, and I don't consider it a general solution to any known problem with URIs, at least not as commonly discussed (primarily, a spec defining an equivalence mapping between two URIs). > But it's still the case > that the former is a name and *not* a locator. And if dx.doi.org goes > away at some point, the thing is still named by "urn:doi:xyz-abc", > even though I can no longer use that locator. There's nothing stopping that string from being used as a locator. Even if a transformation based approach were used, all I need is another scheme, say "doi2" that's defined so that all its URIs can be transformed to an http scheme URI at dx.doi.org. Whip up a little Javascript registerProtocolHandler with a one line string transform, and whammo, doi2:xyz-abc is a locator for me. Another configuration to consider - to John Levine's point - is using intercepting proxies (or manually configured ones, for those not on the library network) to, e.g. resolve http://dx.doi.org/xx.yy.zz to some local copy stored at the library. I'm sure there are other possible configurations too, that use a similar level of indirection, perhaps using other mechanisms (DNS?). So let's please forget about this "name" and "locator" stuff since those labels are so context dependent as to be useless in any broadly scoped discussion like this. There are only identifiers. From nobody Mon Apr 21 02:19:33 2014 Return-Path: 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 9F4AE1A0045; Mon, 21 Apr 2014 02:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.637 X-Spam-Level: X-Spam-Status: No, score=0.637 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no 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 n4aXyPmyAW3X; Mon, 21 Apr 2014 02:19:27 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id C8E2D1A0109; Mon, 21 Apr 2014 02:19:26 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id B261E32E4AC; Mon, 21 Apr 2014 18:19:20 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 56e0_bb63_bb28ebb9_8d69_4dc0_9027_b050abbda10f; Mon, 21 Apr 2014 18:19:20 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E6A0EBFBD3; Mon, 21 Apr 2014 18:19:19 +0900 (JST) Message-ID: <5354E28B.9070904@it.aoyama.ac.jp> Date: Mon, 21 Apr 2014 18:19:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Mark Baker , Barry Leiba References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/If1GrL1-IZb_OrZnS_IOSqpljjc Cc: "urn@ietf.org" , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 09:19:30 -0000 On 2014/04/21 14:41, Mark Baker wrote: > On Sun, Apr 20, 2014 at 11:17 AM, Barry Leiba wrote: >> But it's still the case >> that the former is a name and *not* a locator. And if dx.doi.org goes >> away at some point, the thing is still named by "urn:doi:xyz-abc", >> even though I can no longer use that locator. > > There's nothing stopping that string from being used as a locator. > > Even if a transformation based approach were used, all I need is > another scheme, say "doi2" that's defined so that all its URIs can be > transformed to an http scheme URI at dx.doi.org. Whip up a little > Javascript registerProtocolHandler with a one line string transform, > and whammo, doi2:xyz-abc is a locator for me. > > Another configuration to consider - to John Levine's point - is using > intercepting proxies (or manually configured ones, for those not on > the library network) to, e.g. resolve http://dx.doi.org/xx.yy.zz to > some local copy stored at the library. I'm sure there are other > possible configurations too, that use a similar level of indirection, > perhaps using other mechanisms (DNS?). > > So let's please forget about this "name" and "locator" stuff since > those labels are so context dependent as to be useless in any broadly > scoped discussion like this. There are only identifiers. Yes indeed. I occasionally get students making presentations based on outdated (but Japanese) material that makes a sharp name/locator distinction, or get asked by students about the difference between URLs and URNs. I always explain that in the context of a traditional library (i.e. physical books), the distinction is very easy: When you want to borrow/read a book, you don't care which copy you get, because they all look the same, but in order to actually get a copy, you have to know where it is. However, as soon as you move to the Web (or any other electronic system), things start to get blurred. Caching (in CDNs, in proxies, by your browser, in core memory,...) and similar tricks (multiple servers,...) produce lots of copies, but you for most purposes, you don't have to be concerned where they are, that's all handled "under the hood". Even where it's not, it's always easy to make it so (see examples above). That's why library people used to see the name/location distinction as an absolute one, and there are still some applications with a strong tie-in to that model (which is alright by me), but why we should keep our infrastructure flexible to allow different models to coexist. Regards, Martin. From nobody Mon Apr 21 04:37:43 2014 Return-Path: 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 93FFF1A01FA; Mon, 21 Apr 2014 04:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.037 X-Spam-Level: ** X-Spam-Status: No, score=2.037 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272] autolearn=no 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 YYzdfb-YJPt2; Mon, 21 Apr 2014 04:37:40 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id B0C991A01F7; Mon, 21 Apr 2014 04:37:39 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 4B38032E4AC; Mon, 21 Apr 2014 20:37:34 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 56dd_070c_482ecded_259c_4849_a740_2bbcd394960e; Mon, 21 Apr 2014 20:37:34 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 786E8BF4CE; Mon, 21 Apr 2014 20:37:33 +0900 (JST) Message-ID: <535502F1.8080201@it.aoyama.ac.jp> Date: Mon, 21 Apr 2014 20:37:21 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John C Klensin , Phillip Hallam-Baker , Mark Baker References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> In-Reply-To: <7F56813812D9F654C3EF271E@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bDCKKeCmGvp2CTHi8OAc8GUuYts Cc: Julian Reschke , Nico Williams , urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 11:37:41 -0000 On 2014/04/19 21:59, John C Klensin wrote: > --On Friday, April 18, 2014 22:34 -0400 Phillip Hallam-Baker > wrote: > >>> A string that *you* might *today* call a "name", might >>> already be a "locator" to somebody who's rigged a private >>> resolution service. Ten years from now, that "name" might be >>> a "locator" to all of us. >> >> Which is exactly what I was saying. >> >> For example, UPC code for a can of baked beans is a URN. >> >> But if you go to Amazon you can use it as a locator, albeit >> mediated via UPS rather than TCP/IP. > > As Mark Nottingham suggested and I tried to elaborate, this > particular discussion may be interesting (or not), but, in the > current context, isn't worth the energy it takes. Well, no, it's exactly at the very core of the issue. See below for more. > First, a UPC code for a can of beans isn't a URN. If an > identifier for those were documented and registered as an NID, > or if it were treated as part of an identifier sub-space within > the "epc" NID specified in RFC 5134, _that_ would be a URN. Okay up to here. Let's assume that done. > As > a URN, the defining materials would presumably come with a lot > of information about what it was and what operations could be > performed with it. For a URN based on that UPC associated with > a can of beans, those operations might include whether its > purpose is just to distinguish one brand or can-size of beans > from another or whether it can be used to retrieve a product > (see below). No. The URN/UPC just stands for the can of beans. What you can do with it depends on where you use it. Here's where Phil's example comes in very handy. Amazon will provide different operations on that URN than e.g. a service by the registration authority or by a manufacturer who doesn't ship directly to end users. > That set of distinctions is not just pedantry. If "URN" mean > whatever someone claims it means at a given moment, That's not what we are talking about. The identifier still means the same. It's one and the same specific kind of can of beans. > then we > don't have a specific category of identifier, we just have a > very generic term for some variety of identifier. For the > information it contains, one might as well have the above > statement read "UPC code for a can of baked beans is an > Ironduck". > > Even ignoring whether it is a URN or not, a UPC doesn't act as a > UPS-mediated locator, any more than urn:isbn:0-88175-188-X is a > TCP-medidated locator. It is an identifier of an abstraction of > a class of objects. To get the object to your doorstep, it is > typically necessary to resolve it to a different product > abstraction, to a warehouse and location in it, to a > shelf-picking mechanism, and so on, typically through several > step before a particular can-instance is finally chosen, boxed, > labeled, and handed over to UPS (or some other transit carrier > whose choice might be another item in the list of > abstraction-resolutions. Of course. That's what I wrote about in a separate mail. Even for a simple "locator" such as "http://www.ietf.org", there are many very similar (although much less physically visible) steps involved. And as in the case of something like "http://www.ietf.org", the average user on average doesn't want to care much about all these intermediate steps. > In addition, like many URNs (see my notes on the URN list), > there are other useful questions that apply to the > generically-named object and not to the particular can that > might be located. For example, "what is the size of the can > associated with that code" is a question about the generic named > object. "What is the sell-by date" probably still doesn't apply > to a particular can that needs to be located and retrieved > before the question can be answered -- perhaps it is sufficient > to locate a case of cans and to do so in an appropriate database. > > So I suggest they are still different from http-type URLs in > more ways than the [retrieval] method. But, again as Mark > Nottingham pointed out, it may be that the greatest value of > this proposed separation is to get around the situation of > different communities talking past each other and being > unwilling to accept each other's perspective and legitimacy even > to the extent needed to have a real conversation. No, we have had different communities talking past each other in the past, and have surmounted that very well. The problem with any separation is that it eliminates any potential benefit of being able to both URLs and URNs interchangeably where they are interchangeable. Of course they are not always interchangeable. But that's no reason for separation. Regards, Martin. From nobody Mon Apr 21 08:35:52 2014 Return-Path: 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 A7EF71A018F; Mon, 21 Apr 2014 08:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 r_bgs7XxFcE6; Mon, 21 Apr 2014 08:35:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id EB17F1A0004; Mon, 21 Apr 2014 08:35:46 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.921.12; Mon, 21 Apr 2014 15:35:35 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0921.000; Mon, 21 Apr 2014 15:35:35 +0000 From: Larry Masinter To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , "Mark Baker" , Barry Leiba Thread-Topic: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPXULmAT2EmtpMTUSdTNDq2695iZscLcqg Date: Mon, 21 Apr 2014 15:35:34 +0000 Message-ID: <5885b538abd9403e9434699bfff36a8e@BL2PR02MB307.namprd02.prod.outlook.com> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <5354E28B.9070904@it.aoyama.ac.jp> In-Reply-To: <5354E28B.9070904@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.150.10.203] x-forefront-prvs: 0188D66E61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(189002)(199002)(79102001)(76482001)(20776003)(77982001)(15202345003)(99396002)(74662001)(86362001)(74502001)(54356999)(31966008)(50986999)(77096999)(76176999)(76576001)(15975445006)(33646001)(66066001)(46102001)(80022001)(4396001)(99286001)(85852003)(81342001)(19580395003)(83072002)(83322001)(2656002)(92566001)(80976001)(224303002)(87936001)(81542001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:9DBBF138.8C3284DB.70EABE7B.44EBD47C.201A5; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/_pmH2GSOUjLdxmEWwCkUB19aTMM Cc: "urn@ietf.org" , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 15:35:51 -0000 There's a problem with using 'locator' and 'name' as categories for strings= -- strings are strings. Whether a string is a 'locator' or 'name' depends= on how it's used. =20 That the same string can be used as a locator and a name is an important pu= n: XML namespace names use IRIs as names, so that it's primary use is as a= name, but it can also be used as a locator to find more information about = the thing named. More generally, the "semantic web" uses URLs to name thing= s, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-URI-Vocabul= ary -- easy allocation, and allows one to locate information about the thin= g named. URLs can be persistent ('data:', and http://tools.ietf.org/html/draft-masin= ter-dated-uri ) and URNs can be as temporary as the URN namespace authority urn:authority:= authority-name-for-thing. Do not confuse a location optimization used in locating (cache, proxy, web = archive) with the actual meaning. The actual meaning depends on how you wo= uld resolve disputes over meaning.=20 Larry -- http://larry.masinter.net From nobody Tue Apr 22 04:34:35 2014 Return-Path: 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 7C2B01A03A0; Tue, 22 Apr 2014 04:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 3tiuTBCHntTn; Tue, 22 Apr 2014 04:26:28 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) by ietfa.amsl.com (Postfix) with ESMTP id 947611A0079; Tue, 22 Apr 2014 04:26:28 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59958) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1WcYqB-0005My-Yt (Exim 4.82_3-c0e5623) (return-path ); Tue, 22 Apr 2014 12:26:19 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WcYqB-0006tr-P9 (Exim 4.72) (return-path ); Tue, 22 Apr 2014 12:26:19 +0100 Date: Tue, 22 Apr 2014 12:26:19 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: http://mailarchive.ietf.org/arch/msg/urn/P8qgpj52d0ZOOe-gJ2laaW1ZWc8 X-Mailman-Approved-At: Tue, 22 Apr 2014 04:34:32 -0700 Cc: Julian Reschke , urn@ietf.org, General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 11:26:33 -0000 Phillip Hallam-Baker wrote: > On Thu, Apr 17, 2014 at 5:39 PM, Julian Reschke wrote: > > On 2014-04-16 20:58, Phillip Hallam-Baker wrote: > >> > >> The real difference is that a URL must contains a DNS name and a URN > >> probably does not. > >> ... > > > > Not true. It doesn't need to be a DNS name. > > Why bother with anything else? You might want to use an mDNS name, or a TOR .onion name, etc. Tony. -- f.anthony.n.finch http://dotat.at/ West Wight, Portland, Plymouth, North Biscay: Mainly southerly or southwesterly 4 or 5, occasionally 6. Slight or moderate. Occasional rain or showers. Moderate or good, occasionally poor. From nobody Tue Apr 22 07:18:06 2014 Return-Path: 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 66FD21A0484; Tue, 22 Apr 2014 07:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 zETEBRRKcnxH; Tue, 22 Apr 2014 07:17:58 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 212AC1A047C; Tue, 22 Apr 2014 07:17:57 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id p9so4354616lbv.38 for ; Tue, 22 Apr 2014 07:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7QGiZlfQqnucMQbr8KgqOdh96hjtbTM4mBE/Ma75aP0=; b=lTplIhsLlnj8e9rqAgItsYvHVEcvXZeWXHiVZzR7sHdOfr0lKMYvcb2UkTCPLVWlcr w0bv7Mwxny5tDTVthuSsrhIXP3TVSCU2TfVoGiFTIXtm68KccGSuHtoNlUbzOGKJRLts THxpyJpr4NvS8H/fRn19TiZvOlssNmW3zv2viPgoqx0aIj3DG5bkCPIk85MJbWZRJEVa os/z71R1JRVyxXSNqlBkvkStPCw1p1EZJwi+A/eTZ/EQfWUDwG4bRtKWX8r/fkgpJDY4 neZ+uLh9WmgHliYM9dpmFiWQZJdocioz/s/vi6p6RKVga+nKDOEGHbe2rromvYqZyMq/ As9A== MIME-Version: 1.0 X-Received: by 10.152.10.72 with SMTP id g8mr2042824lab.50.1398176271094; Tue, 22 Apr 2014 07:17:51 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 22 Apr 2014 07:17:50 -0700 (PDT) In-Reply-To: References: <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> Date: Tue, 22 Apr 2014 10:17:50 -0400 Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MmCT0XXrZRg_rAeJdmgjfuXXxs4 Cc: "Julian F. Reschke" , Mark Nottingham , urn@ietf.org, Graham Klyne , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 14:18:04 -0000 On Fri, Apr 18, 2014 at 3:53 PM, John C Klensin wrote: > > > --On Friday, April 18, 2014 11:44 +1000 Mark Nottingham > 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/ From nobody Wed Apr 23 03:05:21 2014 Return-Path: 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 860CB1A0191; Wed, 23 Apr 2014 03:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.615 X-Spam-Level: ** X-Spam-Status: No, score=2.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RDNS_DYNAMIC=0.982] autolearn=no 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 0Pv2wVcERpFg; Wed, 23 Apr 2014 03:05:14 -0700 (PDT) Received: from remote.rinascimento-digitale.it (93-63-166-139.ip28.fastwebnet.it [93.63.166.139]) by ietfa.amsl.com (Postfix) with ESMTP id 33B911A019B; Wed, 23 Apr 2014 03:05:13 -0700 (PDT) Received: from FRD01.frd.local ([fe80::30bc:ca96:e16f:8923]) by FRD01.frd.local ([fe80::30bc:ca96:e16f:8923%10]) with mapi id 14.03.0174.001; Wed, 23 Apr 2014 12:04:56 +0200 From: Maurizio Lunghi To: Phillip Hallam-Baker Thread-Topic: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPXjWvNZcweYtOikiEcFO5n/xexZse+omz Date: Wed, 23 Apr 2014 10:04:55 +0000 Message-ID: <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it> References: <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> , In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.5.0.1057-7.500.1017-20650.005 x-tm-as-result: No--42.276200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UDtfi83hf9S4BVd927NvZPMJ4Gk Cc: General discussion of application-layer protocols , "Julian F. Reschke" , Graham Klyne , Mark Nottingham , "urn@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 10:05:17 -0000 I am wondering if it is useful and maybe necessary to define what a 'persis= tent identifier' is .... as many of you said technology is mot persistent p= er se but policy underpinning the system can make persistent the identifier= s and the service linked to them .... in the APARSEN project www.aparsen.eu= in WP 22 we reached agreement with many experts about a list of criteria t= hat a 'trusted persistent identifier system' must have and we could start f= rom this work to define a broader consensus .... doing so in my view we co= uld clearly distinguish between a URN or URI and a PI ... does it sound rea= sonable? thanks Maurizio Lunghi > On 22 Apr 2014, at 16:18, "Phillip Hallam-Baker" wrote= : >=20 >> On Fri, Apr 18, 2014 at 3:53 PM, John C Klensin wrot= e: >>=20 >>=20 >> --On Friday, April 18, 2014 11:44 +1000 Mark Nottingham >> wrote: >>=20 >>> I have to say that I'm sympathetic to the proposed outcomes, >>> albeit for different reasons, perhaps. >>>=20 >>> 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. >>=20 >> Mark, >>=20 >> 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. >=20 > I think the disagreement is over what counts as an example. >=20 > 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. >=20 > 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. >=20 >=20 >> 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: >=20 > Well either a URN is a distinct class from a URL or it isn't. >=20 > 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) >=20 > 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. >=20 >=20 >> (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. >=20 > I am not sure what the above means. I can't parse it. >=20 > 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. >=20 > 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. >=20 >=20 >> (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. >=20 > 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. >=20 > The only URI that is guaranteed to resolve to the signified content > unconditionally is the DATA method. >=20 > 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'. >=20 > Its not the syntax of a naming infrastructure that gives it longevity, > it is the political and business context in which it operates. >=20 >=20 >> 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). >=20 > I don't think it was one side of the argument guilty of that. >=20 > 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 >=20 > 1) The particular set of requirements can be met >=20 > 2) The distinction insisted on helps meet them >=20 >=20 >> 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). >=20 > Yep >=20 >=20 >> 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. >=20 > 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'. >=20 > --=20 > Website: http://hallambaker.com/ >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn >=20 From nobody Wed Apr 23 06:51:28 2014 Return-Path: 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 B44BB1A03A8; Wed, 23 Apr 2014 06:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 r90TdV0EGXj3; Wed, 23 Apr 2014 06:51:23 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 567FE1A03A7; Wed, 23 Apr 2014 06:51:23 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so808432lbd.1 for ; Wed, 23 Apr 2014 06:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BwNt7vLT8cfyUG3OvOLIHqJDm9nl6w+goMCj161KPm4=; b=N3JUJvNzTPQVikTVj/37Uc8b4YtZsCcOczkrpqDq+E40CgwPN8ARJK/E1o34ORGqCd lqe5ZLOiSqFsw+xHuE6S3Hy90UsjwWbv34yGLdnfHrXA32z7GiUKQcVcb+VLF/N6QjYK TJJgYTJPdRa5nmPDsX14u6kpFxklErFZ6fijNBC4fkm3DVhc8lORVNhFN/Hcf9vcP6QR adY0Wa1f5uagGUlAED/boeUxE4H5XYbv6Z+cpnKg/VDHxEXowsJDP7xPk3lp+MkwFZje j8yjmzLmcSZ73DRzjynAh7jAgrfAxSlcXBuAhczYplmavb6FVP8wE8YMBhDFLbVAknx2 z79Q== MIME-Version: 1.0 X-Received: by 10.152.43.107 with SMTP id v11mr1356070lal.49.1398261077024; Wed, 23 Apr 2014 06:51:17 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Wed, 23 Apr 2014 06:51:16 -0700 (PDT) In-Reply-To: <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it> References: <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> <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it> Date: Wed, 23 Apr 2014 09:51:16 -0400 Message-ID: From: Phillip Hallam-Baker To: Maurizio Lunghi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/urn/8RYOq7oYFlPI5gY_3v6x_QdUFJo Cc: General discussion of application-layer protocols , "Julian F. Reschke" , Graham Klyne , Mark Nottingham , "urn@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 13:51:25 -0000 On Wed, Apr 23, 2014 at 6:04 AM, Maurizio Lunghi wrote: > I am wondering if it is useful and maybe necessary to define what a 'pers= istent identifier' is .... as many of you said technology is mot persistent= per se but policy underpinning the system can make persistent the identifi= ers and the service linked to them .... in the APARSEN project www.aparsen.= eu in WP 22 we reached agreement with many experts about a list of criteria= that a 'trusted persistent identifier system' must have and we could start= from this work to define a broader consensus .... doing so in my view we = could clearly distinguish between a URN or URI and a PI ... does it sound r= easonable? > People have been compiling wish lists for properties of names for 20+ years. The issue is not what people would want, it is what they can get. I can't take the 'urn' approach seriously until someone provides an explanation of 1) How the persistence properties are to be achieved 2) Why a taxonomic distinction between URLs and URNs helps achieve the persistence properties. A name is by definition a signifier that bears only a conventional relationship to the thing signified. In the case of DNS that relationship is mediated by the DNS infrastructure. There are only two ways to make an identifier persistent. The first being to use an index rather than a name. SHA256(c) is a persistent identifier for the content c. Which is what we use in the ni: scheme. The second is to have a first come, first served registry that never revokes previous assignments. Now one could imagine a whole new infrastructure for establishing such a scheme. But really, wouldn't anyone setting up such a scheme apply for a TLD? So now imagine we have .pid which is a first come, first served registry that never revokes an assignment or alternatively requires the date to be inserted into the HTTP URIs. I can give you a HTTP method identifier which is persistent using such an infrastructure. Now we can argue over whether the proposal I make is actually practical. But I think it is at least as practical as all the 'persistent identifier' schemes based on a new registry. The bottom line is that persistence is a qualified property of a naming infrastructure, not a syntactic distinction. If people want to argue further, I want them to put up and show HOW their persistence scheme actually works. No more wish lists or requirements for identifiers. I want to see how the scheme works at a technical and political level to achieve the persistence requirements. --=20 Website: http://hallambaker.com/ From nobody Thu Apr 24 01:25:48 2014 Return-Path: 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 238F91A0564; Thu, 24 Apr 2014 01:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.615 X-Spam-Level: ** X-Spam-Status: No, score=2.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RDNS_DYNAMIC=0.982] autolearn=no 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 AFm9Bc59XoKo; Thu, 24 Apr 2014 01:25:44 -0700 (PDT) Received: from remote.rinascimento-digitale.it (93-63-166-139.ip28.fastwebnet.it [93.63.166.139]) by ietfa.amsl.com (Postfix) with ESMTP id 952241A03A8; Thu, 24 Apr 2014 01:25:43 -0700 (PDT) Received: from FRD01.frd.local ([fe80::30bc:ca96:e16f:8923]) by FRD01.frd.local ([fe80::30bc:ca96:e16f:8923%10]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 10:25:31 +0200 From: Maurizio Lunghi To: Phillip Hallam-Baker Thread-Topic: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPXvsdozmNQKT390aYaUTyYZpG/ZsgVovA Date: Thu, 24 Apr 2014 08:25:30 +0000 Message-ID: References: <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> <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.103] x-tm-as-product-ver: SMEX-10.5.0.1057-7.500.1017-20652.005 x-tm-as-result: No--29.511200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/qLT-vGVibgMIwhJuHxpqfLURqGU Cc: General discussion of application-layer protocols , "Julian F. Reschke" , Graham Klyne , Mark Nottingham , "urn@ietf.org" Subject: [urn] R: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 08:25:46 -0000 TWF5YmUgSSB3YXMgbm90IGNsZWFyLCBidXQgYSB3aXNoIGxpc3QgaXMgdG8gdGhpbmsgdGhhdCB5 b3VyIHRlY2huaWNhbCBzb2x1dGlvbnMgY2FuIGJlIGNvbnNpZGVyZWQgJ1BlcnNpc3RlbnQgSWRl bnRpZmllcnMnDQpGaXJzdCwgaW4gdGhlIGRpZ2l0YWwgcHJlc2VydmF0aW9uIGFyZW5hIHdlIGNv bnNpZGVyIHRoYXQgcG9saWN5IGFyZSBtb3JlIGltcG9ydGFudCB0aGFuIHRlY2hub2xvZ3kgYWN0 dWFsbHksIGFsbCB0aGUgZGlnaXRhbCBwcmVzZXJ2YXRpb24gYXBwbGljYXRpb25zIGhhdmUgYSBz dHJvbmcgYW5kIHdlbGwgZGVmaW5lZCBwb2xpY3kgaW4gc3VwcG9ydCBvZiB0aGVpciBnb2Fscywg dGVjaG5vbG9neSB3aWxsIGJlIG1pZ3JhdGVkIGluIHRoZSB5ZWFycy4gQXMgeW91IHNhaWQsIGFu eSB0ZWNobm9sb2d5IGNhbiBiZWNvbWUgYSBQSSBpZiBzdXBwb3J0ZWQgYnkgYW4gYXBwcm9wcmlh dGUgcG9saWN5IGFuZCBhcHBsaWNhdGlvbi4NClNlY29uZCwgaW4gb3VyIHJlY2VudCB3b3JrIHdl IGFncmVlZCBvbiB0aGF0IGEgUEkgaXMgbm90IG9ubHkgYSBudW1iZXIgb3Igc3RyaW5nLCBhIFBJ IGlzIGEgc2VydmljZSB3aGVyZSB0byB0aGF0IGNvZGUgYW4gaW5mb3JtYXRpb24gc2VydmljZSBp cyBncmFudGVkIGJ5IGEgdHJ1c3RlZCBhZ2VuY3kgd2l0aCBhIGRlZmluZWQgbWFuZGF0ZSBpbiB0 aW1lIGFuZCBmb3IgYSBzcGVjaWZpYyB1c2VyIGNvbW11bml0eSwgdGhpcyBpcyB0aGVuIGNhc2Ug Zm9yIGFsbCB0aGUgbW9zdCByZWxldmFudCBQSSBzeXN0ZW1zIGxpa2UgRE9JLCBIYW5kbGUsIEFS SywgTkJOLCBhbmQgZm9yIHRoZSBlbWVyZ2luZyBQSSBzeXN0ZW1zIGZvciBwZW9wbGUgYWxzby4g SW4gb3VyIHdvcmsgYSBQSSBzeXN0ZW0gaXMgY29tcG9zZWQgYnkgYSByZWxpYWJsZSB0ZWNobm9s b2d5LCBhIHRydXN0ZWQgYm9keSBvZmZlcmluZyB0aGUgc2VydmljZSwgYSBwb2xpY3kgYW5kIG1h bmRhdGUgYnkgdGhlIHVzZXIgY29tbXVuaXR5Lg0KVGhhdCdzIHdoeSBJIGhhdmUgdGhlIGltcHJl c3Npb24gdGhhdCB3ZSBzaG91bGQgZGVmaW5lIGNyaXRlcmlhIGZvciBhIHRydXN0ZWQgUEkgc3lz dGVtIGluIGFub3RoZXIgZG9jdW1lbnQsIGFzIHdlIGhhdmUgZG9uZSBhYm91dCB0aGUgdHJ1c3Rl ZCBkaWdpdGFsIHJlcG9zaXRvcmllcyBpc3N1ZSB3aXRoIFJMRywgT0NMQywgVFJBQywgT0FJUywg SVNPMTYzNjMgLi4uLg0KDQp0aGFua3MNCg0KTWF1cml6aW8gTHVuZ2hpDQpkaXJldHRvcmUgc2Np ZW50aWZpY28NCkZvbmRhemlvbmUgUmluYXNjaW1lbnRvIERpZ2l0YWxlDQpsdW5naGlAcmluYXNj aW1lbnRvLWRpZ2l0YWxlLml0wqAgDQorMzkzMzUxMzk2MzcxDQoNCi0tLS0tTWVzc2FnZ2lvIG9y aWdpbmFsZS0tLS0tDQpEYTogUGhpbGxpcCBIYWxsYW0tQmFrZXIgW21haWx0bzpoYWxsYW1AZ21h aWwuY29tXSANCkludmlhdG86IG1lcmNvbGVkw6wgMjMgYXByaWxlIDIwMTQgMTU6NTENCkE6IE1h dXJpemlvIEx1bmdoaQ0KQ2M6IEpvaG4gQyBLbGVuc2luOyBKdWxpYW4gRi4gUmVzY2hrZTsgTWFy ayBOb3R0aW5naGFtOyB1cm5AaWV0Zi5vcmc7IEdyYWhhbSBLbHluZTsgR2VuZXJhbCBkaXNjdXNz aW9uIG9mIGFwcGxpY2F0aW9uLWxheWVyIHByb3RvY29scw0KT2dnZXR0bzogUmU6IFt1cm5dIFth cHBzLWRpc2N1c3NdIFVSTnMgYXJlIG5vdCBVUklzIChhbm90aGVyIGxvb2sgYXQgUkZDIDM5ODYp DQoNCk9uIFdlZCwgQXByIDIzLCAyMDE0IGF0IDY6MDQgQU0sIE1hdXJpemlvIEx1bmdoaSA8THVu Z2hpQHJpbmFzY2ltZW50by1kaWdpdGFsZS5pdD4gd3JvdGU6DQo+IEkgYW0gd29uZGVyaW5nIGlm IGl0IGlzIHVzZWZ1bCBhbmQgbWF5YmUgbmVjZXNzYXJ5IHRvIGRlZmluZSB3aGF0IGEgJ3BlcnNp c3RlbnQgaWRlbnRpZmllcicgaXMgLi4uLiBhcyBtYW55IG9mIHlvdSBzYWlkIHRlY2hub2xvZ3kg aXMgbW90IHBlcnNpc3RlbnQgcGVyIHNlIGJ1dCBwb2xpY3kgdW5kZXJwaW5uaW5nIHRoZSBzeXN0 ZW0gY2FuIG1ha2UgcGVyc2lzdGVudCB0aGUgaWRlbnRpZmllcnMgYW5kIHRoZSBzZXJ2aWNlIGxp bmtlZCB0byB0aGVtIC4uLi4gaW4gdGhlIEFQQVJTRU4gcHJvamVjdCB3d3cuYXBhcnNlbi5ldSBp biBXUCAyMiB3ZSByZWFjaGVkIGFncmVlbWVudCB3aXRoIG1hbnkgZXhwZXJ0cyBhYm91dCBhIGxp c3Qgb2YgY3JpdGVyaWEgdGhhdCBhICd0cnVzdGVkIHBlcnNpc3RlbnQgaWRlbnRpZmllciBzeXN0 ZW0nIG11c3QgaGF2ZSBhbmQgd2UgY291bGQgc3RhcnQgZnJvbSB0aGlzIHdvcmsgdG8gZGVmaW5l IGEgYnJvYWRlciBjb25zZW5zdXMgLi4uLiBkb2luZyBzbyBpbiBteSB2aWV3IHdlICBjb3VsZCBj bGVhcmx5IGRpc3Rpbmd1aXNoIGJldHdlZW4gYSBVUk4gb3IgVVJJIGFuZCBhIFBJIC4uLiBkb2Vz IGl0IHNvdW5kIHJlYXNvbmFibGU/DQo+DQoNClBlb3BsZSBoYXZlIGJlZW4gY29tcGlsaW5nIHdp c2ggbGlzdHMgZm9yIHByb3BlcnRpZXMgb2YgbmFtZXMgZm9yIDIwKyB5ZWFycy4gVGhlIGlzc3Vl IGlzIG5vdCB3aGF0IHBlb3BsZSB3b3VsZCB3YW50LCBpdCBpcyB3aGF0IHRoZXkgY2FuIGdldC4N Cg0KSSBjYW4ndCB0YWtlIHRoZSAndXJuJyBhcHByb2FjaCBzZXJpb3VzbHkgdW50aWwgc29tZW9u ZSBwcm92aWRlcyBhbiBleHBsYW5hdGlvbiBvZg0KDQoxKSBIb3cgdGhlIHBlcnNpc3RlbmNlIHBy b3BlcnRpZXMgYXJlIHRvIGJlIGFjaGlldmVkDQoNCjIpIFdoeSBhIHRheG9ub21pYyBkaXN0aW5j dGlvbiBiZXR3ZWVuIFVSTHMgYW5kIFVSTnMgaGVscHMgYWNoaWV2ZSB0aGUgcGVyc2lzdGVuY2Ug cHJvcGVydGllcy4NCg0KDQpBIG5hbWUgaXMgYnkgZGVmaW5pdGlvbiBhIHNpZ25pZmllciB0aGF0 IGJlYXJzIG9ubHkgYSBjb252ZW50aW9uYWwgcmVsYXRpb25zaGlwIHRvIHRoZSB0aGluZyBzaWdu aWZpZWQuIEluIHRoZSBjYXNlIG9mIEROUyB0aGF0IHJlbGF0aW9uc2hpcCBpcyBtZWRpYXRlZCBi eSB0aGUgRE5TIGluZnJhc3RydWN0dXJlLg0KDQpUaGVyZSBhcmUgb25seSB0d28gd2F5cyB0byBt YWtlIGFuIGlkZW50aWZpZXIgcGVyc2lzdGVudC4gVGhlIGZpcnN0IGJlaW5nIHRvIHVzZSBhbiBp bmRleCByYXRoZXIgdGhhbiBhIG5hbWUuIFNIQTI1NihjKSBpcyBhIHBlcnNpc3RlbnQgaWRlbnRp ZmllciBmb3IgdGhlIGNvbnRlbnQgYy4gV2hpY2ggaXMgd2hhdCB3ZSB1c2UgaW4gdGhlIG5pOiBz Y2hlbWUuDQoNClRoZSBzZWNvbmQgaXMgdG8gaGF2ZSBhIGZpcnN0IGNvbWUsIGZpcnN0IHNlcnZl ZCByZWdpc3RyeSB0aGF0IG5ldmVyIHJldm9rZXMgcHJldmlvdXMgYXNzaWdubWVudHMuIE5vdyBv bmUgY291bGQgaW1hZ2luZSBhIHdob2xlIG5ldyBpbmZyYXN0cnVjdHVyZSBmb3IgZXN0YWJsaXNo aW5nIHN1Y2ggYSBzY2hlbWUuIEJ1dCByZWFsbHksIHdvdWxkbid0IGFueW9uZSBzZXR0aW5nIHVw IHN1Y2ggYSBzY2hlbWUgYXBwbHkgZm9yIGEgVExEPw0KDQpTbyBub3cgaW1hZ2luZSB3ZSBoYXZl IC5waWQgd2hpY2ggaXMgYSBmaXJzdCBjb21lLCBmaXJzdCBzZXJ2ZWQgcmVnaXN0cnkgdGhhdCBu ZXZlciByZXZva2VzIGFuIGFzc2lnbm1lbnQgb3IgYWx0ZXJuYXRpdmVseSByZXF1aXJlcyB0aGUg ZGF0ZSB0byBiZSBpbnNlcnRlZCBpbnRvIHRoZSBIVFRQIFVSSXMuDQoNCkkgY2FuIGdpdmUgeW91 IGEgSFRUUCBtZXRob2QgaWRlbnRpZmllciB3aGljaCBpcyBwZXJzaXN0ZW50IHVzaW5nIHN1Y2gg YW4gaW5mcmFzdHJ1Y3R1cmUuDQoNCk5vdyB3ZSBjYW4gYXJndWUgb3ZlciB3aGV0aGVyIHRoZSBw cm9wb3NhbCBJIG1ha2UgaXMgYWN0dWFsbHkgcHJhY3RpY2FsLiBCdXQgSSB0aGluayBpdCBpcyBh dCBsZWFzdCBhcyBwcmFjdGljYWwgYXMgYWxsIHRoZSAncGVyc2lzdGVudCBpZGVudGlmaWVyJyBz Y2hlbWVzIGJhc2VkIG9uIGEgbmV3IHJlZ2lzdHJ5Lg0KDQoNClRoZSBib3R0b20gbGluZSBpcyB0 aGF0IHBlcnNpc3RlbmNlIGlzIGEgcXVhbGlmaWVkIHByb3BlcnR5IG9mIGEgbmFtaW5nIGluZnJh c3RydWN0dXJlLCBub3QgYSBzeW50YWN0aWMgZGlzdGluY3Rpb24uDQoNCklmIHBlb3BsZSB3YW50 IHRvIGFyZ3VlIGZ1cnRoZXIsIEkgd2FudCB0aGVtIHRvIHB1dCB1cCBhbmQgc2hvdyBIT1cgdGhl aXIgcGVyc2lzdGVuY2Ugc2NoZW1lIGFjdHVhbGx5IHdvcmtzLiBObyBtb3JlIHdpc2ggbGlzdHMg b3IgcmVxdWlyZW1lbnRzIGZvciBpZGVudGlmaWVycy4gSSB3YW50IHRvIHNlZSBob3cgdGhlIHNj aGVtZSB3b3JrcyBhdCBhIHRlY2huaWNhbCBhbmQgcG9saXRpY2FsIGxldmVsIHRvIGFjaGlldmUg dGhlIHBlcnNpc3RlbmNlIHJlcXVpcmVtZW50cy4NCg0KDQoNCi0tDQpXZWJzaXRlOiBodHRwOi8v aGFsbGFtYmFrZXIuY29tLw0KDQo= From nobody Thu Apr 24 11:59:31 2014 Return-Path: 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 C3D961A03AB; Thu, 24 Apr 2014 11:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 5vWOd8CnIBRm; Thu, 24 Apr 2014 11:59:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) by ietfa.amsl.com (Postfix) with ESMTP id CF52E1A01DB; Thu, 24 Apr 2014 11:59:22 -0700 (PDT) Received: from BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) by BL2PR02MB402.namprd02.prod.outlook.com (10.141.93.144) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 24 Apr 2014 18:59:16 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.921.12; Thu, 24 Apr 2014 18:59:15 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0921.000; Thu, 24 Apr 2014 18:59:14 +0000 From: Larry Masinter To: Tony Finch , Phillip Hallam-Baker Thread-Topic: [apps-discuss] [urn] URNs are not URIs (another look at RFC 3986) Thread-Index: AQHPWlgDFf0xwOibhUWZI6bprNyAHZsdhqyAgAOiAzA= Date: Thu, 24 Apr 2014 18:59:14 +0000 Message-ID: References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(199002)(189002)(31966008)(80976001)(76176999)(46102001)(4396001)(66066001)(86362001)(74316001)(99396002)(92566001)(76482001)(80022001)(77096999)(54356999)(74502001)(81342001)(50986999)(87936001)(83072002)(77982001)(83322001)(558084003)(81542001)(79102001)(20776003)(33646001)(74662001)(85852003)(2656002)(99286001)(224303002)(76576001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:CB217A5C.94B21466.79D14E97.D4D7ACEC.2006E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: adobe.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UUI3X7gGYNIz7Xxd0-FVt9G3GEg Cc: "julian.reschke@gmx.de" , "urn@ietf.org" , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:59:28 -0000 "data:" URLs don't have DNS names and aren't URNs. "mailto:" URLs have domain names, but not in the //.../ authority field "duri:" and "tdb:" URLs are 'permanent', but are arguably not URNs.=20 From nobody Fri Apr 25 01:45:24 2014 Return-Path: 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 A91371A00DA; Fri, 25 Apr 2014 01:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] 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 BZdVEjh-wGVs; Fri, 25 Apr 2014 01:45:18 -0700 (PDT) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE1B1A00D1; Fri, 25 Apr 2014 01:45:18 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 134A37B866; Fri, 25 Apr 2014 04:45:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=sasl; bh= 7gV7s6AQ7M6N390VljvMywD8ub0=; b=j9fYJmPEnQCRJOhqZCN0rXi9/PnRLTVt 0NRxXZBh4vqT+6d2CHuUHj/dsOMsgfil/rUNuc9KUWFHjwsChta5iQm7pt+t68lJ Ej+LQCsvFvI4rnUTujMEJOD7qlPBWHmXEjO81VzfqR1/SRaUHYhF+HM254lnTBZd qpvFRcDPEfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= sasl; b=jZhZxQwx/udwKi65NO33bhEIsstK0AYDfAu74vVZGCUN9WCOaY5UhLra P/jtP9fNPfG6MAgWENxTD+x2e7k6GWEO9GrREZ/0EpphUwTU6dOeYHJ7WfIJlIhr ulJVWq3v0FUJqDUiV1Qar05Vqc2iKAQ68hKRaEMT/HpXyueEbZM= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id ED8F87B864; Fri, 25 Apr 2014 04:45:10 -0400 (EDT) Received: from [128.164.100.42] (unknown [128.164.100.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 9D15C7B860; Fri, 25 Apr 2014 04:45:07 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Edward Summers In-Reply-To: <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> Date: Fri, 25 Apr 2014 04:45:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <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> To: Mark Nottingham X-Mailer: Apple Mail (2.1874) X-Pobox-Relay-ID: E7C6B8F0-CC55-11E3-8788-0731802839F8-07615111!b-pb-sasl-quonix.pobox.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UQkDdPs61sER6osE9So4XZThMSY Cc: "Julian F. Reschke" , urn@ietf.org, Graham Klyne , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 08:45:20 -0000 On Apr 17, 2014, at 9:44 PM, Mark Nottingham wrote: > I have to say that I'm sympathetic to the proposed outcomes, albeit = for different reasons, perhaps. >=20 > 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.=20 >=20 > 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=92s 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. The proposed changes to URN seem largely centered on the needs of memory = organizations, who are a third community at play here. I am worried that = the current draft makes this community seem monolithic in its approach = to persistent identifiers and URIs. The current definition of URN as URI = has not prevented useful work on persistent identifiers] by memory = institutions, notably ARK [1], Memento [2], OpenURL [3], info-uri [4], = ISBN [5] and Version Navigation [6] and Dublin Core [7]. I see Larry=92s = work on things like duri as other examples of useful work that can be = done without changing the relationship of URN to URI. I have personally found the work that has gone into Web architecture, in = particular Fielding=92s work on REST, has been extremely useful in = designing digital preservation systems at the Library of Congress. = Taking the Web seriously has lots of real benefits when it comes to = application development and sustainability since there is a great = diversity in software implementations and maturity with regards to = scalability. I=92m not saying there aren=92t challenges, but if memory = institutions want to continue in their societal role, they must learn to = work with the grain of the Web, not against it. I=92m thinking of the = excellent work that organizations like the Internet Archive have = started. So, as it stands, I think the current draft [8] is too simplistic in its = approach, and actually does a fair bit of damage to people in the field. = If you would prefer to have specific comments I can try to do that but I = am having trouble decoding the politics at play here. //Ed [1] http://tools.ietf.org/id/draft-kunze-ark [2] https://www.ietf.org/rfc/rfc7089.txt [3] https://en.wikipedia.org/wiki/OpenURL [4] https://www.ietf.org/rfc/rfc4452.txt [5] https://www.ietf.org/rfc/rfc3187.txt [6] https://www.ietf.org/rfc/rfc5829.txt [7] http://dublincore.org/documents/dces/ [8] https://tools.ietf.org/id/draft-ietf-urnbis-urns-are-not-uris= From nobody Fri Apr 25 08:28:25 2014 Return-Path: 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 1C0861A03B3; Fri, 25 Apr 2014 08:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5] 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 GBWa02Y9iIdT; Fri, 25 Apr 2014 08:28:16 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7541A05C3; Fri, 25 Apr 2014 08:28:12 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 85E7F7F396; Fri, 25 Apr 2014 17:28:04 +0200 (CEST) From: "Svensson, Lars" To: Phillip Hallam-Baker , Maurizio Lunghi Thread-Topic: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC3986) Thread-Index: Ac9gmucSIPXRPGL+TPO6HkD1WoDOXg== Date: Fri, 25 Apr 2014 15:28:03 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA43FE069@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.192] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MnQgI0G21jf7Zj3p9Q4Gn37U81s Cc: "Julian F. Reschke" , Mark Nottingham , "urn@ietf.org" , Graham Klyne , General discussion of application-layer protocols Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC3986) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:28:21 -0000 All, I'll enter the discussion here, commenting on Phillip's mail and add some t= houghts of mine that relate to what others have said earlier. Phillip said in answer to Maurizio:=20 > > I am wondering if it is useful and maybe necessary to define what a >> 'persistent identifier' is .... as many of you said technology is mot pe= rsistent >> per se but policy underpinning the system can make persistent the >> identifiers and the service linked to them .... in the APARSEN project >> www.aparsen.eu in WP 22 we reached agreement with many experts about >> a list of criteria that a 'trusted persistent identifier system' must ha= ve and we >> could start from this work to define a broader consensus .... doing so i= n my >> view we could clearly distinguish between a URN or URI and a PI ... doe= s it >> sound reasonable? > > >=20 > People have been compiling wish lists for properties of names for 20+ > years. The issue is not what people would want, it is what they can > get. >=20 > I can't take the 'urn' approach seriously until someone provides an > explanation of >=20 > 1) How the persistence properties are to be achieved It is clear that persistence is not a quality of the identifier syntax but = there need to be other things in place, too. What I have understood from th= e discussion is that people in different communities seem to have a differe= nt understanding of what 'persistent' in 'persistent identifier' is suppose= d to mean and IMO we need to agree on that before we can move forward. My d= efinition is that a persistent identifier is a string that uniquely identif= ies an object in such a way that there are procedures in place that guarant= ee that once a specific string has been attached to a specific resource (in= the widest sense), that string can never be used to identify any other res= ource. Period. It does not mean that there persistently (=3Dalways) will be= a resolution service in place that can resolve a persistent identifier to = a resource. Technically, I can have a persistent identifier for a resource = even if there is no resolution service available, but of course it is bette= r if there is some documentation on which identifier is tied to which resou= rce. A database with PIs and locators/metadata and a resolver on top of it = is *one* way to document that, but I could just as well print 500 copies of= a catalogue with identifier/metadata pairs and put those in 500 libraries = worldwide and let people look it up there (Kudos to Esa-Pekka Keskitalo for= this nice example). As an aside, this is why I keep arguing that urn synta= x and urn resolution belong together but still have to be considered separa= tely. I think that this is similar to what Barry said although I might be biased: [[ I think both of these confuse the issue. Given a name, we can often turn it into a locator. That's clear, and that's one thing that makes names useful. But I think we still need to keep in mind that the names *aren't* locators. If I can always take "urn:doi:xyz-abc", transform it to "http://dx.doi.org/find/xyz-abc", and get a valid locator for the thing named, that's great. But it's still the case that the former is a name and *not* a locator. And if dx.doi.org goes away at some point, the thing is still named by "urn:doi:xyz-abc", even though I can no longer use that locator. ]] RFC 2141bis states that urn assignment is a managed process. That is how th= e persistent the connection between identifier and resource is achieved. > 2) Why a taxonomic distinction between URLs and URNs helps achieve the > persistence properties. When someone loses a DNS lease (for whatever reason), there is no guarantee= that previously named resources under that DNS name will be available any = more. With urn:s (the RFC 2141 kind), the administration of a NID is delega= ted to an organisation through a managed process including public review. = This means that the responsibility and administration of e. g. urn:nbn:fi c= annot suddenly move from the National Library of Finland to e. g. the Swedi= sh Financial Supervisory Authority (Finansinspektionen (FI), http://www.fi.= se), who happens to use the abbreviation "fi" as well. >=20 > A name is by definition a signifier that bears only a conventional > relationship to the thing signified. In the case of DNS that > relationship is mediated by the DNS infrastructure. And the DNS infrastructure can and does transfer the responsibility for the= domain names between organisations. > There are only two ways to make an identifier persistent. The first > being to use an index rather than a name. SHA256(c) is a persistent > identifier for the content c. Which is what we use in the ni: scheme. >=20 > The second is to have a first come, first served registry that never > revokes previous assignments. Yes, and that is what urn NIDs are about. You register a NID and the IETF p= rocess ensures that no-one else can be assigned that NID. The resolution mi= ght be dependent on the DNS, but the naming need not be. > Now one could imagine a whole new > infrastructure for establishing such a scheme. But really, wouldn't > anyone setting up such a scheme apply for a TLD? >=20 > So now imagine we have .pid which is a first come, first served > registry that never revokes an assignment or alternatively requires > the date to be inserted into the HTTP URIs. >=20 > I can give you a HTTP method identifier which is persistent using such > an infrastructure. >=20 > Now we can argue over whether the proposal I make is actually > practical. But I think it is at least as practical as all the > 'persistent identifier' schemes based on a new registry. >=20 >=20 > The bottom line is that persistence is a qualified property of a > naming infrastructure, not a syntactic distinction. Yes, those are the so called PI Systems Maurizio talks about. =20 > If people want to argue further, I want them to put up and show HOW > their persistence scheme actually works. No more wish lists or > requirements for identifiers. I want to see how the scheme works at a > technical and political level to achieve the persistence requirements. Quoting Maurizio: [[ First, in the digital preservation arena we consider that policy are more i= mportant than technology actually, all the digital preservation application= s have a strong and well defined policy in support of their goals, technolo= gy will be migrated in the years. As you said, any technology can become a = PI if supported by an appropriate policy and application. Second, in our recent work we agreed on that a PI is not only a number or s= tring, a PI is a service where to that code an information service is grant= ed by a trusted agency with a defined mandate in time and for a specific us= er community, this is then case for all the most relevant PI systems like D= OI, Handle, ARK, NBN, and for the emerging PI systems for people also. In o= ur work a PI system is composed by a reliable technology, a trusted body of= fering the service, a policy and mandate by the user community. ]] I can only agree with that. Persistence of persistent identifiers (the way = I understand them) has nothing to do with technology but is a matter of pol= icy and of institutions fulfilling their responsibilities. The identifier a= s such is only part of a larger ecosystem (the PI System). The German DIN 3= 1646 defines a PI System as a combination of Policies, PI registration, Res= olvers and Data Sources, and this is very similar to Maurizio's definition = above. A last comment on the URN vs. URI question: I see nothing so far that preve= nts URNs (the RFC 2141 kind) to be URIs. One of the issues coming up every = now and then is the question if we should allow queries or not. I think we = can, but have to differentiate between queries in urn:s and queries targeti= ng resolution services (which is another argument why we need to keep those= two separate). Queries targeted at resolution services can be used to spec= ify if I want the identified resource, metadata about the resource or metad= ata about the identifier (who registered it, etc.). Queries in the urn are = specific to the identified resource. As an example: if I have urn:example:g= oogle-query and that resolves to https://www.google.com/search?, then urn:e= xample:google-query?q=3Drfc%202141 would resolve to https://www.google.com/= search?q=3Drfc%202141. So there is a difference in functionality. Best, Lars From nobody Fri Apr 25 10:51:29 2014 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 To: Edward Summers , Mark Nottingham Message-ID: <11B3A42537CE2D687E206A34@JcK-HP8200.jck.com> In-Reply-To: References: <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/zVz8DaL-p7cL_TC4pAmnqYZ1OFM Cc: "Julian F. Reschke" , urn@ietf.org, Graham Klyne 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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:" 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. From nobody Fri Apr 25 13:41:50 2014 Return-Path: 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 56EFC1A03DF for ; Fri, 25 Apr 2014 13:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FRT_ADOBE2=2.455] autolearn=no 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 gwSg0g1G_-la for ; Fri, 25 Apr 2014 13:41:46 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4B41A0354 for ; Fri, 25 Apr 2014 13:41:46 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id uLW71n0041ZXKqc59Lhf00; Fri, 25 Apr 2014 20:41:40 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta21.westchester.pa.mail.comcast.net with comcast id uLhf1n00A1KKtkw3hLhfMs; Fri, 25 Apr 2014 20:41:39 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3PKfdIL029940; Fri, 25 Apr 2014 16:41:39 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3PKfdVS029938; Fri, 25 Apr 2014 16:41:39 -0400 Date: Fri, 25 Apr 2014 16:41:39 -0400 Message-Id: <201404252041.s3PKfdVS029938@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Larry Masinter In-reply-to: (masinter@adobe.com) References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398458500; bh=IipIe2i5IlPo1MZvq1kYzzfhPC00OuYcZRByARXYxAA=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=G0/v9hfmtzGviQJN/QyZmnJ9+XUdfCq1T8mNtcJbeLU7getPbM2LnIFiirhIqAs/D zJNLwapRyDB3ZJWjjajnrxuzRxOmpDZ7MCAeAOTjQPjR98DuEK/fb7LTD3QkkjrnbC FGV1Wilv0ko9NPzMslZVm6ddwfaAN1Uuocnb0tam8D4nQ8EKQMBs/Bfg6eFV29xEWe yYV2paXqjsHwLXevnSPRhIsS93IKy+KaffTOJus+BhE9wvLMQfRBdOFgWywsbkVsu4 2zeWUE86HSnTou0u5c2uy1vXAaPvZButM/CJeP+rwUpsjXrrx+tIVM7rp+9eBktF9K WiEgXkSs8tf8w== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/o_iEsEhhpyxplN1M6tXN1Qf-vJE Cc: urn@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 20:41:47 -0000 > From: Larry Masinter > > "data:" URLs don't have DNS names and aren't URNs. Ooooh, that's a fascinating example! One can consider a "data:" URI to be a URL, since it provides a way to locate the referenced information (i.e., parse the URI). Nonetheless, it does not contain a DNS name or any other identifier of a network resource. And yet it's also a URN, because it is a persistent identifier of the referenced information -- the association of the URI with the referenced information never changes! Dale From nobody Fri Apr 25 14:10:42 2014 Return-Path: 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 064D21A03E3 for ; Fri, 25 Apr 2014 14:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_21=0.6] autolearn=no 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 8ZP9_2ta3u0d for ; Fri, 25 Apr 2014 14:10:38 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2FD1A03D9 for ; Fri, 25 Apr 2014 14:10:38 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta03.westchester.pa.mail.comcast.net with comcast id uC5o1n0050SCNGk53MAXhA; Fri, 25 Apr 2014 21:10:31 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta09.westchester.pa.mail.comcast.net with comcast id uMAW1n0041KKtkw3VMAWhZ; Fri, 25 Apr 2014 21:10:31 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3PLATBT031474; Fri, 25 Apr 2014 17:10:29 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3PLAPM1031471; Fri, 25 Apr 2014 17:10:25 -0400 Date: Fri, 25 Apr 2014 17:10:25 -0400 Message-Id: <201404252110.s3PLAPM1031471@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: John C Klensin In-reply-to: <11B3A42537CE2D687E206A34@JcK-HP8200.jck.com> (john-ietf@jck.com) References: <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> <11B3A42537CE2D687E206A34@JcK-HP8200.jck.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398460231; bh=aSC14b24kwCTn+NtoS9PdjOwR77BPn76whviCWy84SI=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=EA4Ppsp5WS4t/IMjMjCgP0vcuqyAwgycn7ANrI5ShjWXeo9jS1QzpSjXV+xQ96fZY L1ULjKMKMk9sE6a4IHDaXTg64iRtvo5nWcXluJaM0e5fr1iKRRTQy8p7NZOdnvO8yF 411/LJ+HwPT6B4lbFuIdz0pklt5jxNzfjj6UqUzoIfJpSWIjbcoRJYf++6y9JbNd81 +Se/+xsra79/VrRLEW45sID8FoHceorEpQLUUYFTdryy7w1YY1gLpGQ7CHgRH0/79C lA/L9ulTxBEHTelYvgHRIgxfSTK0LeXwbXaJFo6MwXabP6AV2U4El+gJbVYRV44kEp zS02bdv+aDIqQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/afARVqKgmeAAL0H_V9E925UL8uU Cc: urn@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 21:10:41 -0000 >From the point of view of this analysis, the items that I have a strong opinion are few, but I think that they bear heavily on the practical engineering of the situation, and so need to be resolved one way or the other. The general idea is that being conservative regarding syntax will avoid large costs, because much existing software incorporates syntax assumptions. But extending semantics is not likely to be so expensive, because little software depends on the semantic assumptions of a subset of UR* unless the software performs detailed processing on those particular UR*. > From: John C Klensin > 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:" form that > Phillip proposed, sometimes with a lot of reserved characters > and associated semantics, and sometimes in between. I have a strong sense that it's valuable to have and maintain a syntax within which all the UR* fit, because processors of UR* enforce and implement such syntaxes. Currently the umbrella syntax is RFC 3986. The cost of expanding the UR* syntax beyond what 3986 permits is going to be relatively high, and will show up in systems that try to allow all possible UR*s in certain situations. Unfortunately, 3986 also specifies some semantics. I believe that the semantics defined for '#' (fragment) is sufficiently precise that there is a risk that a considerable number of processors may be incompatible with any other use for '#'. That is, there will be a significant cost to changing its semantics. My current opinion is that the semantics of '?' (query) is sufficiently broad that it can be used for any purpose that the UR* scheme wishes define. URNs of the "urn" scheme are currently constrained to the subset of the syntax that is specified in RFC 2141. 2141 says that '#' and '?' are reserved for expansion, but unfortunately the BNF given does not specify their use. This suggests that adding fragment and query to "urn" URNs will be expensive, as software is likely to be designed to the BNF. However, defining additional URN schemes that do not have that restriction should not have such a cost. > (i) There is a community, [...] that have found the syntax and > semantic constraints unreasonably restrictive given their perceived > needs. Can you give us pointers to this? In particular, regarding the syntax. It seems to me that this is a deeply important point, but short of reading the entire URNBIS archive, I don't see any algorithmic way to obtain the supporting information for this assertion. Surely, if there are large communities with this opinion, someone somewhere has made a clear statement and defense if this conclusion. Dale From nobody Mon Apr 28 05:42:19 2014 Return-Path: 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 EF1E21A09E8; Mon, 28 Apr 2014 05:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 ao38C83GcS73; Mon, 28 Apr 2014 05:42:15 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B18B81A09F6; Mon, 28 Apr 2014 05:42:14 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id mc6so3709854lab.25 for ; Mon, 28 Apr 2014 05:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RnHzcz1puiZ/BgkeHSa98gM8m4aPIbcgVFOrvl2IHQ8=; b=iJx6yHTFi5Wo0Wafq0sl1MfZTwNDThdoOoa4SpOw4m0g9m1U3rOh93Ev+W6+oLRa2X Efv9NNztahC4S+2lWknsMRxr2ivpU7Ij7E8hUfZa1/xVmAhieBSVIusCv+AWmbdFDK6o o7iU9MMw1TNuFig62cGUgl0tEK6zzUaR/UQCMhOfb5Qjco7ngQVrr5b2Z4CzBgFTqpNL th0TX0vaFaW6c1Ya+uATQTSCcGDbmo21Ign+FIABScQ8+X1oLLGLE4e5IdVdes15yjdI EXQ7ZTJnQIvhUEz0Nr7HhUwpq0XBQ8kNzBLisn/MTmumpE7hkegZQ+nTIYltXWaClES0 fF2Q== MIME-Version: 1.0 X-Received: by 10.112.137.39 with SMTP id qf7mr9423267lbb.18.1398688933329; Mon, 28 Apr 2014 05:42:13 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Mon, 28 Apr 2014 05:42:13 -0700 (PDT) In-Reply-To: <201404252041.s3PKfdVS029938@hobgoblin.ariadne.com> References: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> <534FE7BC.4070002@gmx.de> <201404252041.s3PKfdVS029938@hobgoblin.ariadne.com> Date: Mon, 28 Apr 2014 08:42:13 -0400 Message-ID: From: Phillip Hallam-Baker To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/JRCDRzXQlKKb4rvVT2giRRxpP4U Cc: "urn@ietf.org" , General discussion of application-layer protocols 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 12:42:17 -0000 On Fri, Apr 25, 2014 at 4:41 PM, Dale R. Worley wrote: >> From: Larry Masinter >> >> "data:" URLs don't have DNS names and aren't URNs. > > Ooooh, that's a fascinating example! > > One can consider a "data:" URI to be a URL, since it provides a way to > locate the referenced information (i.e., parse the URI). Nonetheless, > it does not contain a DNS name or any other identifier of a network > resource. > > And yet it's also a URN, because it is a persistent identifier of the > referenced information -- the association of the URI with the > referenced information never changes! What you seem to be implying is that the term 'name' be defined by whether or not it meets the requirements for persistence. That is a terrible way to approach nomenclature. The whole URN fiasco has been flawed from the start because names are not persistent by their very nature. Names are in fact the LEAST persistent type of identifier. I remember back in the day when some AI people misread some books on hermeneutics and started talking about 'ontologies'. Many people reading this are aware of the AI definition which is essentially a sort of shared vocabulary of terms. But in philosophy an ontology is a system of being. We are beyond mere epistemology and into considering the nature of existence and being. Yes there are passages in Heidegger that can support the idea that a being is an intersubjective shared framework of communication. But relying on Heidegger for definitions is always a mistake: His significance lies in the novelty of his work rather than the clarity. Again, there is a very longstanding literature in semiotics. If people want to use terms like 'name' I suggest that they stick to existing definitions rather than invent new ones. At the very least we should agree that the term 'name' has an ordinary meaning and that meeting or failing to meet some requirements that might somehow be defined in an RFC is not a proper test of whether something is a name or not. The term name already has a definition in the IETF, that is why it is called the Domain NAME System and not the Domain Locator System. John did complain about a 'my way or the highway' attitude. Well on this I am completely right and there is no room for argument: DNS labels are NAMES sand anyone who wants to argue with that proposition needs to be given a copy of Heidegger and a loaded pistol. data URIs are not names, they are data. If we convert from the semiotics terminology of 'signifier' 'signified' to labels and resources we get: Type 1: Data : The label is the resource value Type 2: Index : The label is a deterministic function of the resource value Type 3: Name : The relationship between the label and the resource is determined by convention Note here that the terms Data and Index are constructed in such a manner that the resource is static, only a name can bind to a dynamic resource. It follows that all URLs are names. The reason that this URN thing takes so long is that people are insisting on bad terminology which is fundamentally confused. The term name does not imply persistence. It implies the very opposite. We could have a useful discussion of persistent versus ephemeral names. Larry's dated URIs are an example of persistent names (as are John Mallery's Persistent Document Identifiers from 1994). But equating name = persistent name is to commit to a fallacy. In conclusion: * The taxonomic distinction between URLs and URNs is meaningless. URLs == URNs for all practical purposes. The people who attempted to make the original distinction did not know what they were doing and they still don't. * No more URN requirements documents. If people want persistent identifiers then they can write up a draft of requirements for persistent identifiers. There is no point in having a requirements document for a term introduced 20 years ago. * Rather than discussing persistence as a binary quality, we should treat it like we treat security and ask 'how much'. -- Website: http://hallambaker.com/ From nobody Tue Apr 29 13:46:27 2014 Return-Path: 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 E709F1A09A0 for ; Tue, 29 Apr 2014 13:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 R86mEMKjiKfk for ; Tue, 29 Apr 2014 13:46:16 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id F14F31A0984 for ; Tue, 29 Apr 2014 13:46:15 -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 ) id 1WfEuq-0009iH-7v; Tue, 29 Apr 2014 16:46:12 -0400 Date: Tue, 29 Apr 2014 16:46:07 -0400 From: John C Klensin To: "Dale R. Worley" Message-ID: <71FCF3F23062A6AE7F8552C9@JcK-HP8200.jck.com> In-Reply-To: <201404252110.s3PLAPM1031471@hobgoblin.ariadne.com> References: <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> <11B3A42537CE2D687E206A34@JcK-HP8200.jck.com> <201404252110.s3PLAPM1031471@hobgoblin.ariadne.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/n9GLpmZPbty-arhlRZH9QoO6Y6c Cc: urn@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 20:46:21 -0000 Hi. I needed to take a few days off from this. I'm going to respond to a few points of Dale's note below, then send a separate one suggesting a way forward. By means of preface, while I may have caused, or at least worsened, the situation by the way draft-ietf-urnbis-urns-are-not-uris-00 is written, I don't believe that the arguments about "want is a name", "what is persistent", and so on are really productive. I think that, if the WG is to make progress, we need to focus on requirements and how to move forward, not philosophy of naming, categories, and/or other hair-splitting exercises. I'm going to try to avoid terms like "name" or "persistent" in this note and its successor. I've tried to be careful about other terminology but this is a mess, so my apologies if I screw up. In particular, I use the term "http-style URLs" below with the intent of avoid discussions of what a "locator" or how other types of URLs or URIs might behave were they to exist. Disclaimer: nothing in this note or its successor makes any statement or inference about what has or might get WG consensus. That determination can be hard and is Not My Job. However, it is fairly easy to observe things like "no traction" and "clear lack of consensus" and I have made some of those observations. --On Friday, April 25, 2014 17:10 -0400 "Dale R. Worley" wrote: > From the point of view of this analysis, the items that I have > a strong opinion are few, but I think that they bear heavily > on the practical engineering of the situation, and so need to > be resolved one way or the other. The general idea is that > being conservative regarding syntax will avoid large costs, > because much existing software incorporates syntax > assumptions. But extending semantics is not likely to be so > expensive, because little software depends on the semantic > assumptions of a subset of UR* unless the software performs > detailed processing on those particular UR*. I would have said something a little different. If 3986 had adopted the "method:" model of URIs, we wouldn't be having this discussion. If it has taken the position that, while some characters were reserved, their interpretation --other than possibly how to tell when the associated information string ended-- were strictly a function of the method, we wouldn't be having this conversation either. What gets us into the current situation (more about that below and in the note that follows) are a number of statements that amount to "if the following character appears, what follows it has more or less the following syntax, is interpreted as specified here, and ends when the following condition is net". >> From: John C Klensin > >> 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:" form that >> Phillip proposed, sometimes with a lot of reserved characters >> and associated semantics, and sometimes in between. > > I have a strong sense that it's valuable to have and maintain > a syntax within which all the UR* fit, because processors of > UR* enforce and implement such syntaxes. Currently the > umbrella syntax is RFC 3986. The cost of expanding the UR* > syntax beyond what 3986 permits is going to be relatively > high, and will show up in systems that try to allow all > possible UR*s in certain situations. With one qualification, I think I agree. However, there are at least three models of "a syntax within which all the UR* fit" and they are not equivalent: * If all UR* are simply required to obey "method:" as a syntax, then there is no problem. There is not necessarily a lot of advantages either other than the ability to recognize a UR* string and dispatch it to method-specific processing. But that is actually a pretty good lever, given how little a UR* processor can actually do without sensitivity to the method. * There is then the significantly more restrictive syntax and interpretation rules of 3986. More commonality and potential for shared code, but also more restrictions. * And there are a few attempts to redefine, or upgrade the definitions, of URLs, a process that may yield definitions that aren't completely compatible with 3986 either. While I think this WG needs to be aware of those possibilities and issues, I don't think it should be its job to sort them out. > Unfortunately, 3986 also specifies some semantics. I believe > that the semantics defined for '#' (fragment) is sufficiently > precise that there is a risk that a considerable number of > processors may be incompatible with any other use for '#'. > That is, there will be a significant cost to changing its > semantics. Yes. The WG more or less figured that out some months ago (or longer). > My current opinion is that the semantics of '?' (query) is > sufficiently broad that it can be used for any purpose that > the UR* scheme wishes define. Yes. But, based on discussions many months ago, there is a question about what a query applies to (see below). It can be accommodated using use "?" syntax of 3986, but only by the use of some reserved keywords or other instances of horrible kludges. One or two such kludges were proposed to the WG. I think it is accurate to report that they got no traction. > URNs of the "urn" scheme are currently constrained to the > subset of the syntax that is specified in RFC 2141. 2141 says > that '#' and '?' are reserved for expansion, but unfortunately > the BNF given does not specify their use. This suggests that > adding fragment and query to "urn" URNs will be expensive, as > software is likely to be designed to the BNF. However, > defining additional URN schemes that do not have that > restriction should not have such a cost. I look at this a little differently, but we might have reached the same conclusion (except that "URNs" that don't use the "urn" method give me a bad headache because of the ease with which going down that path deteriorates into complete confusion in which people have no idea what each other are talking about. See the forthcoming note. >> (i) There is a community, [...] that have found the syntax and >> semantic constraints unreasonably restrictive given their >> perceived needs. > > Can you give us pointers to this? In particular, regarding the > syntax. It seems to me that this is a deeply important point, > but short of reading the entire URNBIS archive, I don't see any > algorithmic way to obtain the supporting information for this > assertion. Surely, if there are large communities with this > opinion, someone somewhere has made a clear statement and > defense if this conclusion. I'm not part of that community although I've observed it and talked with some of its members. Juha or others may be able to conveniently supply references or even a reading list. But, as I understand it in its contemporary form, a key part of the problem is that a lot of object identifiers are ultimately bound to two-part (or more) things in the sense of the old Apple two-fork HFS ("Mac OS Standard") file system and its predecessors. For an http-style URL, the query is addressed to the store in which the object is located and may be used to select the object, to select within it, etc. In a two (or more) fork environment, queries can, in principle, be addressed to information about the object (aka "metadata"), to the selection of the object or subsets of it, and so on. They may specify if retrieval is actually wanted and, if so, in which fork. For some types of objects (types presumably identified by NID) there may be one fork, two forks, or more forks and actual retrieval may be meaningful (or not) for each other them. In principle, one could have an NID (or NID NSS pair) that did not identify an object at all but was a pure string for comparison purposes (that is allowed by 2141 as I read it). Because of those combinations, it is desirable to be able to identify where a query is intended to be processed and/or what sort of query it is on a basis that applies to all urn-method URNs and maybe to have abstractions about what happens when queries cannot be satisfied that goes somewhat beyond what 3986 specifies (or allows other things to specify). Because the query model of 3986 is, at least IMO, pretty closely tied to the interpretation of queries in http-style URLs, it is hard to make those distinctions except, perhaps, by kludge. And, if we are really trying to construct identifiers that will be useful (or at least accurately interpretable) for centuries, even if the presumed associated retrieval methods go away, kludges that can be avoided are probably an extra-bad idea. So that is, at least from my perspective and very limited model, the problem statement that requires something about the foundations of what we are talking about to change. Watch for the other note (on "moving forward"). john From nobody Tue Apr 29 14:52:33 2014 Return-Path: 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 8BDF81A09A9 for ; Tue, 29 Apr 2014 14:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 mjJW0BEiVRBR for ; Tue, 29 Apr 2014 14:52:28 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8321A1A094B for ; Tue, 29 Apr 2014 14:52:28 -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 ) id 1WfFwx-0009mY-9b for urn@ietf.org; Tue, 29 Apr 2014 17:52:27 -0400 Date: Tue, 29 Apr 2014 17:52:22 -0400 From: John C Klensin To: urn@ietf.org Message-ID: 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/HeaI16yNnaiRAd4KlLWM5RfQzt0 Subject: [urn] Moving forward with something URN-ish X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 21:52:30 -0000 Hi. Having addressed some of the questions and explained why I don't want to engage with some of the others (Mark Nottingham's "two communities ... shared artefact" note of 18 April should be incorporated by reference), this note is a personal perspective on ways forward. If draft-ietf-urnbis-urns-are-not-uris is helpful in this regard, it can be revised as needed; perhaps into something rather different. If it is not, it is easily discarded. The terms "the draft" and "the current draft" below refers to draft-ietf-urnbis-urns-are-not-uris-00. Regardless of what one calls either the communities or what they want to do, there is at least one significant community, identified in Section 2 of the draft as "Content industries ... and memory organizations ..." ("CiMo" below), or a subset of that community, that perceives a need for some functionality that cannot be provided by URNs as specified in RFC 2141. For them at least, extensions to 2141 that are fully compatible with RFC 3986 are inadequate to meet those needs. Some of us have come to agree with them (although not all for the same reason(s)). Others do not. They have found a strategy, promoted and practiced by some people associated with the WG in the past, of telling them that they really don't want and/or need to do the things they believe that they need to do unpersuasive... and, given centuries of experience in doing what they do and peer-reviewed literature to back it up, insulting and perhaps worse. They have, IMO, demonstrated remarkable patience with us but still have the option they have had all along. That option could be to develop something URI-like with a method of, e.g., "CiMo" and whatever syntax met their needs or to develop much the same standard with a method name of "URN". Either would presumably be done independent of the IETF. While the advantage of a "CiMo" method and syntax would be that no one would expect it to conform to RFC 3986, it would have the disadvantage of being incompatible with millions of identifiers developed and deployed consistent with RFC 2141 (including but not limited to those developed and deployed consistent with RFCs 3044, 3187, and 3188). If they were to do something independent of the IETF because they gave up on our meeting their needs, I'm not in a position to predict whether they would go the "CiMo" path with a new method or would fork the "urn" method definition. But, in their position, I'd probably look at the economics of converting those millions of existing identifiers and the (extremely small) extra value that would result from doing so... and then decide that the decision to fork the URN definition was a non-brainer. So, without touching the "what is a name", "what does 'presistent' mean" and several other debates (and with some redundancy with a note I wrote earlier in the month) I think we can now: (1) Recommend that the IETF (and maybe others) create a 3986bis with more flexible syntax and no semantics and then revise 2141 to conform with it and accommodate the perceived needs of that CiMo community (and other communities who believe we need to move beyond un-extended 2141). The creation of that 3986bis is clearly outside the scope of this WG. The reaction on the apps-discuss list to the current draft suggests that such a draft cannot be written and agreed to quickly (if at all). (2) Remove syntax for the "urn" method from the scope of 3986 without trying to change 3986 itself. This is what the current draft attempts, probably badly. Then develop a 2141bis that is upward compatible from 2141 (even though it might use some of the bits of syntax that 2141 reserved) and that meets the needs of the CiMo and other communities, as above. (3) Decide that the combination of the relative silence and slowness of the URNBIS WG indicates that an adequate combination of interest and knowledge does not exist in the IETF and then either: (3.1) Close the WG and hope that the necessary expertise and interest will eventually emerge, that the work can be restarted at that time, and that no one decides to do something incompatible in the interim. (3.2) Hand change control over to the CiMo community or someone/ something else and encourage them to develop a new URN spec. That spec would presumably be compatible enough with 2141 to avoid invalidating any 2141-conforming URNs or NIDs because their investment in those existing URNs would encourage that, but the IETF would have no way to enforce that outcome. Presumably we would eventually ask for permission to public their spec or a reference to it in the RFC series and would use to obsolete 2141. Note that, unless the CiMO community exhibits even more patience than they have in the past, presumably being willing to wait for the IETF forever, the only practical difference between 3.1 and 3.2 is probably whether they develop a new URN spec with or without the IETF's official blessing and hence whether their spec is considered a replacement for 2141 or a fork to that IETF URN spec. (4) In principle, the WG could wrap up the work on a 2141bis that was strictly 3986-compatible and complete a 3406bis that was compatible with it and only then close and proceed with one of the variations on (3). Others may have the energy for that; personally I'd think it would be a lot of effort for very little payoff. I just don't see other options, at least ones that not have been proposed already and failed to gain traction. Is anyone else able to suggest ones I haven't thought of? Or have reason to believe that such options will emerge if we wait long enough? And, if there are no other options, what do people want to do? FWIW, there will some meetings next week that will involve some of the key actors in the CiMo standards community. Their procedures won't permit creating a new CiMo-URN project and launching it without some additional steps, but I would expect those of us who are present at all or parts of that meeting to be asked hard questions about the progress the IETF is making. If we don't have answers better than "still stalled and no plan", then the first steps toward an independently-developed specification could easily be taken. Finally, if option (2) is the right approach but the draft isn't the right way to do it, do people have specific suggestions or, ideally, text? best, john