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
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
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
- Re: request for assignment of informal urn yoshiki.sameshima.vf
- request for assignment of informal urn yoshiki.sameshima.vf
- Re: request for assignment of informal urn Dale R. Worley
- Re: request for assignment of informal urn Peter Saint-Andre - &yet
- Re: request for assignment of informal urn yoshiki.sameshima.vf
- Re: request for assignment of informal urn yoshiki.sameshima.vf
- Re: request for assignment of informal urn Peter Saint-Andre - &yet
- Re: request for assignment of informal urn Dale R. Worley
- Re: request for assignment of informal urn Peter Saint-Andre - &yet
- Re: Re: request for assignment of informal urn Dale R. Worley
- Re: request for assignment of informal urn Dale R. Worley