Re: [urn] URN fragments

jehakala@mappi.helsinki.fi Tue, 26 February 2013 19:26 UTC

Return-Path: <jehakala@mappi.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 37CCE21F86C5 for <urn@ietfa.amsl.com>; Tue, 26 Feb 2013 11:26:39 -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=[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 D8hhVe6avnkg for <urn@ietfa.amsl.com>; Tue, 26 Feb 2013 11:26:34 -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 C365D21F87CC for <urn@ietf.org>; Tue, 26 Feb 2013 11:26:31 -0800 (PST)
Received: from localhost (webmail-5.mappi.helsinki.fi [128.214.20.189]) by smtp-rs2.it.helsinki.fi (8.13.8/8.13.8) with ESMTP id r1QJQLPx025847; Tue, 26 Feb 2013 21:26:21 +0200
Received: from a88-114-110-201.elisa-laajakaista.fi (a88-114-110-201.elisa-laajakaista.fi [88.114.110.201]) by webmail.helsinki.fi (Horde Framework) with HTTP; Tue, 26 Feb 2013 21:26:21 +0200
Date: Tue, 26 Feb 2013 21:26:21 +0200
Message-ID: <20130226212621.Horde.y3L08bLxxMiNJYU7FS9abA1.jehakala@webmail.helsinki.fi>
From: jehakala@mappi.helsinki.fi
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> <512716C6.4090308@helsinki.fi> <512CDC48.9070703@gmx.de> <512CEC80.8020702@stpeter.im>
In-Reply-To: <512CEC80.8020702@stpeter.im>
User-Agent: Internet Messaging Program (IMP) H5 (6.0.3)
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Cc: Julian Reschke <julian.reschke@gmx.de>, "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:26:39 -0000

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).

Of course this whole point is entirely theoretical. If IETF cannot  
live with the idea that URN and URN + fragment still identify the same  
thing and are in that sense the same URN, we can extend the syntax so  
that after NSS one can add fragment and / or query into the URN string  
itself. Then, but only then, URN and URN + fragment are different.  
Different in which way exactly should of course be discussed, and  
whatever we do with the chapter dealing with semantic equivalence in  
the URN syntax document. the text has to be drafted rather carefully  
so as to make it very clear to everyone what URNs identify. It is a  
bit alarming that even in this WG we tend to have diverse views on  
things - which may lead to dead ends that would have been avoidable.

It is important that IETF does develop URN syntax which is fully  
aligned with RFC 3986. Since there are no generally accepted  
guidelines on how to use fragment or query, people have been  
inventive. For instance in the Clarin project, "@" is used to indicate  
fragment (or part, as they call it). So a Handle

11858/1234@test=a

will be resolved to http://clarin.eu?test=a

But no other application but the Clarin Handle server will be able to  
process these Clarin Handles; all other systems out there would be  
perplexed by it. One might think of few reasons why creating this kind  
of URIs can be risky.

Juha



>
> 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/
>
> iQIcBAEBAgAGBQJRLOx/AAoJEOoGpJErxa2p9aMQAKoZUm0Uq0Sa0xQ23TsmKqhL
> i7C4PKkYJ8dpjKWJ65SVFTKn1jCr+td2oR+qNMny7MqGm58GTcmmkYmTPlCx39I8
> UhpAXw3jL9HXScLpdUCGtV3IPPuiMVT+FLHfqVdXm/sbew/ICe9KwDVmCYKEve0y
> fMzlW3PdQPPjncBjTFdHsPpmAVS/gn7NZ4sX7hD8q2bMn3Cym+bSjRRK8L4k/it8
> h+xGPOXi6waOE4EfZJcL2Sme+4u5uN98aSE6lBxa1J1J9L8ZzNU7z1hhdrv+iztH
> 1yT1QaS2jEj5uN7V8dhI6LkRf3yy883j8WKyBs4BvLYQG++C+hboQgyAuh/O7+O5
> LmHQtsLPQWjsNoawa2lceAs+MNcLVH3+PPkT6jJ3rxPDITYay/d/0Byr6SAPYs6Y
> mfiWg5w+1A69KSEu+n9nJnpPyqoUZBjJ8YfiiwIr1F/Ft1NjFD2+vpTKGFsj06Ry
> 0xwZH5WMinlpMhXLnztKvWBgx/9d0RbLlxsYNvzw7+v1NM0dMmaAWfmr90g1Xiyq
> h4t6RIaYRxkYsmEx3AEWDGw7jtV+rgUtI3Jf1qn8iS6R/BmIWYpyiKvuwVRu1Lke
> apGp7nFROuv7g2AntWPi7Ur8av6TfZijllcmKSwhxAVHeKj5JU+BHz+BeZvlN5js
> UbAwq+ORA7UFM8MtGlnR
> =EMFB
> -----END PGP SIGNATURE-----