Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to general issues

Juha Hakala <juha.hakala@helsinki.fi> Fri, 06 July 2012 09:18 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 CBC0D21F86BE for <urn@ietfa.amsl.com>; Fri, 6 Jul 2012 02:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.192
X-Spam-Level:
X-Spam-Status: No, score=-5.192 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_40=-0.185, 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 jIRixbH0eqm4 for <urn@ietfa.amsl.com>; Fri, 6 Jul 2012 02:18:35 -0700 (PDT)
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 7123D21F86BD for <urn@ietf.org>; Fri, 6 Jul 2012 02:18:34 -0700 (PDT)
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 q669IlYG003095 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <urn@ietf.org>; Fri, 6 Jul 2012 12:18:48 +0300
Message-ID: <4FF6AD77.2090803@helsinki.fi>
Date: Fri, 06 Jul 2012 12:18:47 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.5) Gecko/20120605 Thunderbird/10.0.5
MIME-Version: 1.0
To: urn@ietf.org
References: <201207050926.LAA08015@TR-Sys.de>
In-Reply-To: <201207050926.LAA08015@TR-Sys.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [urn] A way forward for rfc2141bis and rfc3406bis -- comments to general issues
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, 06 Jul 2012 09:18:36 -0000

Hello,

Alfred has brought up several important issues in this message. I'll not 
respond to everything at once, but will discuss the general points, the 
way forward and the proposal separately.

This message concentrates on the general issues.

On 5.7.2012 12:26, Alfred wrote:
> URN folks,
>
> thanks to all for reviving the discussion on the rfx2141bis and
> rfc3406bis I-Ds.  As the editor of both drafts, I try to sum up
> below and provide a perspective for a way forward; I'll respond
> individually in more detail ASAP (see endnote).
>
>
> ** general **
>
> Unfortunately, stakeholders of URN Namespaces for various reasons
> seem to feel discouraged to participate in the on-list discussion,
> which now has been majorized by few long-time "IETF professional"
> contributors.  Part of the frustration I observe also seems to be
> based on the lack of constructive proposals on the list so far,
> as replacement solutions for the options being voted against.

There are not that many librarians, publishers etc. who are involved 
with standards work. And most of these standards activists concentrate 
on developing ISO standards. IETF as a whole, and the way in which it 
develops standards, is unfamiliar to book trade and libraries. So even 
if the URN system is vitally important for those organisations who use 
it, we have only a limited number of mainly technical people following 
the URNbis process.
>
> We should not forget that the prime target audience of these URN
> core documents is the rather divers family of (present and)
> prospective stakeholders of URN Namespaces, which frequently
> have not been in contact with the IETF, but possibly with other
> persistent ID schemes, _or_ which are working within the IETF,
> but with a focus on a particular technology and mostly unaware
> of relevant work for URNs.

There are on the one hand technical people who write, implement and 
maintain URN resolvers (among other tools), and on the other hand people 
who use URNs to identify resources. The former are familiar with RFCs, 
and will look for technical information from them. The latter must be 
familiar with the functionality of the URN system in general level, and 
the local URN policy in the detailed level. They cannot find the latter 
from RFCs, and they should get former from other sources than RFCs.

As an aside, there seems to be a misconception that developing a URN 
resolver is complicated. This is not the case; the resolver software 
used by the national library of Finland consists of 18 lines of Python 
code (including four blank lines). But we should be careful in not 
making the business of resolution too complex.

> Hence, the goal of the "core URN documents" should be to give
> concise guidance to _that_ audience, in order to help avoid to
> have to explain the same context again and again individually
> (as I have done in the past couple of years).

I do not insist upon removal of the generic guidance information from 
URNbis documents (potential readers can skip the sections they don't 
need), but if we want e.g. librarians to read this information, it 
should be made available at (or linked to) places where librarians etc. 
go to find information about preservation of digital resources in 
general, such as http://www.digitalpreservation.gov/.

> This IMO needs to include a bit of a "marketing" effort for the
> URN framework against other, concurring identifier systems.

Choosing a persistent identifier system is a decision one has to live 
with for a long time. IMHO it is a big responsibility to tell somebody 
that you should use this or that persistent identifier. Moreover, no 
matter what the experts say, the choice is often based on the 
availability of software package which allows one to start Handle / DOI 
/ URN assignment easily, or mandates one of these systems (like e.g. 
DSpace requires Handles).

To be honest, currently it really does not matter whether the persistent 
identifier is endorsed by IETF or not, or even whether the technical 
requirements such as URI Generic Syntax are followed. There is a major 
project which started assigning Handles in which the fragment identifier 
and the rest of the identifier string in Handle suffix are separated by 
"@" (@ was selected because Handle syntax has not reserved it; the fact 
that it is reserved in URI syntax did not matter).

Given that the overall situation in PID assignment is a bit chaotic, it 
is important that after the revision of the URN system we can say that 
URNs follow strictly the requirements of e.g. RFC 3986, and that the 
RFCs which specify key features such as URN syntax are on standards 
track. Since no other PID system is a true Internet standard, this will 
give URN credibility compared to other PIDs. Of course, in order to gain 
more users, easy to use open source URN software package(s) are needed.

> Recently, being able to point prospective applicants of
> new URN Namespaces (from inside and outside of the IETF) to
> the material in the present Introductions of the rfc2141bis
> and rfc3406bis drafts has been very helpful in giving guidance
> on technical/document/historical context; such material is
> sought by prospective stakeholders in the core documents.

True, and we will be even better off when this information is available 
in more accessible documents, and perhaps also in multiple languages.

Juha

>
> Best regards,
>    Alfred.
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn

-- 

  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