Re: request for assignment of informal urn

<yoshiki.sameshima.vf@hitachi-solutions.com> Mon, 16 March 2015 08:47 UTC

Return-Path: <yoshiki.sameshima.vf@hitachi-solutions.com>
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 9930A1A1B5B for <urn-nid@ietfa.amsl.com>; Mon, 16 Mar 2015 01:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.208
X-Spam-Level: ****
X-Spam-Status: No, score=4.208 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG52BGzcJp8J for <urn-nid@ietfa.amsl.com>; Mon, 16 Mar 2015 01:47:48 -0700 (PDT)
Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 084451A1B25 for <urn-nid@apps.ietf.org>; Mon, 16 Mar 2015 01:47:47 -0700 (PDT)
Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 71FD7B1D384; Mon, 16 Mar 2015 17:47:46 +0900 (JST)
Received: from mfilter04.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id t2G8lklu009229; Mon, 16 Mar 2015 17:47:46 +0900
Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t2G8ljCP001161; Mon, 16 Mar 2015 17:47:46 +0900
Received: from gxml13a.ad.clb.hitachi.co.jp (unknown [158.213.157.129]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 06725140046; Mon, 16 Mar 2015 17:47:45 +0900 (JST)
Received: from [127.0.0.1] by gxml13a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 72G83B8O200006FCC; Mon, 16 Mar 2015 17:47:44 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: <XNM2$7$1$6$$4$8$2$A$5000205U550698ac@hitachi-solutions.com>
Content-Type: text/plain; charset=us-ascii
To: <worley@ariadne.com>
From: <yoshiki.sameshima.vf@hitachi-solutions.com>
Date: Mon, 16 Mar 2015 17:47:40 +0900
References: <54EE9E8F.1090907@andyet.net> <87385o8hmw.fsf@hobgoblin.ariadne.com>
Priority: normal
Importance: normal
Subject: =?ISO-2022-JP?B?UmU6IHJlcXVlc3QgZm9yIGFzc2lnbm1l?= =?ISO-2022-JP?B?bnQgb2YgaW5mb3JtYWwgdXJu?=
X400-Content-Identifier: X550698AC00000M
X400-MTS-Identifier: [/C=JP/ADMD=GMGROUP/PRMD=GMGROUP/;mta141503161747405O6]
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/34_0t9GPrK_sdEVt0BGPk-LghS0>
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: Mon, 16 Mar 2015 08:47:49 -0000

Dale and Peter,

We are wondering whether we should revise our registration proposal or
we should assume that our proposal was already turned down.
Your advice is greatly appreciated.

Best regards,
Yoshiki Sameshima

worley@ariadne.com wrote:
> 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
>