Re: request for assignment of informal urn

worley@ariadne.com (Dale R. Worley) Sun, 01 March 2015 22:42 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02FE1A1BED for <urn-nid@ietfa.amsl.com>; Sun, 1 Mar 2015 14:42:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79ad4OgRf3KC for <urn-nid@ietfa.amsl.com>; Sun, 1 Mar 2015 14:42:04 -0800 (PST)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AD51A0015 for <urn-nid@apps.ietf.org>; Sun, 1 Mar 2015 14:42:03 -0800 (PST)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-06v.sys.comcast.net with comcast id yNhX1p00A2JGN3p01Ni3fU; Sun, 01 Mar 2015 22:42:03 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-10v.sys.comcast.net with comcast id yNi11p00T1KKtkw01Ni25W; Sun, 01 Mar 2015 22:42:03 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id t21Mg1ct012248; Sun, 1 Mar 2015 17:42:01 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id t21Mg04x012245; Sun, 1 Mar 2015 17:42:00 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Peter Saint-Andre - &yet <peter@andyet.net>
Subject: Re: request for assignment of informal urn
In-Reply-To: <54EE9E8F.1090907@andyet.net> (peter@andyet.net)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Sun, 01 Mar 2015 17:41:59 -0500
Message-ID: <87385o8hmw.fsf@hobgoblin.ariadne.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1425249723; bh=SPaGqceKa0PQPicXWJ3cUV5Yfr5lsEALUEmmEvMmurM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=POIskgSZeFjKul0R3VR/v8rjeLLjL7W7oBUzk8rYR9J3PHsdziSBETXWNbAkglS3J ojD7fDJyQ2Cex1pTDxcZf56QVsBZj8YvjTj0SMxmQJi7UzNbkDoqVR5Uzzd1rM7Ugz D4at03GQAtZb/VIyZVWWKKCIum4jMXDWKc9vJnIMEQlQg3jsaQCUlo6M+Zvw7J3mfP BZ42fmcrtmqEhcYxQi3Ht7Tzq/o7MzRE802HrE6LUbTY5vXkN9UkJiYpkuucWog8uK 5PHETtRD4901p9RXWqEt72F+TProdBaaaI1ll7HYlCdyqxWeBCrWgytSKgq0Rh3ilZ 8LiFV7rAMUxnA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/DQyTTYTgV9aHhy9chvQ25USRg6c>
Cc: tomohiro.misawa.rf@hitachi-solutions.com, urn-nid@apps.ietf.org, yoshiki.sameshima.vf@hitachi-solutions.com, takanobu.hosoe.ju@hitachi-solutions.com
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Mar 2015 22:42:04 -0000

Peter Saint-Andre - &yet <peter@andyet.net> writes:
> But fragment identifiers are disallowed by RFC 2141. This registration 
> can't go forward until the URNBIS work completes. At which point, I 
> think it would be better to define real namespaces (e.g., it's likely 
> that the ISBN namespace will be updated to allow f-components) instead 
> of forcing it into an informal namespace.

I don't see any truly good solutions to the requirements.  Of course,
the advice about participation is important.

But in this case, while perhaps path-components will be added to ISBN, I
doubt they'll be added to UUID.  Which leaves the authors with no good
way to represent what they want to represent.  It seems like the best
solution is to create an informal namespace now and then, some years
from now, when the problem space is better understood and we have
improved how URNs work, they can revisit and update their namespace(s)
and syntax.

As for fragment-components, my advice would be to omit them from the
namespace definition and then use them in practice.  This is because we
can predict what the syntax for fragment-components used with URNs will
be, so there's no danger that the non-standard usage will contradict
URNbis when it comes out.  So why delay getting this namespace into real
use?

Dale