Re: [urn] call for comments: an alternative 2141bis document

"Svensson, Lars" <L.Svensson@dnb.de> Mon, 29 October 2012 17:50 UTC

Return-Path: <L.Svensson@dnb.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 5ABED21F86EA for <urn@ietfa.amsl.com>; Mon, 29 Oct 2012 10:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.749
X-Spam-Level:
X-Spam-Status: No, score=-6.749 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, SARE_WEOFFER=0.3]
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 xhlzrfzWgc1H for <urn@ietfa.amsl.com>; Mon, 29 Oct 2012 10:50:24 -0700 (PDT)
Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 60ECA21F86CD for <urn@ietf.org>; Mon, 29 Oct 2012 10:50:24 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id B2E1ED5D39 for <urn@ietf.org>; Mon, 29 Oct 2012 18:50:22 +0100 (CET)
Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.01.0355.002; Mon, 29 Oct 2012 18:50:22 +0100
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] call for comments: an alternative 2141bis document
Thread-Index: AQHNst+BBJ8XGGNKAUKvh2m9P5ShbpfQjb1g
Date: Mon, 29 Oct 2012 17:50:21 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA3F8E0E2@dnbf-ex1.AD.DDB.DE>
References: <CAAQiQRe+wCBmKfm7up8XY-4RxLnktZiz+nuanprygGcHAYdqAw@mail.gmail.com>
In-Reply-To: <CAAQiQRe+wCBmKfm7up8XY-4RxLnktZiz+nuanprygGcHAYdqAw@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.69.222]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [urn] call for comments: an alternative 2141bis document
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: Mon, 29 Oct 2012 17:50:25 -0000

All,

> Can participants of this working group please review both documents and
> express opinions and provide comments as to the direction desired for
> this working group in regards to a 2141bis RFC?

To me it seems obvious that people have different views of what an RFC should offer. One view is that an RFC first and foremost should offer a specification suitable for _technical_ implementers (engineers). The other view is well described by what Juha wrote:

[[
[...] many people who'll read URN-related RFCs will not be familiar with IETF in general and the history of URNs in particular, and it is important to provide them some background information. A particularly important target group are people representing identifier systems which may or may not register namespaces. The key RFCs may be the only source of information at hand when the process begins, and if these documents provide just the very minimum of what is needed, some important namespace registrations may never be produced. I have written namespace registration requests using both the old, "skeletal" RFC 2141 and the new RFC2141bis, and IMHO the new, more exhaustive document was more helpful. I am a librarian, not an engineer, but writing a namespace registration request requires, first and foremost, familiarity with the identifier standard and its usage.
]]

As a librarian with a background in software engineering I feel that both points are valid. In order to foster uptake of the URN specifications among groups who are not familiar with the IETF, it is important to be able to point (non-technical) implementers to the background information; it is valuable and important and must not be lost. OTOH it is very well possible that engineers outside the cultural heritage sector are not willing to read a 30 page specification in order to distill out the four pages of information they need to complete their task; the result could be a lack of uptake within that group. As a compromise: Could it be an option to let the RFC focus on the technical implementation and to factor out the background information into a separate document and refer to it as a non-normative reference in the RFC? If the background document is given a URN:NBN and we offer resolving through e. g. http://nbn-resolving.org we would even have a nice showcase what an implementation could look like.

All the best,

Lars

***Lesen. Hören. Wissen. 100 Jahre Deutsche Nationalbibliothek***
***Reading. Listening. Understanding. A century of the German National Library***

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
l.svensson@dnb.de
http://www.dnb.de/100jahre