Re: [urn] URN fragments

Julian Reschke <julian.reschke@gmx.de> Tue, 26 February 2013 19:53 UTC

Return-Path: <julian.reschke@gmx.de>
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 7E19121F8727 for <urn@ietfa.amsl.com>; Tue, 26 Feb 2013 11:53:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.923
X-Spam-Level:
X-Spam-Status: No, score=-105.923 tagged_above=-999 required=5 tests=[AWL=-3.324, 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 Gm+E4Nx6785U for <urn@ietfa.amsl.com>; Tue, 26 Feb 2013 11:53:38 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id C67F421F871D for <urn@ietf.org>; Tue, 26 Feb 2013 11:53:23 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lbx7K-1UZtyB05Aa-00jGVH for <urn@ietf.org>; Tue, 26 Feb 2013 20:53:23 +0100
Received: (qmail invoked by alias); 26 Feb 2013 19:53:22 -0000
Received: from p5DD97B44.dip.t-dialin.net (EHLO [192.168.1.102]) [93.217.123.68] by mail.gmx.net (mp012) with SMTP; 26 Feb 2013 20:53:22 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+H7vQ4uReHRgvD6nLr6TJP2rmaVPkVYMiW3S4a8i 8e/kwqcQOspYK4
Message-ID: <512D12B0.4050304@gmx.de>
Date: Tue, 26 Feb 2013 20:53:20 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: jehakala@mappi.helsinki.fi
References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> <512716C6.4090308@helsinki.fi> <512CDC48.9070703@gmx.de> <512CEC80.8020702@stpeter.im> <20130226212621.Horde.y3L08bLxxMiNJYU7FS9abA1.jehakala@webmail.helsinki.fi>
In-Reply-To: <20130226212621.Horde.y3L08bLxxMiNJYU7FS9abA1.jehakala@webmail.helsinki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
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: Tue, 26 Feb 2013 19:53:38 -0000

On 2013-02-26 20:26, jehakala@mappi.helsinki.fi wrote:
> Hello,
>
> Quoting Peter Saint-Andre <stpeter@stpeter.im>im>:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 2/26/13 9:01 AM, Julian Reschke wrote:
>>> On 2013-02-22 07:57, Juha Hakala wrote:
>
>>>> Despite the addition of fragment and query the URN itself remains
>>>> the same, even though the HTTP URI changes. ...
>>>
>>> Well, it's a different string, thus a different URN.
>>
>> Correct. As Martin suggested, one might refer to the
>> organizationally-assigned or algorithmically-determined URN as an
>> "absolute URN", but that doesn't change the fact that absolute+query
>> or absolute+fragment is still a different URN.
>
> It is a different string, thus a different URI, as dictated by RFC 3986.
>
> But it is the same URN, since fragment is not part of the Namespace
> specific string, as specified by the Alfred Hoenes' version of the URN
> syntax, or any other syntax specification which approves the current
> idea that fragment is not part of the NSS. And we know already that
> incorporating the fragment into NSS would cause a lot of avoidable
> trouble (for instance, many namespaces could not use fragment at all).

I was actually talking about the query part; sorry for the confusion.

It's up to the URN or NIS syntax to describe what the query part means, 
and how it applies to different namespaces. But in *general*, adding a 
query part to a URI changes the resource being identified.

Best regards, Julian