Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt

Juha Hakala <juha.hakala@helsinki.fi> Fri, 23 December 2011 11:01 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 E5F3121F8B38 for <urn@ietfa.amsl.com>; Fri, 23 Dec 2011 03:01:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.903
X-Spam-Level:
X-Spam-Status: No, score=-4.903 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4]
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 Bcf-pFKzmo2P for <urn@ietfa.amsl.com>; Fri, 23 Dec 2011 03:01:39 -0800 (PST)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 92BBD21F8B2B for <urn@ietf.org>; Fri, 23 Dec 2011 03:01:37 -0800 (PST)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id pBNB1Vft025826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Dec 2011 13:01:32 +0200
Message-ID: <4EF45F8B.7040509@helsinki.fi>
Date: Fri, 23 Dec 2011 13:01:31 +0200
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de>
In-Reply-To: <4EF44091.3070608@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org
Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt
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: Fri, 23 Dec 2011 11:01:40 -0000

Hello again,

Julian Reschke wrote:

> We should keep that the important point in UR*N* * *naming*.

In my community (libraries & publishing) naming has been taken for 
granted for decades, due to the identifier systems like ISBN and ISSN. 
URN is relevant for us because we need to make these traditional 
identifiers actionable (resolvable) in the Internet. So the important 
point in URN may vary, depending on the implementer community's 
requirements and background.

> URNs *can* be (made) resolvable, and URLs *can* be (stable) names.

True, and the shelf location codes the libraries use could be utilized 
as identifiers too. But approximately 4000 years of practical experience 
has proven that it is a very good idea to separate location information 
and identification, since things do move around, and often in ways that 
haven't been anticipated. Using URLs as names of Internet resources will 
eventually (after a few decades or centuries) get more complicated than 
URN-based solution (which becomes truly useful only when supported by 
some kind of resolution services).
> 
> If this WG believes that urn:uuid is something that is kind of wrong 
> then I think we have a problem :-)

We do not have a problem, since RFC 4122 and approximately 300.000 
assigned urn:uuid's have settled this issue forever. It is definitely 
not wrong to use UUIDs as URNs. Whether it is a good idea to do that is 
an entirely different question, and one that will be answered by the 
users, not by us. Since many people are using just prefix uuid: instead 
of urn:uuid: there is a chance that at least some people are failing to 
see the point of using URN:UUIDs.

>> There are good reasons for keeping services and identification apart
>> (for instance, services are technology driven and will change over
>> time), which is why the URN community has tried to avoid conflicts here,
>> both in the existing URN RFCs and in the documents currently under
>> development.
> 
> Is this the "HTTP" may go way argument? Even if it does, you will still 
> be able to write resolvers, just like what you're trying to do right now 
> with URNs.

No, I was just emphasizing the point that if we piggyback service 
parameters in <query> they will not be part of the URN itself. Whenever 
there are fundamental changes in technology, the URN itself remains the 
same, but the service parameters may be encoded differently.

Best regards,

Juha
> 
> Best regards, Julian
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678