Re: [urn] URN fragments

Peter Saint-Andre <stpeter@stpeter.im> Fri, 22 February 2013 03:37 UTC

Return-Path: <stpeter@stpeter.im>
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 C947821E8054 for <urn@ietfa.amsl.com>; Thu, 21 Feb 2013 19:37:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Level:
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UZUv6Wy3KYG for <urn@ietfa.amsl.com>; Thu, 21 Feb 2013 19:37:06 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 029CA21E803D for <urn@ietf.org>; Thu, 21 Feb 2013 19:37:06 -0800 (PST)
Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 773A54060C; Thu, 21 Feb 2013 20:44:38 -0700 (MST)
Message-ID: <5126E7D6.6050301@stpeter.im>
Date: Thu, 21 Feb 2013 20:36:54 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Juha Hakala <juha.hakala@helsinki.fi>
References: <512606BC.7020902@helsinki.fi>
In-Reply-To: <512606BC.7020902@helsinki.fi>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] URN fragments
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 22 Feb 2013 03:37:11 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/21/13 4:36 AM, Juha Hakala wrote:
> Hello Peter; all,
> 
> Concerning this:
>> Could you also explain (perhaps in a separate thread) the
>> intended use of the fragment identifier?
> It took a while before the bibliographic community got a
> sufficient grasp of how fragment can best be used in the URN
> context. Initially we thought that fragment should be part of the
> URN namespace specific string, but we realized soon that that would
> complicate things a lot. Since many (most, probably) standard
> namespaces do not allow add-ons to identifier strings, this:
> 
> Ex. 1http://urn.fi/URN:ISBN:978-952-10-7670-1
> 
> would have been possible, but not this (NOTE: this is only an
> example)
> 
> Ex. 2http://urn.fi/URN:ISBN:978-952-10-7670-1#chapter2
> 
> Moreover, adding a fragment to an existing URN would in this case
> have been an act of identifier assignment, which in some namespaces
> is a managed process, so too few people would have been allowed to
> use fragments with URNs.
> 
> Eventually Alfred Hoenes, myself and others concluded that the
> best solution is to separate identification & URN assignment from
> fragment assignment, that is, not to include fragment in the NSS.
> Which means that fragments can be added to the URN by anybody, any
> time after the URN has been assigned and the document made
> available (via URN resolution) in the Internet.

Hi Juha, this model sounds similar to what you described for the query
component: the fragment can be "added to the URN". I'm not sure what
that means. When you add a query component or a fragment identifier to
the URN, is that now a different URN (which wasn't assigned by the
minting organization or in accordance with the minting algorithm)? Or
is "a URN with some additional data appended" and therefore not really
a URN anymore? Or is actually a URI (such as an HTTP URI) whose path
is the URN itself as just a string of characters embedded in the
broader URI?

Still confused,

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJufWAAoJEOoGpJErxa2pijYP/1Fq0JUQmr4r3oZg7rumqYB8
Y37kB4Um6e1/D/AYyMuebICyWU3dIIO5RckEr5Di+n15xMk3zREsIbbdvFWeKlIh
/hX1LFPLEbqqlvG85GqSC9T2RA0uJE1mtX2NuJPoij6OkxfsPfzaiTI3eDbujTpA
4BUjiV3w53JHvwnAvkGZn/zwbzxColQayMAW4Mq2ivsnY8Xm+mCPPiIz8poiLekL
fW0yCJl68wRfFM1hfs3w/NPMgphoMkmaX7F8FZScFH8WZjuz+/6tlcwbss9m79iL
jTYQ/W4QlwD7KaxKtnhi3bKwaofEtaiPlW/Z3+VDrHGHxxjxh09kciluQ/zIIRsl
7F05ujTM+hWV2KnohOnrcWq7qEA2M0XXCFfuN7rOxtjefSu8o2RPTuF8Bjvr1Yh5
gUxvXuBf1SIyOvzcsDDkMBw7/9zC2JmWfF3UiKBXurSbjrdJPQ6KjF9pQ2fTrai0
04os0sCMNNuqbUI3aL5zUZCibS4RNQRgjywGnkpnnp8YW7Txm3nYmsdBXP1CUfEt
xy6gvdPfBDFSnBpBIROZ5Cz3HbLoD/waXM4HaNUgv2b8h4crXTnmy5Goq8gU+nBY
fRC/lB8XCHFy3a5JRW61PXNey8O7J2zsi/ifcPocw7y5yi/GvGDOIVOMzR3wgGy4
9p+yG1IDbBxifHOy77j/
=Zpj0
-----END PGP SIGNATURE-----