Re: [urn] URN fragments

Juha Hakala <juha.hakala@helsinki.fi> Wed, 27 February 2013 07:03 UTC

Return-Path: <juha.hakala@helsinki.fi>
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 E908B21F853D for <urn@ietfa.amsl.com>; Tue, 26 Feb 2013 23:03:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 HKpa6oM--cSY for <urn@ietfa.amsl.com>; Tue, 26 Feb 2013 23:03:25 -0800 (PST)
Received: from smtp-rs2.it.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) by ietfa.amsl.com (Postfix) with ESMTP id 940C821F8534 for <urn@ietf.org>; Tue, 26 Feb 2013 23:03:23 -0800 (PST)
Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id r1R73KWT025572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Feb 2013 09:03:20 +0200
Message-ID: <512DAFB8.7070704@helsinki.fi>
Date: Wed, 27 Feb 2013 09:03:20 +0200
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
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> <512D12B0.4050304@gmx.de>
In-Reply-To: <512D12B0.4050304@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: jehakala@mappi.helsinki.fi, "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: Wed, 27 Feb 2013 07:03:27 -0000

Hello,

On 26.2.2013 21:53, Julian Reschke wrote:
>
>> 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.

You have to be careful with the word "identify" in the URN context.

 From the URN point of view, the resource identified does not change 
when a query is added, if queries are used to facilitate the services 
specified in RFC 2483. All these services are related to one and only 
one identified resource.  A user can request for instance the resource 
itself, metadata about it, its current URL or URLs, and so forth. In 
practice, HTTP URIs (locations) the URN resolves to and the things that 
are being retrieved change, but the resource identified by the (location 
independent) URN does not.

I suppose it will not be possible to prevent URN implementers from 
constructing systems in which query is used to enable identification of 
multiple resources using the "absolute" URN as the starting point. But 
if the URN syntax says that the query is not part of the namespace 
specific string, then such an URN implementation is violating the syntax 
specification. And IANA should not approve namespace registration 
requests which use query in such non-standard way.

If query were made part of the namespace specific string, we might end 
up discussing whether a resource can be identified both by its absolute 
URN and the absolute URN + query indicating URI to resource service. Or, 
if a metadata record describing a resource can be identified by the URN 
of the resource + query indicating URI to URC service. It might be a 
good idea to avoid such a debate.

All the best,

Juha
>
>
> Best regards, Julian


-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503)
  FIN-00014 Helsinki University
  tel +358 9 191 44293