Re: [urn] URN fragments

Juha Hakala <juha.hakala@helsinki.fi> Fri, 22 February 2013 06:57 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 A62AF21F8F36 for <urn@ietfa.amsl.com>; Thu, 21 Feb 2013 22:57:17 -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 KcovSMp9gBu6 for <urn@ietfa.amsl.com>; Thu, 21 Feb 2013 22:57:17 -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 CCFEC21F8F35 for <urn@ietf.org>; Thu, 21 Feb 2013 22:57:15 -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 r1M6vBMe031654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 08:57:14 +0200
Message-ID: <512716C6.4090308@helsinki.fi>
Date: Fri, 22 Feb 2013 08:57:10 +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: Peter Saint-Andre <stpeter@stpeter.im>
References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im>
In-Reply-To: <5126E7D6.6050301@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
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 06:57:17 -0000

Hi,

On 22.2.2013 5:36, Peter Saint-Andre wrote:
> 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? 

Despite the addition of fragment and query the URN itself remains the 
same, even though the HTTP URI changes.

"Added to the URN" means that neither query nor fragment are part of the 
URN, or more specifically, its namespace specific string. When something 
is identified, more or less formally, the NSS is and must always be 
sufficient for that, and RFC 2141 does not provide any functionality 
beyond that. Full alignment with RFC 3986 would in this interpretation 
mean that once a resource has been identified with a URN, anybody can 
add a fragment to the URN in order to pinpoint a location within the 
resource (for the browsers to act upon), or a query to demand a service 
from the URN resolver.

Syntactically and semantically this interpretation should match the one 
in RFC 3986. Note that fragments do not identify anything since they are 
not part of the NSS. IMHO, since we must use RFC 3986 as the starting 
point it is not even appropriate to say that in the URN context fragment 
actually identifies something. So Peter's term "fragment identifier" 
above is not proper language :-).

One reason why we should clarify the usage of fragment and query in the 
URN context is that there is a need to explain which fragment + query 
combinations make sense. In principle, it is only possible to use 
fragment when the resource itself is requested. In practice, there may 
be namespaces or service environments in which the situation is or will 
be more complicated than that.

Juha

-- 

  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