From andy@hxr.us Tue Aug 14 06:59:17 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6939521F869D for ; Tue, 14 Aug 2012 06:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubdu-KKnJb1h for ; Tue, 14 Aug 2012 06:59:17 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB87921F8694 for ; Tue, 14 Aug 2012 06:59:16 -0700 (PDT) Received: by ghbg16 with SMTP id g16so541643ghb.31 for ; Tue, 14 Aug 2012 06:59:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=GtbOcFFRv+v2clT9hPgqKJHDNymvpO792kfKzcKvMqM=; b=BOM1yoGmzS+G79VzQc+yMn10eFL+MYpeIAkjyJaaNnug3kQ/gwcy7kS7nE7esFnuoI Mo3SvDZViwtmHKwNWp3ddIpRfmj14OpTcg9yb1bkmu1PdPJPFGyBilY4laGKCg3IMBRo anjPu0ORNpLBGVoe0jf2o74bjzwDTDwbC3oriFwGKBKAi2YSHgcT8iI9sI+d2uxjbYkQ wA/wXJzo81DozbvCTaDgQ6Xh3fI+CjF3FL4AnrtQuWIipBraifAIyAIYLGe4NXlepS7Y HtQ7w2eKegmRxRL0xBzhUKLmAGRba9MwnvUuriB74Q54AUmsbVa45nopVs93be/PGHDb NIMA== Received: by 10.236.154.165 with SMTP id h25mr15087974yhk.38.1344952756341; Tue, 14 Aug 2012 06:59:16 -0700 (PDT) Received: from ?IPv6:2001:500:4:15:91d7:f3f6:ff76:9906? ([2001:500:4:15:91d7:f3f6:ff76:9906]) by mx.google.com with ESMTPS id l1sm4954132yhm.19.2012.08.14.06.59.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 06:59:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andy Newton In-Reply-To: <50180676.9090108@stpeter.im> Date: Tue, 14 Aug 2012 09:59:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120731162051.14510.52208.idtracker@ietfa.amsl.com> <50180676.9090108@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmnV3flDj/hBEsIuupo6qDlSY+XOHy0YEgFJkc+enEx3dcoKXhvAJnWOeDgia0sVOCmu3aO Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 13:59:17 -0000 With co-chair hat removed ( I think I left it somewhere in Paris ): On Jul 31, 2012, at 12:23 PM, Peter Saint-Andre wrote: > FYI and as previously mentioned. If approved, this document might = enable > us to remove experimental namespace identifiers from 3406bis. Larry Masinter made a statement at the APPSWG about URNs that I thought = was profound and missing from the URN discussions. Hopefully summarizing = his statement correctly: each URN NID should be tied to a naming = authority for the purpose of resolving collisions and errors in the = future. If true, the UUID NID is a mistake, and I think this would be = doing the same. Given that URNs are suppose to have permanence or persistence or = whatever we are calling it today and a resolution mechanism, this desire = to shoehorn identifiers that need to qualify as a URI into the URN = system might be wrong. An identifier that must be a URI does not = necessarily need or have all the properties to be a URN. Just an = observation. -andy= From stpeter@stpeter.im Tue Aug 14 08:47:05 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D678F21F858E for ; Tue, 14 Aug 2012 08:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O1it+M2EJvc for ; Tue, 14 Aug 2012 08:47:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 157D521F857E for ; Tue, 14 Aug 2012 08:47:05 -0700 (PDT) Received: from [64.101.72.56] (unknown [64.101.72.56]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8970D404EA; Tue, 14 Aug 2012 09:47:28 -0600 (MDT) Message-ID: <502A72F7.4070700@stpeter.im> Date: Tue, 14 Aug 2012 09:47:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Andy Newton References: <20120731162051.14510.52208.idtracker@ietfa.amsl.com> <50180676.9090108@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 15:47:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/14/12 7:59 AM, Andy Newton wrote: > With co-chair hat removed ( I think I left it somewhere in Paris > ): > > On Jul 31, 2012, at 12:23 PM, Peter Saint-Andre wrote: > >> FYI and as previously mentioned. If approved, this document >> might enable us to remove experimental namespace identifiers >> from 3406bis. > > Larry Masinter made a statement at the APPSWG about URNs that I > thought was profound and missing from the URN discussions. > Hopefully summarizing his statement correctly: each URN NID should > be tied to a naming authority for the purpose of resolving > collisions and errors in the future. If true, the UUID NID is a > mistake, and I think this would be doing the same. The UUID NID is not a mistake. Or, at least, Ted Hardie convinced me of that last fall in a thread on this very list: http://www.ietf.org/mail-archive/web/urn/current/msg01612.html http://www.ietf.org/mail-archive/web/urn/current/msg01613.html http://www.ietf.org/mail-archive/web/urn/current/msg01614.html http://www.ietf.org/mail-archive/web/urn/current/msg01615.html http://www.ietf.org/mail-archive/web/urn/current/msg01616.html In the case of UUID, the algorithm itself guarantees uniqueness, effectively providing a managed process for issuance of URNs. I agree that example URNs are different here. > Given that URNs are suppose to have permanence or persistence or > whatever we are calling it today and a resolution mechanism, I am not convinced that URNs need to be resolvable. > this desire to shoehorn identifiers that need to qualify as a URI > into the URN system might be wrong. An identifier that must be a > URI does not necessarily need or have all the properties to be a > URN. Just an observation. The idea behind the example URN namespace was to provide a way for people to test URN processing, to use URNs in documentation, and to remove the need for x-* NIDs. One could argue that such things do not need to be URNs in the first place, and I'd be open to that argument, in which case I'd also argue for removing experimental NIDs. At that point I think we'd also say that example URNs belong under specific NIDs (e.g., in my world urn:xmpp:example) and could be issued by the relevant authority for a given NID, thus obviating the need for an example NID. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqcvcACgkQNL8k5A2w/vwdaQCeNks8yVb1xqVkyrB3H92Ap/BT iwMAnjogEqn36Xi0dXGxAcCPGZkBUUZq =eQ4h -----END PGP SIGNATURE----- From moore@network-heretics.com Thu Aug 16 04:50:17 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C795A21F84B8 for ; Thu, 16 Aug 2012 04:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2d8-FQ2wOu8 for ; Thu, 16 Aug 2012 04:50:17 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id E818921F84B6 for ; Thu, 16 Aug 2012 04:50:16 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0F04020C80 for ; Thu, 16 Aug 2012 07:50:16 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 16 Aug 2012 07:50:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=1IqHVWtM1A+dyONrb77ECF /h5XE=; b=KXrjN04RE/5v5vQBQDbmVWT13Jm370G9dpNFWvxkQzrHbFpmeY4R0x Crryts9pqcpnfoyO7Y6eWyJfYwK3dmr4paFPROYYOi39qhkEvRavvgSM42xf6MmW OQNR9ujfUXfue45BduB52t6YV6xmX0iPvKAS2jwvlA+086woacMS0= X-Sasl-enc: 4D0JAaTokxttQKoqyyd6DoDCkUrWfmVmqxt3vVZcpNbu 1345117815 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 878B88E01F4 for ; Thu, 16 Aug 2012 07:50:15 -0400 (EDT) Message-ID: <502CDE74.4050400@network-heretics.com> Date: Thu, 16 Aug 2012 07:50:12 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: urn@ietf.org References: <20120731162051.14510.52208.idtracker@ietfa.amsl.com> <50180676.9090108@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 11:50:17 -0000 On 08/14/2012 09:59 AM, Andy Newton wrote: > Given that URNs are suppose to have permanence or persistence or > whatever we are calling it today and a resolution mechanism, this > desire to shoehorn identifiers that need to qualify as a URI into the > URN system might be wrong. An identifier that must be a URI does not > necessarily need or have all the properties to be a URN. Just an > observation. +1 URNs were intended to be _resource names_, i.e. names of resources rather than merely unique identifiers. The expectation was that such resources would generally be at least potentially accessible over the network, and that it would be possible to resolve such names to resource locations. Everyone agreed that it should be possible to assign URNs to resources that were not resolvable, or at least not resolvable for the time being. But the idea that URNs are appropriate for use whenever someone needed a unique non-resolvable identifier that qualifies as a URI, always has struck me as bizarre and contrary to the intended purpose of URNs. Keith From A.Hoenes@TR-Sys.de Thu Aug 16 14:03:32 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFBF21F867F for ; Thu, 16 Aug 2012 14:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.583 X-Spam-Level: X-Spam-Status: No, score=-98.583 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyqF9ab9e4gy for ; Thu, 16 Aug 2012 14:03:31 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id D423121F867E for ; Thu, 16 Aug 2012 14:03:28 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA214570894; Thu, 16 Aug 2012 23:01:34 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA08756; Thu, 16 Aug 2012 23:01:33 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201208162101.XAA08756@TR-Sys.de> To: moore@network-heretics.com Date: Thu, 16 Aug 2012 23:01:32 +0200 (MESZ) In-Reply-To: <502CDE74.4050400@network-heretics.com> from Keith Moore at Aug "16, " 2012 "07:50:12" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 21:03:32 -0000 (no hat) On 08/16/2012, Keith Moore wrote: > On 08/14/2012 09:59 AM, Andy Newton wrote: >> Given that URNs are suppose to have permanence or persistence or >> whatever we are calling it today and a resolution mechanism, this >> desire to shoehorn identifiers that need to qualify as a URI into the >> URN system might be wrong. An identifier that must be a URI does not >> necessarily need or have all the properties to be a URN. Just an >> observation. > +1 > > URNs were intended to be _resource names_, i.e. names of resources > rather than merely unique identifiers. The expectation was that such > resources would generally be at least potentially accessible over the > network, and that it would be possible to resolve such names to resource > locations. Everyone agreed that it should be possible to assign URNs > to resources that were not resolvable, or at least not resolvable for > the time being. But the idea that URNs are appropriate for use whenever > someone needed a unique non-resolvable identifier that qualifies as a > URI, always has struck me as bizarre and contrary to the intended > purpose of URNs. > > Keith +1 (for both statements) I already have responded similarly to the seminal email wrt this topic (by Julian) that has motivated the creation this I-D (by PSA). The above notes seem to be properly backed the following excerpts from RFC 1737, "Requirements for Uniform Resource Names", Section 2, "Requirements for functional capabilities": | ... | It is intended that the lifetime of a URN be permanent. | ... | | URNs can be assigned to any resource that might conceivably | be available on the network, for hundreds of years. | ... IMO, the concepts of "example URNs" and "testing URNs" seem to be fundamentally incompatible with these requirements. For the latter, rapid software development for testing of namespace management and resolution systems can be furthered by "early reservation/assignment" of URN Namespace IDs by IANA (as soon as urn-nid mailing list and expert review "thumbs up" is obtained for a new URN Namespace proposal. Best regards, Alfred. > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From julian.reschke@gmx.de Fri Aug 17 00:27:46 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE9721F852B for ; Fri, 17 Aug 2012 00:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[AWL=-2.441, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZGA1sWwsQvx for ; Fri, 17 Aug 2012 00:27:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 53B7A21F851C for ; Fri, 17 Aug 2012 00:27:45 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 07:27:43 -0000 Received: from p54BB2EC5.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.46.197] by mail.gmx.net (mp024) with SMTP; 17 Aug 2012 09:27:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+9JYtEWhS99XG8cdQ9DVm0rlXhGFsIkRIVBsX2vk 6iYF1/VSFPee1d Message-ID: <502DF26E.3050406@gmx.de> Date: Fri, 17 Aug 2012 09:27:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201208162101.XAA08756@TR-Sys.de> In-Reply-To: <201208162101.XAA08756@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org, moore@network-heretics.com Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 07:27:46 -0000 On 2012-08-16 23:01, Alfred � wrote: > (no hat) > > On 08/16/2012, Keith Moore wrote: >> On 08/14/2012 09:59 AM, Andy Newton wrote: >>> Given that URNs are suppose to have permanence or persistence or >>> whatever we are calling it today and a resolution mechanism, this >>> desire to shoehorn identifiers that need to qualify as a URI into the >>> URN system might be wrong. An identifier that must be a URI does not >>> necessarily need or have all the properties to be a URN. Just an >>> observation. >> +1 >> >> URNs were intended to be _resource names_, i.e. names of resources >> rather than merely unique identifiers. The expectation was that such >> resources would generally be at least potentially accessible over the >> network, and that it would be possible to resolve such names to resource >> locations. Everyone agreed that it should be possible to assign URNs >> to resources that were not resolvable, or at least not resolvable for >> the time being. But the idea that URNs are appropriate for use whenever >> someone needed a unique non-resolvable identifier that qualifies as a >> URI, always has struck me as bizarre and contrary to the intended >> purpose of URNs. >> >> Keith > > +1 (for both statements) For the record: -1- urn:uuid: is used a lot in practice, and I simply don't see a practical problem with it. Are you saying these shouldn't be URIs in the first place, or that a separate URI scheme would have been ok (in which case those would be URNs as well, just not using the "URN" URI scheme, no?). > I already have responded similarly to the seminal email wrt this topic > (by Julian) that has motivated the creation this I-D (by PSA). > > The above notes seem to be properly backed the following excerpts > from RFC 1737, "Requirements for Uniform Resource Names", > Section 2, "Requirements for functional capabilities": > > | ... > | It is intended that the lifetime of a URN be permanent. > | ... > | > | URNs can be assigned to any resource that might conceivably > | be available on the network, for hundreds of years. > | ... > > IMO, the concepts of "example URNs" and "testing URNs" seem to be > fundamentally incompatible with these requirements. For the latter, > rapid software development for testing of namespace management and > resolution systems can be furthered by "early reservation/assignment" > of URN Namespace IDs by IANA (as soon as urn-nid mailing list and > expert review "thumbs up" is obtained for a new URN Namespace proposal. The use case for reserved example URNs are specifications. It's much better if people use one reserved for this purpose than making up invalid ones (and that's what started this discussion). Best regards, Julian From moore@network-heretics.com Fri Aug 17 04:57:44 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8F721F857D for ; Fri, 17 Aug 2012 04:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDUOcOeYkVdS for ; Fri, 17 Aug 2012 04:57:43 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 69E0821F8575 for ; Fri, 17 Aug 2012 04:57:43 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BA2E320731; Fri, 17 Aug 2012 07:57:42 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 17 Aug 2012 07:57:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=ksAa2vn8lXBVicCdfz8WvH kSyiA=; b=AU4X/gS5YgGfD/wrFFeYDY03MvI93PYdP93NzqFX4kV0nekM1rYGU9 eTit4XFcPPNhShE0qT7DuVC/9BeDG/droVAbDQsNHUD8kk7oUAHRzynf481zZUJf TY75uP3eCuTsUfwend+U6DbtkLjDnRYjBbEnT8U4Q7pJEkZA6JzbE= X-Sasl-enc: XmogI6h2IZrl+NEUB/pHHLcMINuOos901dzfVMT85FP/ 1345204661 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 09CD48E0111; Fri, 17 Aug 2012 07:57:40 -0400 (EDT) Message-ID: <502E31B0.8000500@network-heretics.com> Date: Fri, 17 Aug 2012 07:57:36 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Julian Reschke References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> In-Reply-To: <502DF26E.3050406@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 11:57:44 -0000 On 08/17/2012 03:27 AM, Julian Reschke wrote: > On 2012-08-16 23:01, Alfred � wrote: >> (no hat) >> >> On 08/16/2012, Keith Moore wrote: >>> On 08/14/2012 09:59 AM, Andy Newton wrote: >>>> Given that URNs are suppose to have permanence or persistence or >>>> whatever we are calling it today and a resolution mechanism, this >>>> desire to shoehorn identifiers that need to qualify as a URI into the >>>> URN system might be wrong. An identifier that must be a URI does not >>>> necessarily need or have all the properties to be a URN. Just an >>>> observation. >>> +1 >>> >>> URNs were intended to be _resource names_, i.e. names of resources >>> rather than merely unique identifiers. The expectation was that such >>> resources would generally be at least potentially accessible over the >>> network, and that it would be possible to resolve such names to >>> resource >>> locations. Everyone agreed that it should be possible to assign URNs >>> to resources that were not resolvable, or at least not resolvable for >>> the time being. But the idea that URNs are appropriate for use >>> whenever >>> someone needed a unique non-resolvable identifier that qualifies as a >>> URI, always has struck me as bizarre and contrary to the intended >>> purpose of URNs. >>> >>> Keith >> >> +1 (for both statements) > > For the record: -1- > > urn:uuid: is used a lot in practice, and I simply don't see a > practical problem with it. > > Are you saying these shouldn't be URIs in the first place, or that a > separate URI scheme would have been ok (in which case those would be > URNs as well, just not using the "URN" URI scheme, no?). I don't actually have a problem with UUID URNs in principle, so long as the mechanisms used to generate UUIDs actually ensure that they're unique. (If memory serves, they do, but it's been awhile since I've read the spec). As long as people use UUID URNs to refer to resources, such usage is perfectly consistent with the intended purpose of URNs. And I certainly am not suggesting that UUID URNs be deprecated, or any thing similarly disruptive. The problem I have is with the idea that has emerged that if you need an ID that happens to be a URI, a URN is the right thing to use. I've seen a lot of things labeled "urn:" that didn't refer to resources, or worse, weren't unique at all, apparently because of this idea. Keith From julian.reschke@gmx.de Fri Aug 17 05:09:12 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F7121F84DD for ; Fri, 17 Aug 2012 05:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.277 X-Spam-Level: X-Spam-Status: No, score=-104.277 tagged_above=-999 required=5 tests=[AWL=-1.678, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3lF34oQGrqJ for ; Fri, 17 Aug 2012 05:09:11 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id AA92521F8499 for ; Fri, 17 Aug 2012 05:09:06 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 12:09:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 17 Aug 2012 14:09:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+DzYY6dGyDWUtNrMi8zSinu75OZQWZ0Yc0KjFj4W 3zKfVe3tknRZM1 Message-ID: <502E3460.209@gmx.de> Date: Fri, 17 Aug 2012 14:09:04 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Keith Moore References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <502E31B0.8000500@network-heretics.com> In-Reply-To: <502E31B0.8000500@network-heretics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 12:09:12 -0000 On 2012-08-17 13:57, Keith Moore wrote: > ... > I don't actually have a problem with UUID URNs in principle, so long as > the mechanisms used to generate UUIDs actually ensure that they're > unique. (If memory serves, they do, but it's been awhile since I've read > the spec). As long as people use UUID URNs to refer to resources, such > usage is perfectly consistent with the intended purpose of URNs. And I > certainly am not suggesting that UUID URNs be deprecated, or any thing > similarly disruptive. > > The problem I have is with the idea that has emerged that if you need an > ID that happens to be a URI, a URN is the right thing to use. I've > seen a lot of things labeled "urn:" that didn't refer to resources, or > worse, weren't unique at all, apparently because of this idea. > ... Do you have a definition of "resource" different from: "the term "resource" is used in a general sense for whatever might be identified by a URI" -- ? Other than that, I agree about the uniqueness bit. Best regards, Julian From moore@network-heretics.com Fri Aug 17 05:17:47 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5259E21F84D3 for ; Fri, 17 Aug 2012 05:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxAut1KdA5ZO for ; Fri, 17 Aug 2012 05:17:46 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 96D4921F84CD for ; Fri, 17 Aug 2012 05:17:46 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2F9E8207C1; Fri, 17 Aug 2012 08:17:46 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Fri, 17 Aug 2012 08:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=ZF1I3Y8MJIIPyoTJVkjVwc iVjtU=; b=JLplOeJOxDU4JGCKFmfVi7nFNAPg1D6iOFfuoSJQLh5RbQU6Zk3Ye9 u+gVAdOz52SJ3uaEfY+5CdNdIo9F7RG0DFqqLg7s2gg2PGNQ2UJLUTy8NW7UrcFf JjQ+CELihI5/P5zIoRqtQyK/XMPEYzHPqwKbbNseqg2qUQn8IffNk= X-Sasl-enc: 0UKcnBr+1u8ckarQBnJsB55BZB0LonC5kqCBPMmoesDD 1345205865 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 690B548279B; Fri, 17 Aug 2012 08:17:45 -0400 (EDT) Message-ID: <502E3666.9090308@network-heretics.com> Date: Fri, 17 Aug 2012 08:17:42 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Julian Reschke References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <502E31B0.8000500@network-heretics.com> <502E3460.209@gmx.de> In-Reply-To: <502E3460.209@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 12:17:47 -0000 On 08/17/2012 08:09 AM, Julian Reschke wrote: > On 2012-08-17 13:57, Keith Moore wrote: >> ... >> I don't actually have a problem with UUID URNs in principle, so long as >> the mechanisms used to generate UUIDs actually ensure that they're >> unique. (If memory serves, they do, but it's been awhile since I've read >> the spec). As long as people use UUID URNs to refer to resources, such >> usage is perfectly consistent with the intended purpose of URNs. And I >> certainly am not suggesting that UUID URNs be deprecated, or any thing >> similarly disruptive. >> >> The problem I have is with the idea that has emerged that if you need an >> ID that happens to be a URI, a URN is the right thing to use. I've >> seen a lot of things labeled "urn:" that didn't refer to resources, or >> worse, weren't unique at all, apparently because of this idea. >> ... > > Do you have a definition of "resource" different from: > > "the term "resource" is used in a general sense for whatever might be > identified by a URI" -- > > > ? That's not a very useful definition for determining whether a URN is appropriate. But my point is that a URN should name _something_. In addition, it needs to be clear what is being named by the URN. Otherwise there's no way to ensure persistence of the binding between the URN and the resource. Keith From julian.reschke@gmx.de Fri Aug 17 06:08:10 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03E321F852C for ; Fri, 17 Aug 2012 06:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.257 X-Spam-Level: X-Spam-Status: No, score=-104.257 tagged_above=-999 required=5 tests=[AWL=-1.658, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV5lVLM20wwf for ; Fri, 17 Aug 2012 06:08:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id BD00721F84B3 for ; Fri, 17 Aug 2012 06:08:08 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 13:08:07 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp039) with SMTP; 17 Aug 2012 15:08:07 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1804Z0Wwlw0JTg/k+79jp017bLrl0wDzdbKReCbYs v3l7Sy5M2r73MJ Message-ID: <502E4237.8090804@gmx.de> Date: Fri, 17 Aug 2012 15:08:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Keith Moore References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <502E31B0.8000500@network-heretics.com> <502E3460.209@gmx.de> <502E3666.9090308@network-heretics.com> In-Reply-To: <502E3666.9090308@network-heretics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:08:11 -0000 On 2012-08-17 14:17, Keith Moore wrote > That's not a very useful definition for determining whether a URN is > appropriate. But my point is that a URN should name _something_. My understanding is that if you can give it a name (URI/URN), it is "something". > In addition, it needs to be clear what is being named by the URN. > Otherwise there's no way to ensure persistence of the binding between > the URN and the resource. Given a UUID, there's no way to know *what* is being named without additional information. How is that a problem in practice, if all you need is a unique identifier? Best regards, Julian From moore@network-heretics.com Fri Aug 17 07:09:10 2012 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8C521F8593 for ; Fri, 17 Aug 2012 07:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbtGx-UQ14wc for ; Fri, 17 Aug 2012 07:09:08 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id A37E621F858A for ; Fri, 17 Aug 2012 07:09:08 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4E46B20C3A; Fri, 17 Aug 2012 10:09:08 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 17 Aug 2012 10:09:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=NrPIoe2lO4M+NJTJDB0/JR Ckrws=; b=CR+Ibbp6Uc4yaPpbqKdpnOaWw1vpPhZcvc4h+QmEdF4BiEEtsOMfs8 zetQsZgzjChDMHJVJlgu10xofJ/8l/yAGjYH6ZonsmjYZcqQ7TDN4l+C8ajF5EwM AYOuqBm97p6NRDUjwHKOwIUnSouGFl4phqye7w2GftmqEf5yo956o= X-Sasl-enc: cJWze7iK8lj1Juq1ADZ6mY6uWry5FhnJ4yZa4EKZEgrk 1345212547 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A3EF548270E; Fri, 17 Aug 2012 10:09:07 -0400 (EDT) Message-ID: <502E5080.8000705@network-heretics.com> Date: Fri, 17 Aug 2012 10:09:04 -0400 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Julian Reschke References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <502E31B0.8000500@network-heretics.com> <502E3460.209@gmx.de> <502E3666.9090308@network-heretics.com> <502E4237.8090804@gmx.de> In-Reply-To: <502E4237.8090804@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 14:09:10 -0000 On 08/17/2012 09:08 AM, Julian Reschke wrote: > On 2012-08-17 14:17, Keith Moore wrote >> That's not a very useful definition for determining whether a URN is >> appropriate. But my point is that a URN should name _something_. > > My understanding is that if you can give it a name (URI/URN), it is > "something". Yes, but you can coin names without binding them to anything, or without being clear about what you're naming. >> In addition, it needs to be clear what is being named by the URN. >> Otherwise there's no way to ensure persistence of the binding between >> the URN and the resource. > > Given a UUID, there's no way to know *what* is being named without > additional information. How is that a problem in practice, if all you > need is a unique identifier? URNs aren't merely unique; the binding between the URN and the resource named is expected to be persistent. By declaring something to be a URN, you're making both assertions. UUIDs are unique (by definition), but just because you create a UUID for something doesn't mean you're committing to making the binding between the UUID and that something persistent. It follows that not every UUID should be considered to be suitable for use in a UUID URN. (naming is tricky and extremely subtle) Keith