Re: [urn] URNs and URI <fragment> --> better URN <query> discussion?

Julian Reschke <julian.reschke@gmx.de> Mon, 12 September 2011 07:39 UTC

Return-Path: <julian.reschke@gmx.de>
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 C702421F8634 for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 00:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.243
X-Spam-Level:
X-Spam-Status: No, score=-104.243 tagged_above=-999 required=5 tests=[AWL=-1.644, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1DaAIqCjwPd for <urn@ietfa.amsl.com>; Mon, 12 Sep 2011 00:39:43 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9A17721F84FA for <urn@ietf.org>; Mon, 12 Sep 2011 00:39:42 -0700 (PDT)
Received: (qmail invoked by alias); 12 Sep 2011 07:41:43 -0000
Received: from p508FAAE9.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.170.233] by mail.gmx.net (mp035) with SMTP; 12 Sep 2011 09:41:43 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/cubwTQnDc4aMPypTug5sB9n+INYx768P24Ab4Ce lVtvTGqbnreAhz
Message-ID: <4E6DB7B4.8020407@gmx.de>
Date: Mon, 12 Sep 2011 09:41:40 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "Kocer, Kadir Karaca" <K.Kocer@dnb.de>
References: <6DA97EFF2763174B8BDC409CA19729840A8E83C7@dbf-ex.AD.DDB.DE>
In-Reply-To: <6DA97EFF2763174B8BDC409CA19729840A8E83C7@dbf-ex.AD.DDB.DE>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "\"Kett, Jürgen\"" <J.Kett@dnb.de>, urn@ietf.org, "Altenhoener, Reinhard" <R.Altenhoener@dnb.de>
Subject: Re: [urn] URNs and URI <fragment> --> better URN <query> discussion?
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Mon, 12 Sep 2011 07:39:43 -0000

On 2011-09-12 09:27, Kocer, Kadir Karaca wrote:
> ...
> ...
> At the moment there is no built-in direct support for URNs in Internet Explorer/Firefox/..., so that *every* URN needs some kind of resolving mechanism.
> Most widely implemented solution is a HTTP-Based-Resolver.
>
> Unfortunately my Test-Implementation shows that neither Internet Explorer nor Firefox sends # Fragments to the HTTP server/servlet container. That means if we consider the Julian's example:
> http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
> the resolver do *not* receive the information that the user requests only chapter98 and not any other chapter so it can not react in appropriate way.
> ...

That's by design; not a bug.

> This simple fact has huge effect on URN-Fragments discussion: even the perfect URN fragment solution we agree here will not have any practical effect in daily life, till a future Internet Explorer (version 14/15?) supports URNs natively and all older obsolete IE versions are updated.

If your ultimate goal is to have URNs that are resolvable then why do 
you start with URNs in the first place?

> As a consequence of those two points I tried to explain above, I suggest to start a new discussion:
> queries in URN(:NBN).
> Instead of
> http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
> standardizing
> http://resolver.example.com/urn:nbn:aq:987-65432-1?chapter=98
> so the resolver can get the information, that only a small part of the resource and not the whole is required.

If the goal is to make an HTTP-based resolver aware of the chapter 
number, then yes.

It seems to me that this just indicates that using the fragment 
identifier for use in the URN was a bad choice in the first place :-)

> This solution seems to be the only solution that can in real existing desktop systems function and easily be implemented*.
>
> What is your opinion?
> Karaca Koçer
>
>
> (*) besides a REST based approach like
> http://resolver.example.com/urn:nbn:aq:987-65432-1/chapter/98

Query parameter vs path segment is just a different notation and really 
has little to do with being Restful.

Best regards, Julian