Re: [urn] URN:META namespace registration request

worley@ariadne.com Fri, 06 March 2020 04:07 UTC

Return-Path: <worley@alum.mit.edu>
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 52DE83A12C4 for <urn@ietfa.amsl.com>; Thu, 5 Mar 2020 20:07:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.983
X-Spam-Level:
X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 IklJlssvb8aA for <urn@ietfa.amsl.com>; Thu, 5 Mar 2020 20:07:02 -0800 (PST)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8C03A12C3 for <urn@ietf.org>; Thu, 5 Mar 2020 20:07:02 -0800 (PST)
Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id A4BBjp03tQWuCA4GKjgqMj; Fri, 06 Mar 2020 04:07:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1583467620; bh=fO5rVpTzQzRmycNE+wKNZiMcxeqtibRLVHinDcPry9w=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=GjwDqxM7lfoY1njN1trxUbH1yUQQsPtHaqEQgwumq3J3RzGynawRvddiAm5YVHpf8 x5eSg+lPno0YRooVVSIqiI8xfkH1oFdy8UWx7k/rJV21v0KVt2b7RrDSuC+kNn+dZP SbUlBu1+A70v5z8Rso/5Ufz9zEsodl/4DT6eJDdUMRpzXWV/lsNGrls1xaV8HdaNeN eqXaQphum1NsIJ2cR9SfyHztsnZlh8YNB2n14iN3YHcpIlQwhaKWiZ7J1Se/NlegrU kjmDXoav1vDRFgVKT0b2P28yTiymtJHtxb9CQkP6qPEsjQP0Am/CsTVt9sBG52+xUa BP16huCo2Zhtg==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:c190:222:fbff:fe91:d396]) by resomta-ch2-05v.sys.comcast.net with ESMTPA id A4GIjYB8cbBT8A4GIjr9t4; Fri, 06 Mar 2020 04:06:59 +0000
X-Xfinity-VMeta: sc=0.00;st=legit
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 02646v18032443; Thu, 5 Mar 2020 23:06:57 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 02646teb032431; Thu, 5 Mar 2020 23:06:55 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: juha.hakala@helsinki.fi, paul@paulwalk.net, osma.suominen@helsinki.fi, klensin@jck.com, tom@tombaker.org, urn@ietf.org
In-Reply-To: <875zfqaz2q.fsf@hobgoblin.ariadne.com> (worley@ariadne.com)
Sender: worley@ariadne.com
Date: Thu, 05 Mar 2020 23:06:55 -0500
Message-ID: <87imji9leo.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/uWg9Bw4aZBSHGrYu4eic0zG91og>
Subject: Re: [urn] URN:META namespace registration request
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 06 Mar 2020 04:07:05 -0000

I probably ought to give some motivation for writing so much about
resolution mechanisms in my recent review.  My impression, upon reading
the second version, was that the resolution mechanism was truly an
important part of this proposal, as that's the real value-added for
using URN's to identify metadata fields.  And the long series of
examples at the end seems to be about resolving URNs.

And in that regard, all the words I added about resolver base URLs is
enunciating the infrastructure that the examples seem to be
presupposing.

It is an extension to state that resolver base URLs need to be
registered with the National Library of Finland.  But really, you can't
make the resolution services work unless there's a central point for
distributing what the resolvers are.  And the National Library is
already handling the bookkeeping for these URNs.

There's one further point.  I have a sense I've seen some discussion of
it, but I can't remember the details.  So you may have already sent a
response to this.  The point is that the grammar for URN:META is

    meta-nss    = prefix "-" meta-string

    prefix      = format-code *( ":" subspc )

However, the general usage in URNs is that colons are "higher-level"
separators than hyphens.  So the more expected grammar is

    meta-nss    = prefix ":" meta-string

    prefix      = format-code *( "-" subspc )

which gives examples like "urn:meta:dc-new:title".

And indeed, the examples written in the second version have the latter
format, not the format documented in the draft.

Dale