From stpeter@stpeter.im Mon Jan 7 10:35:08 2013 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 2387C21F8994 for ; Mon, 7 Jan 2013 10:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 AwGPuXgcZqVi for ; Mon, 7 Jan 2013 10:35:07 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEC621F882E for ; Mon, 7 Jan 2013 10:35:06 -0800 (PST) Received: from [10.129.24.67] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CBAF8404EB for ; Mon, 7 Jan 2013 11:40:10 -0700 (MST) Message-ID: <50EB1560.3060602@stpeter.im> Date: Mon, 07 Jan 2013 11:35:12 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: urn@ietf.org References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> In-Reply-To: <502DF26E.3050406@gmx.de> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Mon, 07 Jan 2013 18:35:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Old thread alert! On 8/17/12 1: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 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). Exactly. Just as we have reserved domain names for specifications (RFC 2606), I think it might be useful to have a reserved URN namespace ID for specifications. I'd be happy to more carefully scope the Internet-Draft to reflect that narrow focus. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDrFWAACgkQNL8k5A2w/vxNBACfd5mSh3XTngTaHgBLiNLX07f1 VsUAoMgpbVZhAAJ4fo2FmAPwf4/WOn/g =jk5H -----END PGP SIGNATURE----- From moore@network-heretics.com Tue Jan 8 20:28:00 2013 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 7D7EE1F0CF8 for ; Tue, 8 Jan 2013 20:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 LCDqj9NlOz9h for ; Tue, 8 Jan 2013 20:27:59 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 92E791F0CB3 for ; Tue, 8 Jan 2013 20:27:59 -0800 (PST) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E4FEE20A47; Tue, 8 Jan 2013 23:27:58 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 08 Jan 2013 23:27:58 -0500 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=E5e1CMT8hctSJxUAA/dbWJ yfu4M=; b=rbfTAxfZxHvyZFCjFthQTXKOHdJSKBA3C5Go5B6Bx0dre/CiAin0Nw wtCLcMlb1QTf3mKM/QFULQFErjGtCzKohF84GX5L2cSF1ddN7XU17a1yFqAkBc6U HxL0XeR1wwijcJxSTnu1YpyC92uQKw1KSV8cLoFuFBL9rJJ8DYm6I= X-Sasl-enc: PXPtXTO7ceKvess68OpRmbFO/VsyiKb6j87x1j4Zk761 1357705678 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 099A44827A2; Tue, 8 Jan 2013 23:27:57 -0500 (EST) Message-ID: <50ECF1CC.6030208@network-heretics.com> Date: Tue, 08 Jan 2013 23:27:56 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> In-Reply-To: <50EB1560.3060602@stpeter.im> 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: Wed, 09 Jan 2013 04:28:00 -0000 On 01/07/2013 01:35 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Old thread alert! > > On 8/17/12 1: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. Whether something works well in practice, and whether something conforms to the intent of a standard, are of course two separate questions. Again, URNs were designed to identify resources. If people use them for other things, that's not a problem so long as such use doesn't degrade the intended utility of URNs. It's not like the protocol police are going to chase down the users of UUID URNs and put them in jail if those UUIDs weren't chosen to refer to resources. And of course you can't tell by looking what is named by a URN - and that is a feature, not a bug. But just because people find uses for URNs that weren't intended, doesn't mean that the URN standard should be changed to encompass those uses. This _would_ degrade the utility of URNs. To be clear, there's nothing in principle wrong with a UUID URN. What's wrong is using a UUID URN just because what you need is a unique identifier that doesn't refer to a resource, and you want that unique ID to be some sort of URI. Yes, it probably does little harm most of the time, but it's still not a good idea to promote the practice. > 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'm saying that whoever insisted that it was a good idea to use URIs of any kind as unique identifiers, just because they happened to contain DNS names (which we already knew were not unique over time), was adding needless complexity to the network in exchange for marginal, probably negative, utility. UUIDs by themselves would have worked just fine.[*] Misuse of URNs in this way is just a small part of the resulting collateral damage. [*] Well, almost just fine. I've seen security holes in web services that relied on UUID URNs as transaction IDs and were vulnerable to trivial UUID guessing attacks. But the general problem is with adding more layers which aren't well understood. People who don't understand security protocols shouldn't be picking what to use as nonces, people who don't understand URNs shouldn't be designing protocols around them. etc. Keith From julian.reschke@gmx.de Wed Jan 9 07:49:02 2013 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 93D7A21F8698 for ; Wed, 9 Jan 2013 07:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.832 X-Spam-Level: X-Spam-Status: No, score=-103.832 tagged_above=-999 required=5 tests=[AWL=-1.233, 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 tkVRJwtkHOK0 for ; Wed, 9 Jan 2013 07:49:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 242AE21F84F3 for ; Wed, 9 Jan 2013 07:49:01 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MfTAj-1TdtzT1LP1-00P9yG for ; Wed, 09 Jan 2013 16:49:00 +0100 Received: (qmail invoked by alias); 09 Jan 2013 15:49:00 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 09 Jan 2013 16:49:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Df+RPO0mDVy3xRg7+GEbNkYNsxj9vlg0m7Cg0B3 5QklwqFOOYV6zk Message-ID: <50ED9168.6050000@gmx.de> Date: Wed, 09 Jan 2013 16:48:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Keith Moore References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> In-Reply-To: <50ECF1CC.6030208@network-heretics.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Wed, 09 Jan 2013 15:49:02 -0000 On 2013-01-09 05:27, Keith Moore wrote: > On 01/07/2013 01:35 PM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Old thread alert! >> >> On 8/17/12 1: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. > Whether something works well in practice, and whether something conforms > to the intent of a standard, are of course two separate questions. > > Again, URNs were designed to identify resources. If people use them > for other things, that's not a problem so long as such use doesn't > degrade the intended utility of URNs. It's not like the protocol > police are going to chase down the users of UUID URNs and put them in > jail if those UUIDs weren't chosen to refer to resources. And of course > you can't tell by looking what is named by a URN - and that is a > feature, not a bug. > > But just because people find uses for URNs that weren't intended, > doesn't mean that the URN standard should be changed to encompass those > uses. This _would_ degrade the utility of URNs. > > To be clear, there's nothing in principle wrong with a UUID URN. What's > wrong is using a UUID URN just because what you need is a unique > identifier that doesn't refer to a resource, and you want that unique ID > to be some sort of URI. Yes, it probably does little harm most of the > time, but it's still not a good idea to promote the practice. > ... "This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI." -- Case closed. Best regards, Julian (ducks) From moore@network-heretics.com Wed Jan 9 07:59:35 2013 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 A061021F87E3 for ; Wed, 9 Jan 2013 07:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 V+P57uNRzD72 for ; Wed, 9 Jan 2013 07:59:34 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id DBFFA21F87E1 for ; Wed, 9 Jan 2013 07:59:34 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1591220C7D; Wed, 9 Jan 2013 10:59:33 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 09 Jan 2013 10:59:34 -0500 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=e8uDRTb1TUoIs5045fF89h 0gbsU=; b=cOcGtP4ojvE6mIuNSXlyI3oS/Wr9Y3FmIWSEQd0CtGhVLoq/tJOUK1 SQx+HtQATQK8tiv0kM9KYCBuaMiXCyHW8swsEKnsItZE//1i175LEBbQ4yFzZ1RJ 1WABkAw/D97/HSgPtAL+OMkj7TKD3jAYX3vzJL7xGekRYaMvXO1P0= X-Sasl-enc: RJgzDcxtwquJxNDfU6o9/wrbRhDg/y8d9thkRFuzy7jS 1357747173 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 1534A8E07A5; Wed, 9 Jan 2013 10:59:32 -0500 (EST) Message-ID: <50ED93E2.9040002@network-heretics.com> Date: Wed, 09 Jan 2013 10:59:30 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Julian Reschke References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> In-Reply-To: <50ED9168.6050000@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: Wed, 09 Jan 2013 15:59:35 -0000 On 01/09/2013 10:48 AM, Julian Reschke wrote: >>>> >>>> urn:uuid: is used a lot in practice, and I simply don't see a >>>> practical problem with it. >> Whether something works well in practice, and whether something conforms >> to the intent of a standard, are of course two separate questions. >> >> Again, URNs were designed to identify resources. If people use them >> for other things, that's not a problem so long as such use doesn't >> degrade the intended utility of URNs. It's not like the protocol >> police are going to chase down the users of UUID URNs and put them in >> jail if those UUIDs weren't chosen to refer to resources. And of course >> you can't tell by looking what is named by a URN - and that is a >> feature, not a bug. >> >> But just because people find uses for URNs that weren't intended, >> doesn't mean that the URN standard should be changed to encompass those >> uses. This _would_ degrade the utility of URNs. >> >> To be clear, there's nothing in principle wrong with a UUID URN. What's >> wrong is using a UUID URN just because what you need is a unique >> identifier that doesn't refer to a resource, and you want that unique ID >> to be some sort of URI. Yes, it probably does little harm most of the >> time, but it's still not a good idea to promote the practice. >> ... > > "This specification does not limit the scope of what might be a > resource; rather, the term "resource" is used in a general sense for > whatever might be identified by a URI." -- > > > Case closed. yes, but it didn't anticipate that URNs would be widely used to not name resources at all. again, most such uses do little harm. but that's not an argument for perverting URNs to be just random numbers instead of resource identifiers. Keith From julian.reschke@gmx.de Wed Jan 9 08:01:00 2013 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 2B08F21F87E3 for ; Wed, 9 Jan 2013 08:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=-0.925, 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 CjWrpZE7K0C8 for ; Wed, 9 Jan 2013 08:00:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9783A21F87E0 for ; Wed, 9 Jan 2013 08:00:51 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MT5po-1TS7Yi3QL0-00S4K2 for ; Wed, 09 Jan 2013 17:00:50 +0100 Received: (qmail invoked by alias); 09 Jan 2013 16:00:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 09 Jan 2013 17:00:50 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX188XLAPOac8tL42MJL1b0D2C55B+gYCkeZ4qvrbmZ V0RDJjTPk9UE9P Message-ID: <50ED9430.4040606@gmx.de> Date: Wed, 09 Jan 2013 17:00:48 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Keith Moore References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> In-Reply-To: <50ED93E2.9040002@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: Wed, 09 Jan 2013 16:01:00 -0000 On 2013-01-09 16:59, Keith Moore wrote: > On 01/09/2013 10:48 AM, Julian Reschke wrote: >>>>> >>>>> urn:uuid: is used a lot in practice, and I simply don't see a >>>>> practical problem with it. >>> Whether something works well in practice, and whether something conforms >>> to the intent of a standard, are of course two separate questions. >>> >>> Again, URNs were designed to identify resources. If people use them >>> for other things, that's not a problem so long as such use doesn't >>> degrade the intended utility of URNs. It's not like the protocol >>> police are going to chase down the users of UUID URNs and put them in >>> jail if those UUIDs weren't chosen to refer to resources. And of course >>> you can't tell by looking what is named by a URN - and that is a >>> feature, not a bug. >>> >>> But just because people find uses for URNs that weren't intended, >>> doesn't mean that the URN standard should be changed to encompass those >>> uses. This _would_ degrade the utility of URNs. >>> >>> To be clear, there's nothing in principle wrong with a UUID URN. What's >>> wrong is using a UUID URN just because what you need is a unique >>> identifier that doesn't refer to a resource, and you want that unique ID >>> to be some sort of URI. Yes, it probably does little harm most of the >>> time, but it's still not a good idea to promote the practice. >>> ... >> >> "This specification does not limit the scope of what might be a >> resource; rather, the term "resource" is used in a general sense for >> whatever might be identified by a URI." -- >> >> >> Case closed. > yes, but it didn't anticipate that URNs would be widely used to not name > resources at all. > > again, most such uses do little harm. but that's not an argument for > perverting URNs to be just > random numbers instead of resource identifiers. > ... My point being: they *are* resource identifiers. Best regards, Julian From moore@network-heretics.com Wed Jan 9 08:05:05 2013 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 08CFC11E80EC for ; Wed, 9 Jan 2013 08:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 tb1ERO7Ofsqb for ; Wed, 9 Jan 2013 08:05:04 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 553BB21F880E for ; Wed, 9 Jan 2013 08:05:04 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0B93320A14; Wed, 9 Jan 2013 11:05:04 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 09 Jan 2013 11:05:04 -0500 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=KvhriTiLheSM27BAr/5jTg CVHJo=; b=iB4r/ltfHUfcWT5oYkEXroCN9w5EhqHdF36DUocCx5r0yqI+uZlJe3 smnsSIyitaKt1CgwvzQeTaw2Mt7AgI29nFCfKKYXdMfCiWiZldaqj4khTLMPfqa7 bbINuBtAYxhBsPtAmhrpZMvTUVgEh7WfwSqrBvNlDxXWB3x+qEZQ8= X-Sasl-enc: MPlYRlc1Rqq7LTGHSjOMCVstotp6nVgwnD/kvcSpCtYC 1357747503 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 3DBB74827CB; Wed, 9 Jan 2013 11:05:03 -0500 (EST) Message-ID: <50ED952C.8080704@network-heretics.com> Date: Wed, 09 Jan 2013 11:05:00 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Julian Reschke References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> In-Reply-To: <50ED9430.4040606@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: Wed, 09 Jan 2013 16:05:05 -0000 On 01/09/2013 11:00 AM, Julian Reschke wrote: >>> "This specification does not limit the scope of what might be a >>> resource; rather, the term "resource" is used in a general sense for >>> whatever might be identified by a URI." -- >>> >>> >>> Case closed. >> yes, but it didn't anticipate that URNs would be widely used to not name >> resources at all. >> >> again, most such uses do little harm. but that's not an argument for >> perverting URNs to be just >> random numbers instead of resource identifiers. >> ... > > My point being: they *are* resource identifiers. Only if they actually identify resources. Keith From michael@refactored-networks.com Wed Jan 9 08:19:37 2013 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 A423721F87E7 for ; Wed, 9 Jan 2013 08:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1n9IayDZ-t4H for ; Wed, 9 Jan 2013 08:19:37 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id D928521F87E3 for ; Wed, 9 Jan 2013 08:19:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 50B29390095; Wed, 9 Jan 2013 10:19:36 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwbGunHBlngz; Wed, 9 Jan 2013 10:19:36 -0600 (CST) Received: from smtp.01.com (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1DAF73900BD; Wed, 9 Jan 2013 10:19:36 -0600 (CST) Received: from [10.136.79.33] (unknown [65.50.0.4]) by smtp-out-2.01.com (Postfix) with ESMTPSA id E19003900B7; Wed, 9 Jan 2013 10:19:35 -0600 (CST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Mealling In-Reply-To: <50ED952C.8080704@network-heretics.com> Date: Wed, 9 Jan 2013 11:19:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1499) Cc: Julian Reschke , 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: Wed, 09 Jan 2013 16:19:37 -0000 Is it really 1999 all over again? Maybe I should by come CMGI stock. With a couple of noted exceptions this is one area where the W3C and the = IETF's URN group agreed: That the definition of 'resource' is the thing = identified by a URI. That minting any URI immediately causes its = resource to come into being in the abstract. Some URI scheme = specifications can restrict that it limits resource to be sequences of = bits on a network but that is a limitation of that particular URI. We = never set that limit for URNs. In other words, the rough consensus from = back then was Julian is right, that ALL URIs identify 'resources' by = definition. Merely being identified by a URI _makes_ it a resource. wow=85 that made me feel ten years younger! ;-) -MM On Jan 9, 2013, at 11:05 AM, Keith Moore = wrote: > On 01/09/2013 11:00 AM, Julian Reschke wrote: >>>> "This specification does not limit the scope of what might be a >>>> resource; rather, the term "resource" is used in a general sense = for >>>> whatever might be identified by a URI." -- >>>> >>>>=20 >>>> Case closed. >>> yes, but it didn't anticipate that URNs would be widely used to not = name >>> resources at all. >>>=20 >>> again, most such uses do little harm. but that's not an argument = for >>> perverting URNs to be just >>> random numbers instead of resource identifiers. >>> ... >>=20 >> My point being: they *are* resource identifiers. > Only if they actually identify resources. >=20 > Keith >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From julian.reschke@gmx.de Wed Jan 9 08:23:34 2013 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 BCA3E21F8615 for ; Wed, 9 Jan 2013 08:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.339 X-Spam-Level: X-Spam-Status: No, score=-103.339 tagged_above=-999 required=5 tests=[AWL=-0.740, 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 lB1wC-+LEmBQ for ; Wed, 9 Jan 2013 08:23:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2888321F84BB for ; Wed, 9 Jan 2013 08:23:28 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MP3Jh-1TwXKm1z8x-006OKi for ; Wed, 09 Jan 2013 17:23:23 +0100 Received: (qmail invoked by alias); 09 Jan 2013 16:23:23 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 09 Jan 2013 17:23:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/G6AUh1v/GzJStWFyEPrSBqc1MBaFCo43cjVu2Jy E0GypFedzs+AJf Message-ID: <50ED9978.8080904@gmx.de> Date: Wed, 09 Jan 2013 17:23:20 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Michael Mealling References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: urn@ietf.org, Keith Moore 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: Wed, 09 Jan 2013 16:23:34 -0000 On 2013-01-09 17:19, Michael Mealling wrote: > Is it really 1999 all over again? Maybe I should by come CMGI stock. > > With a couple of noted exceptions this is one area where the W3C and the IETF's URN group agreed: That the definition of 'resource' is the thing identified by a URI. That minting any URI immediately causes its resource to come into being in the abstract. Some URI scheme specifications can restrict that it limits resource to be sequences of bits on a network but that is a limitation of that particular URI. We never set that limit for URNs. In other words, the rough consensus from back then was Julian is right, that ALL URIs identify 'resources' by definition. Merely being identified by a URI _makes_ it a resource. > > wow… that made me feel ten years younger! ;-) > > -MM Me too :-) From moore@network-heretics.com Wed Jan 9 08:31:10 2013 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 A760A21F86F7 for ; Wed, 9 Jan 2013 08:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 CYgn27KvTgCh for ; Wed, 9 Jan 2013 08:31:09 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 63D7721F86C1 for ; Wed, 9 Jan 2013 08:31:09 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0632D20AE4; Wed, 9 Jan 2013 11:31:09 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 09 Jan 2013 11:31:09 -0500 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=gMMn+orWPtcDy147zO8buj B3nrU=; b=u7DoA9z7BZtaaCQmNVfuhp3vIad+CrEVkelaDyUR9VpHKn0hqgzpqA 8UGo1kk28B/puN6FG0NGBmiiaIUzKJ3JS+ITvRRq1rE3H4OC0CZXukfed014eU14 Fqn7IcVP3Gu4ELcmno4yf6lVYXoiXsKsYXGyuZeV2WsWssQAXstf4= X-Sasl-enc: 6WZjXnefGzeTUhV2yevlXpfAFirWeOcHrdSrMXdtinKf 1357749068 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A0448E07A0; Wed, 9 Jan 2013 11:31:08 -0500 (EST) Message-ID: <50ED9B48.7020604@network-heretics.com> Date: Wed, 09 Jan 2013 11:31:04 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Mealling References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , 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: Wed, 09 Jan 2013 16:31:10 -0000 On 01/09/2013 11:19 AM, Michael Mealling wrote: > Is it really 1999 all over again? Maybe I should by come CMGI stock. > > With a couple of noted exceptions this is one area where the W3C and the IETF's URN group agreed: That the definition of 'resource' is the thing identified by a URI. That minting any URI immediately causes its resource to come into being in the abstract. Some URI scheme specifications can restrict that it limits resource to be sequences of bits on a network but that is a limitation of that particular URI. We never set that limit for URNs. In other words, the rough consensus from back then was Julian is right, that ALL URIs identify 'resources' by definition. Merely being identified by a URI _makes_ it a resource. It's the cases where there is no "it" that concern me. People seem to have gotten the idea that URNs aren't resource identifiers, but rather, nonces. Keith From julian.reschke@gmx.de Wed Jan 9 08:42:05 2013 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 B7F9921F84EB for ; Wed, 9 Jan 2013 08:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.024 X-Spam-Level: X-Spam-Status: No, score=-104.024 tagged_above=-999 required=5 tests=[AWL=-1.425, 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 TgoK06aTS6DL for ; Wed, 9 Jan 2013 08:42:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id DCB0B21F84D1 for ; Wed, 9 Jan 2013 08:42:04 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MQKg6-1TPN1k0R48-00TjF0 for ; Wed, 09 Jan 2013 17:42:04 +0100 Received: (qmail invoked by alias); 09 Jan 2013 16:42:03 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp030) with SMTP; 09 Jan 2013 17:42:03 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/gdnNatpfg8lNUtME0xY0Pgf57Ojs6qnSd38mxJd JJj8iIukQr6tEx Message-ID: <50ED9DD9.5030303@gmx.de> Date: Wed, 09 Jan 2013 17:42:01 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Keith Moore References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> <50ED9B48.7020604@network-heretics.com> In-Reply-To: <50ED9B48.7020604@network-heretics.com> Content-Type: text/plain; charset=windows-1252; 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: Wed, 09 Jan 2013 16:42:06 -0000 On 2013-01-09 17:31, Keith Moore wrote: > On 01/09/2013 11:19 AM, Michael Mealling wrote: >> Is it really 1999 all over again? Maybe I should by come CMGI stock. >> >> With a couple of noted exceptions this is one area where the W3C and >> the IETF's URN group agreed: That the definition of 'resource' is the >> thing identified by a URI. That minting any URI immediately causes its >> resource to come into being in the abstract. Some URI scheme >> specifications can restrict that it limits resource to be sequences of >> bits on a network but that is a limitation of that particular URI. We >> never set that limit for URNs. In other words, the rough consensus >> from back then was Julian is right, that ALL URIs identify 'resources' >> by definition. Merely being identified by a URI _makes_ it a resource. > > It's the cases where there is no "it" that concern me. People seem to > have gotten the idea that URNs aren't resource identifiers, but rather, > nonces. > > Keith There is no such case. Somebody mints a UUID for *something*, and at that point there is a "it". It's just not resolvable/testable. Best regards, Julian From moore@network-heretics.com Wed Jan 9 08:51:32 2013 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 5A05721F871D for ; Wed, 9 Jan 2013 08:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 bXGlKZHKWsCG for ; Wed, 9 Jan 2013 08:51:29 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8D53421F8703 for ; Wed, 9 Jan 2013 08:51:29 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 289B62040D; Wed, 9 Jan 2013 11:51:29 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 09 Jan 2013 11:51:29 -0500 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=bdNVM1u9m+ZfcorJWS1Zr/ sOMNE=; b=bubOX7QpcWrsnqLOJEhkRClPVyZ6dOkdLtxS3Xe90d/ZUMsusvJmts DmPY/PiKPvSVmnUj/V1EYpTFISBeV2ze1Sk6QTqcTSvcBCcg14XymQgXh8R81yV1 nm0PBAn6LKMaK2WJHbX/RhXXNjk3j4ViStlmNj/YspVhc8KHpr4Ws= X-Sasl-enc: Va4pC9T+pkMU84ALMQQJMAM30itlB6qcHuGqwfucNNFg 1357750288 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 5CA56482615; Wed, 9 Jan 2013 11:51:28 -0500 (EST) Message-ID: <50EDA00C.6080401@network-heretics.com> Date: Wed, 09 Jan 2013 11:51:24 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Julian Reschke References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> <50ED9B48.7020604@network-heretics.com> <50ED9DD9.5030303@gmx.de> In-Reply-To: <50ED9DD9.5030303@gmx.de> Content-Type: text/plain; charset=windows-1252; 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: Wed, 09 Jan 2013 16:51:33 -0000 On 01/09/2013 11:42 AM, Julian Reschke wrote: >> It's the cases where there is no "it" that concern me. People seem to >> have gotten the idea that URNs aren't resource identifiers, but rather, >> nonces. >> >> Keith > > There is no such case. Somebody mints a UUID for *something*, and at > that point there is a "it". It's just not resolvable/testable. Not so. Just because someone mints a UUID doesn't mean that there is an it. The whole point of URNs is that the relationship between the name, and the thing that is named by the name, cannot change. If this relationship between the name and the thing that is named isn't explicit, no such assurance can be made, and it's not appropriate to use a URN. Keith From julian.reschke@gmx.de Wed Jan 9 09:08:41 2013 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 234EB21F8615 for ; Wed, 9 Jan 2013 09:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.866 X-Spam-Level: X-Spam-Status: No, score=-103.866 tagged_above=-999 required=5 tests=[AWL=-1.267, 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 byrT7B1R1KrF for ; Wed, 9 Jan 2013 09:08:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id DE76C21F8610 for ; Wed, 9 Jan 2013 09:08:39 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LhQh4-1TFEXu0saW-00mdOi for ; Wed, 09 Jan 2013 18:08:38 +0100 Received: (qmail invoked by alias); 09 Jan 2013 17:08:38 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 09 Jan 2013 18:08:38 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19H1h9DbVNHgl7dd+t/rfT2KP9RUDh5pU8jzHzG2W rRzT05TosguMGp Message-ID: <50EDA413.3060107@gmx.de> Date: Wed, 09 Jan 2013 18:08:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Keith Moore References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> <50ED9B48.7020604@network-heretics.com> In-Reply-To: <50ED9B48.7020604@network-heretics.com> Content-Type: text/plain; charset=windows-1252; 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: Wed, 09 Jan 2013 17:08:41 -0000 On 2013-01-09 17:31, Keith Moore wrote: > On 01/09/2013 11:19 AM, Michael Mealling wrote: >> Is it really 1999 all over again? Maybe I should by come CMGI stock. >> >> With a couple of noted exceptions this is one area where the W3C and >> the IETF's URN group agreed: That the definition of 'resource' is the >> thing identified by a URI. That minting any URI immediately causes its >> resource to come into being in the abstract. Some URI scheme >> specifications can restrict that it limits resource to be sequences of >> bits on a network but that is a limitation of that particular URI. We >> never set that limit for URNs. In other words, the rough consensus >> from back then was Julian is right, that ALL URIs identify 'resources' >> by definition. Merely being identified by a URI _makes_ it a resource. > > It's the cases where there is no "it" that concern me. People seem to > have gotten the idea that URNs aren't resource identifiers, but rather, > nonces. Well. Your use of the term "resource" is in conflict with the RFC 3986 definition. I could ask you for your definition but I fear we'll end up with totally pointless philosophical discussion :-) Best regards, Julian From derhoermi@gmx.net Wed Jan 9 15:50:07 2013 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 055AB21F8495 for ; Wed, 9 Jan 2013 15:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 EB5BO+Jx-NdQ for ; Wed, 9 Jan 2013 15:50:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 36F9821F8481 for ; Wed, 9 Jan 2013 15:50:03 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.28]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MNO9n-1TvaVs36jp-006zw1 for ; Thu, 10 Jan 2013 00:50:01 +0100 Received: (qmail invoked by alias); 09 Jan 2013 23:50:01 -0000 Received: from p5B063D83.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.6.61.131] by mail.gmx.net (mp028) with SMTP; 10 Jan 2013 00:50:01 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/m5lpr3MrmNqC3uSLlveFs7potDQnCpvCWBBDp+C OpoepdNtuor6Sp From: Bjoern Hoehrmann To: Michael Mealling Date: Thu, 10 Jan 2013 00:50:01 +0100 Message-ID: <3g0se8tkctkt904aem2jh7k4c8mmepl2rm@hive.bjoern.hoehrmann.de> References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Julian Reschke , urn@ietf.org, Keith Moore 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: Wed, 09 Jan 2013 23:50:07 -0000 * Michael Mealling wrote: >Is it really 1999 all over again? We did warn you about the Y2K bug... -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From masinter@adobe.com Sat Jan 12 09:04:50 2013 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 8E91621F868F for ; Sat, 12 Jan 2013 09:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, 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 aEh8MSt-6g31 for ; Sat, 12 Jan 2013 09:04:50 -0800 (PST) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7593321F84EB for ; Sat, 12 Jan 2013 09:04:48 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUPGXrOnupVgCI9BwBlfvPdqn/x2Lfgid@postini.com; Sat, 12 Jan 2013 09:04:49 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r0CH4hC9020887; Sat, 12 Jan 2013 09:04:43 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r0CH4gXL017294; Sat, 12 Jan 2013 09:04:42 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sat, 12 Jan 2013 09:04:41 -0800 From: Larry Masinter To: "julian.reschke@gmx.de" , Keith Moore Date: Sat, 12 Jan 2013 09:04:37 -0800 Thread-Topic: [urn] I-D Action: draft-saintandre-urn-example-00 Thread-Index: Ac3ugNqbHIS1741YQKyLGZhifK/NZgCZdz5Q Message-ID: References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> In-Reply-To: <50ED9168.6050000@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.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: Sat, 12 Jan 2013 17:04:50 -0000 T2xkIHRocmVhZCBmYW5zIC0tIHJlc291cmNlcyBhcmUgYW5nZWxzOg0KDQpodHRwOi8vbWFzaW50 ZXIuYmxvZ3Nwb3QuY29tLzIwMTAvMDMvcmVzb3VyY2VzLWFyZS1hbmdlbHMtdXJscy1hcmUtcGlu cy5odG1sIA0KDQo= From masinter@adobe.com Sat Jan 19 08:27:43 2013 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 E3E2C21F8233 for ; Sat, 19 Jan 2013 08:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, 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 SEW5Q0anfxnM for ; Sat, 19 Jan 2013 08:27:43 -0800 (PST) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB1521F8202 for ; Sat, 19 Jan 2013 08:27:42 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUPrJeqiSpdMzY/9z23nxJvGCqpNylgmq@postini.com; Sat, 19 Jan 2013 08:27:42 PST Received: from inner-relay-1.corp.adobe.com (inner-relay-1.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r0JGRaC9021839; Sat, 19 Jan 2013 08:27:36 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r0JGRZAV015670; Sat, 19 Jan 2013 08:27:35 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Sat, 19 Jan 2013 08:27:35 -0800 From: Larry Masinter To: Keith Moore , "julian.reschke@gmx.de" Date: Sat, 19 Jan 2013 08:27:31 -0800 Thread-Topic: [urn] I-D Action: draft-saintandre-urn-example-00 Thread-Index: Ac3uiZlmpegepsZhTzu/hlXg/emPKAH1XmqA Message-ID: References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> <50ED9B48.7020604@network-heretics.com> <50ED9DD9.5030303@gmx.de> <50EDA00C.6080401@network-heretics.com> In-Reply-To: <50EDA00C.6080401@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.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: Sat, 19 Jan 2013 16:27:44 -0000 For my part, the only way I can make peace with URNs is to take the perspec= tive that "persistence" is wishful thinking, that "resource" is a myth, and= that the primary use for URNs is a way of importing into the space of URIs= those identifiers that are maintained by other organizations (namely, the = "naming authority"). Of course, you should only use naming authorities who can offer a credible = promise of persistence of the association of the name to the thing named, b= ut each service makes its own guarantees. IETF offers that "STD 66" names s= omething, even if the document changes, and that "RFC 3986" names something= which is currently the same document. But that also what it names is somew= hat independent of the format it's set in, or the location. This description of URNs doesn't require anyone to believe in Resources or = that URNs Name them, or that they do so Uniformly. It explains _most_ of t= he URN namespaces.=20 The only problem is the darn urn:uuid: namespace, where "uuid" is not an au= thority at all, and there's nowhere to turn to figure out who might have kn= own at any point in time what was meant by it. I don't know what to do with= urn:uuid except to declare it a mistake. Larry -- http://larry.masinter.net > -----Original Message----- > From: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] On Behalf Of Kei= th > Moore > Sent: Wednesday, January 09, 2013 5:51 PM > To: julian.reschke@gmx.de > Cc: urn@ietf.org > Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00 >=20 > On 01/09/2013 11:42 AM, Julian Reschke wrote: > >> It's the cases where there is no "it" that concern me. People seem t= o > >> have gotten the idea that URNs aren't resource identifiers, but rather= , > >> nonces. > >> > >> Keith > > > > There is no such case. Somebody mints a UUID for *something*, and at > > that point there is a "it". It's just not resolvable/testable. > Not so. Just because someone mints a UUID doesn't mean that there is an > it. >=20 > The whole point of URNs is that the relationship between the name, and > the thing that is named by the name, cannot change. If this > relationship between the name and the thing that is named isn't > explicit, no such assurance can be made, and it's not appropriate to use > a URN. >=20 > Keith >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From moore@network-heretics.com Sun Jan 20 20:19:47 2013 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 32D8C21F8629 for ; Sun, 20 Jan 2013 20:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 Hwu3ktAAVFv6 for ; Sun, 20 Jan 2013 20:19:46 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2E59B21F8457 for ; Sun, 20 Jan 2013 20:19:43 -0800 (PST) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 667092089F for ; Sun, 20 Jan 2013 23:19:42 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 20 Jan 2013 23:19:42 -0500 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=mxyk0Ck39PP3Qbpx/ovR+Q QY/F0=; b=c8C17+2i624GZBUGykPpww8KZcm+NCKYtiog06JKJYV3y23o5P9UCY QCdkc1Yp6l6xaA/Cn2wATALrRRfXwsdX8I/MwWaOqpX2mU+2QMrEasPGDEYA3H3V RYkzqe17E5+r8eSPImG/LHhRsKhqyUG8WKUVB9cqZwjer6H1jNGbQ= X-Sasl-enc: Zcmd11+K3GEDYAsx1UEe+72bicUqmd4axSYGiBAxG1SA 1358741981 Received: from [172.19.131.95] (unknown [12.130.123.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 5DF1D48279B; Sun, 20 Jan 2013 23:19:41 -0500 (EST) Message-ID: <50FCC1E1.3040803@network-heretics.com> Date: Sun, 20 Jan 2013 23:19:45 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: urn@ietf.org References: <201208162101.XAA08756@TR-Sys.de> <502DF26E.3050406@gmx.de> <50EB1560.3060602@stpeter.im> <50ECF1CC.6030208@network-heretics.com> <50ED9168.6050000@gmx.de> <50ED93E2.9040002@network-heretics.com> <50ED9430.4040606@gmx.de> <50ED952C.8080704@network-heretics.com> <50ED9B48.7020604@network-heretics.com> <50ED9DD9.5030303@gmx.de> <50EDA00C.6080401@network-heretics.com> 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 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: Mon, 21 Jan 2013 04:19:47 -0000 On 01/19/2013 11:27 AM, Larry Masinter wrote: > For my part, the only way I can make peace with URNs is to take the perspective that "persistence" is wishful thinking, that "resource" is a myth, and that the primary use for URNs is a way of importing into the space of URIs those identifiers that are maintained by other organizations (namely, the "naming authority"). Which of course has nothing to do with the purpose of URNs. > Of course, you should only use naming authorities who can offer a credible promise of persistence of the association of the name to the thing named, but each service makes its own guarantees. IETF offers that "STD 66" names something, even if the document changes, and that "RFC 3986" names something which is currently the same document. But that also what it names is somewhat independent of the format it's set in, or the location. > > This description of URNs doesn't require anyone to believe in Resources or that URNs Name them, or that they do so Uniformly. It explains _most_ of the URN namespaces. No it doesn't. it's just a mostly-coincidental characteristic of some URNs. > The only problem is the darn urn:uuid: namespace, where "uuid" is not an authority at all, and there's nowhere to turn to figure out who might have known at any point in time what was meant by it. I don't know what to do with urn:uuid except to declare it a mistake. That might not be a bad idea, but not for the reason you cite. To attempt to define what URNs are in terms of what you observe about URNs is to attempt to destroy their utility. Keith