Re: [urn] URN fragments

jehakala@mappi.helsinki.fi Thu, 21 February 2013 14:52 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 54F1F21F8DFB for <urn@ietfa.amsl.com>; Thu, 21 Feb 2013 06:52:46 -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 Iv4M-hkX5U19 for <urn@ietfa.amsl.com>; Thu, 21 Feb 2013 06:52:45 -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 DD93821F8DC9 for <urn@ietf.org>; Thu, 21 Feb 2013 06:52:34 -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 r1LEqVG4030755; Thu, 21 Feb 2013 16:52:31 +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; Thu, 21 Feb 2013 16:52:31 +0200
Date: Thu, 21 Feb 2013 16:52:31 +0200
Message-ID: <20130221165231.Horde.u5Xz5_PLrvIpUNgzZbmThw4.jehakala@webmail.helsinki.fi>
From: jehakala@mappi.helsinki.fi
To: Jonathan A Rees <rees@mumble.net>
References: <512606BC.7020902@helsinki.fi> <CAGnGFM+xKsW1F+pbBbX-98dCDTLXFX3OpfZo_W3Re9KAc_piXQ@mail.gmail.com>
In-Reply-To: <CAGnGFM+xKsW1F+pbBbX-98dCDTLXFX3OpfZo_W3Re9KAc_piXQ@mail.gmail.com>
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: "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: Thu, 21 Feb 2013 14:52:46 -0000

Hello,

As I said, our conclusion has been that fragment is not part of the  
URN (NSS). Therefore the fragment semantics comes from RFC 3986 and  
nowhere else. Note however that we should not talk about fragment  
identifiers; fragment is just something that is attached to the  
identifier as a guideline to the browser to take the user into a given  
location within the resource.

If it were not possible to use fragment with URN, we might have two  
URIs (one URN and one URL) both resolving to the same resource  
(location), but it would only be OK to use fragment with the URL,  
although the fragment string would be exactly the same in both cases.  
I doubt this was the intention of RFC 3986.

In practice, people will attach fragments to URNs (when they are  
expressed as HTTP URIs). For these Internet users, this will be like  
using fragments with URLs. It is important to support them by  
explaining the rules of the game for them in RFC 2141.

Juha

Quoting Jonathan A Rees <rees@mumble.net>et>:

> On Thu, Feb 21, 2013 at 6:36 AM, Juha Hakala <juha.hakala@helsinki.fi>wrote;wrote:
>
>>  Hello Peter; all,
>>
>> When fragment usage was last discussed on the list, the IETF  
>> community disapproved of the idea (if I remember correctly) on the  
>> basis that URNs will not be bound to a single manifestation of a  
>> resource, such as a PDF version of a book. When the file format  
>> changes, the probability that the fragment no longer works is too  
>> close for comfort to 1.
>>
>> That is not my recollection. The problem with defining fragment ids in the
> urn: registration is that fragment id semantics comes from RFC 3986 and
> simply cannot be changed or overridden by any URI scheme registration.
> Quoth 3986:
>
>    Fragment identifier semantics are independent of the
>    URI scheme and thus cannot be redefined by scheme specifications.
>
> Jonathan