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

Julian Reschke <> Tue, 30 October 2012 10:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA2AF21F84B5 for <>; Tue, 30 Oct 2012 03:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.699
X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wayqs7V1BAW2 for <>; Tue, 30 Oct 2012 03:18:38 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 70EB621F84B3 for <>; Tue, 30 Oct 2012 03:18:38 -0700 (PDT)
Received: (qmail invoked by alias); 30 Oct 2012 10:10:24 -0000
Received: from (EHLO []) [] by (mp019) with SMTP; 30 Oct 2012 11:10:24 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/z0Io5r2Dz7IA3SEhqJ9qPgLAvSrBew4eU53E3yY 91B15FZ4hIcYAv
Message-ID: <>
Date: Tue, 30 Oct 2012 11:10:22 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Svensson, Lars" <>
References: <> <24637769D123E644A105A0AF0E1F92EFA3F8E0E2@dnbf-ex1.AD.DDB.DE>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA3F8E0E2@dnbf-ex1.AD.DDB.DE>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "" <>
Subject: Re: [urn] call for comments: an alternative 2141bis document
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Oct 2012 10:18:39 -0000

On 2012-10-29 18:50, Svensson, Lars wrote:
> 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. we would even have a nice showcase what an impl
ion could look like.
> ...

Of course a document providing rational and background makes sense. It 
could be an RFC, too.

Also note that every IETF document already has a URN via 

Best regards, Julian