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
- [urn] URN:META namespace registration request Hakala, Juha E
- Re: [urn] URN:META namespace registration request Henry S. Thompson
- Re: [urn] URN:META namespace registration request Hakala, Juha E
- Re: [urn] URN:META namespace registration request Dale R. Worley
- Re: [urn] URN:META namespace registration request Hakala, Juha E
- Re: [urn] URN:META namespace registration request Hakala, Juha E
- Re: [urn] URN:META namespace registration request Dale R. Worley
- Re: [urn] URN:META namespace registration request worley
- Re: [urn] URN:META namespace registration request Hakala, Juha E