Re: request for assignment of informal urn

worley@ariadne.com (Dale R. Worley) Mon, 23 February 2015 03:58 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 DBB981A0167 for <urn-nid@ietfa.amsl.com>; Sun, 22 Feb 2015 19:58:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.799
X-Spam-Level: *
X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 l8z0ubsDZUD4 for <urn-nid@ietfa.amsl.com>; Sun, 22 Feb 2015 19:58:37 -0800 (PST)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [69.252.207.43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE611A00F0 for <urn-nid@apps.ietf.org>; Sun, 22 Feb 2015 19:58:37 -0800 (PST)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-11v.sys.comcast.net with comcast id vfyX1p0022Udklx01fybfT; Mon, 23 Feb 2015 03:58:35 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-18v.sys.comcast.net with comcast id vfya1p0011KKtkw01fyawL; Mon, 23 Feb 2015 03:58:35 +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 t1N3wW1x010531; Sun, 22 Feb 2015 22:58:32 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id t1N3wUVM010528; Sun, 22 Feb 2015 22:58:30 -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: <54E7F813.8010201@andyet.net> (peter@andyet.net)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Sun, 22 Feb 2015 22:58:30 -0500
Message-ID: <87k2z9b7o9.fsf@hobgoblin.ariadne.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1424663915; bh=+2PBViBeZQ3R9tIHUSyJSmWhNGQ4G63+eaDmc+T8FOo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=QIUCBoyb10fqIAcWpr1wvEt4aVv+n0FtYfJeOiJVOKWAZmqpMAZgFe6qeQJe9kWdi 5mUoeNCXuzRz2t5mJLwewRdDql09gmF1F/J+kftR9s+InOFuAUMMXwwY6dDkij79Pi mlZNCDI4lyKnu9EbqBqvTlWmQ8BeG8qUwOxRKz6ZCjV/jRDEcmWpA56Lg7912Hjr7n GSIIWH+2vgkcKbciRlLObWehYJW++9BieAK31diiWnciYABj7Jywo42/BIqq7E2L97 1a/6QdvMMEOsvKMa/QFWqOZpREvHoVacjFMBhQSKjxArSconegSYdUB2Rtb3q3F8R9 sTGZwFgoCDFeg==
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/iGGuFwQxUOjGRH5mC4_CWqqw8QU>
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, 23 Feb 2015 03:58:39 -0000

IMHO, the correct way to handle fragment identifiers is to ignore the
fact that the URN syntax doesn't permit them.  The two main reasons for
that are (1) work is underway to allow specifying fragment identifiers
with URNs, and (2) by analogy with all other URIs, everyone knows how
they'll work syntactically.  A more subtle reason is (3) the fragment
identifier can be semantically separated from the "base" URN, in that
the definition of the URN namespace tells how to map the URN into a
"resource", and the resource itself determines how the fragment
identifier is to be interpreted.

Within that framework, the politics of the situation is much improved if
the namespace doesn't explicitly define fragment identifiers as part of
the syntax, and the practice is implicitly what everybody expects
already.

But it's not clear why a new namespace is needed -- instead of defining
one namespace which is semantically the disjoint union of ISBNs and
UUIDs, instead have the set of admissible URNs be the (intrinsically
disjoint) union of ISBN and UUID URNs.

The only reason I can see for a new namespace is if the process by which
a fragment identifier is applied to a resource is determined not by the
resource itself but by the namespace definition.  That is,
"urn:isbn:0-345-33971-1#epubcfi(/6/4[chap01ref]!/4[body01]/16[svgimg])"
might mean something different than
"urn-NNN:isbn:0-345-33971-1#epubcfi(/6/4[chap01ref]!/4[body01]/16[svgimg])"
even though they both intrinsically refer to fragments within the "book"
that has the ISBN 0-345-33971-1.

Dale