Re: [urn] Some initial thoughts on draft-ietf-urnbis-rfc3188bis-nbn-urn-02

Alfred Hönes <> Fri, 10 February 2012 20:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DD8E21F878A for <>; Fri, 10 Feb 2012 12:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -97.093
X-Spam-Status: No, score=-97.093 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id awIxLyDd2cUt for <>; Fri, 10 Feb 2012 12:22:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A3FD621F88C0 for <>; Fri, 10 Feb 2012 12:22:22 -0800 (PST)
Received: from by w. with ESMTP ($Revision: $/16.3.2) id AA279425285; Fri, 10 Feb 2012 21:21:25 +0100
Received: (from ah@localhost) by (8.9.3 (PHNE_25183)/8.7.3) id VAA25016; Fri, 10 Feb 2012 21:21:24 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <>
Message-Id: <>
Date: Fri, 10 Feb 2012 21:21:24 +0100 (MEZ)
In-Reply-To: <> from Peter Saint-Andre at Feb "9, " 2012 "01:47:46" pm
X-Mailer: ELM [$Revision: $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Subject: Re: [urn] Some initial thoughts on draft-ietf-urnbis-rfc3188bis-nbn-urn-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Feb 2012 20:22:25 -0000

At 2012-02-09, Peter Saint-Andre wrote:

> <hat type='individual'/>
> On 1/24/12 7:37 AM, Alfred Hönes wrote:
>> At 2012-01-24, Bengt Neiss wrote:
> <snip/>
>>> 2.  The sentence "Future NBN implementations SHOULD make the NBN
>>> string case insensitive as well".  Is this a relevant statement?
>>> Since it seems to be that the nbn_string may be case-sensitive
>>> depending on syntax applied locally (ie.  already implemented) and
>>> URN:s are persistent the case-sensitivity of the nbn_string must
>>> always be taken into consideration...
>> The intent here was to refer to new usages of URN:NBNs, i.e.
>> national libraries and institutions that newly establish and/or
>> formalize NBNs and build national support services for URN:NBN
>> for their ISO 3166 URN:NBN prefix.
>> So there should not be backwards compatibility issues at the URN
>> level, but of course legacy NBN usage within the scope of the
>> future adoptors needs to be addressed, which might lead to a
>> legitimate exemption of the "SHOULD" quoted above.
>> Question to the list:
>>   Would you prefer to drop the quoted "SHOULD" recommendation ?
> Drop the "SHOULD" in favor of what?

The idea was meant literally: Drop this recommendation; period.

> Indeed, I find these two sentences to be in tension:
>    The NBN string MAY be case
>    sensitive, depending on the NBN syntax applied locally.  Future NBN
>    implementations SHOULD make the NBN string case insensitive as well.

Exactly, that's the primary reason why I suggested dropping
the 2nd sentence again.

> I read this as "it is OPTIONAL for existing implementations to treat the
> NBN string as case-sensitive, but RECOMMENDED for new implementations to
> treat the NBN string as case-insensitive".
> Why the different policies for new and existing implementations? IMHO it
> would be better to have the same policy for all. Since RFC 3188 did not
> provide global rules ("Any national library may provide its own rules,
> on the basis of its NBN syntax."), it seems better to err on the side of
> caution by saying that in general NBN strings are case-sensitive, since
> RFC 2141 says:
>    Some namespaces may define additional lexical equivalences, such as
>    case-insensitivity of the NSS (or parts thereof).  Additional lexical
>    equivalences MUST be documented as part of namespace registration,
>    MUST always have the effect of eliminating some of the false
>    negatives obtained by the procedure above, and MUST NEVER say that
>    two URNs are not equivalent if the procedure above says they are
>    equivalent.

Indeed, that's the spirit.

Hence, if a new "implementation" (i.e. another national library
that starts adopting usage of URN:NBN) opts to formalize their
NBN-strings as being case-insensitive, they need to provide a
resolution service that implements this -- resolution clients
should not be hampered with that equivalence and need to continue
treating all NBN-strings as case-sensitive.

However, human users generally kind of seem to expect NBN-strings to
be case-insensitive as well -- in the same manner as most Internet
Mail users assume the local part of email addresses to be case-
insensitive, although they formally aren't, while common mailbox
systems allow their admins a configuration option to treat the
local part of email addresses within their own domains as case-
insensitive -- so the idea was to state a rather strong suggestion
for new implementations of URN:NBN branches to reduce user surprise
by defining their NBN-strings as case-insensitive as well.

We will try to re-phrase the text in the next draft version
to clarify this intent, without using RFC 2119 terms.

Best regards,

> Peter
> --
> Peter Saint-Andre