Re: [urn] I-D Action: draft-saintandre-urn-example-00.txt

Peter Saint-Andre <stpeter@stpeter.im> Tue, 14 August 2012 15:47 UTC

Return-Path: <stpeter@stpeter.im>
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 <urn@ietfa.amsl.com>; 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 <urn@ietfa.amsl.com>; 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 <urn@ietf.org>; 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 <stpeter@stpeter.im>
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 <andy@hxr.us>
References: <20120731162051.14510.52208.idtracker@ietfa.amsl.com> <50180676.9090108@stpeter.im> <C1DB5D4B-B02D-4BCC-80AD-C84A55A8FDFD@hxr.us>
In-Reply-To: <C1DB5D4B-B02D-4BCC-80AD-C84A55A8FDFD@hxr.us>
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 <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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-----