Re: [urn] URN fragments

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 22 February 2013 04:11 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 243EA21E804B for <urn@ietfa.amsl.com>; Thu, 21 Feb 2013 20:11:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.326
X-Spam-Level:
X-Spam-Status: No, score=-106.326 tagged_above=-999 required=5 tests=[AWL=-2.536, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 hki06oPLgIpl for <urn@ietfa.amsl.com>; Thu, 21 Feb 2013 20:11:01 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 448E221E803D for <urn@ietf.org>; Thu, 21 Feb 2013 20:11:00 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r1M4At2u009779 for <urn@ietf.org>; Fri, 22 Feb 2013 13:10:56 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2ae8_94cc_daa77f16_7ca5_11e2_900e_001d096c5782; Fri, 22 Feb 2013 13:10:54 +0900
Received: from [IPv6:::1] ([133.2.210.1]:60943) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S16391C9> for <urn@ietf.org> from <duerst@it.aoyama.ac.jp>; Fri, 22 Feb 2013 13:10:56 +0900
Message-ID: <5126EFC7.6080201@it.aoyama.ac.jp>
Date: Fri, 22 Feb 2013 13:10:47 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
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 04:11:08 -0000

On 2013/02/22 12:36, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/21/13 4:36 AM, Juha Hakala wrote:

>> Eventually Alfred Hoenes, myself and others concluded that the
>> best solution is to separate identification&  URN assignment from
>> fragment assignment, that is, not to include fragment in the NSS.
>> Which means that fragments can be added to the URN by anybody, any
>> time after the URN has been assigned and the document made
>> available (via URN resolution) in the Internet.
>
> 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?

This is different for the query part and for the fragment part. The 
fragment part is independent of the scheme. The query part is not.

You will see that in Appendix A of RFC 3986 
(http://tools.ietf.org/html/rfc3986#appendix-A). There, URI is defined 
as including an (optional) fragment part, but absolute-URI is defined 
excluding the fragment part. Same in RFC 3987 for IRIs. So in terms of 
terminology, it might be possible to call an URN without a fragment part 
an absolute URN (in places where such a distinction is necessary).

For fragments, the conclusion that Juha explains above is how it was 
intended for all URIs from the start, and how RFC 3986 is written. It 
may have taken some time for the URN community to arrive at this point, 
but it's a very good conclusion, because it's what works best with the 
rest of the infrastructure.

Regards,   Martin.