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

Alfred Hönes <ah@TR-Sys.de> Fri, 10 February 2012 20:22 UTC

Return-Path: <A.Hoenes@TR-Sys.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 7DD8E21F878A for <urn@ietfa.amsl.com>; Fri, 10 Feb 2012 12:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.093
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awIxLyDd2cUt for <urn@ietfa.amsl.com>; Fri, 10 Feb 2012 12:22:23 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id A3FD621F88C0 for <urn@ietf.org>; Fri, 10 Feb 2012 12:22:22 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA279425285; Fri, 10 Feb 2012 21:21:25 +0100
Received: (from ah@localhost) by z.TR-Sys.de (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=?= <ah@TR-Sys.de>
Message-Id: <201202102021.VAA25016@TR-Sys.de>
To: stpeter@stpeter.im
Date: Fri, 10 Feb 2012 21:21:24 +0100 (MEZ)
In-Reply-To: <4F3430F2.8050008@stpeter.im> from Peter Saint-Andre at Feb "9, " 2012 "01:47:46" pm
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Cc: urn@ietf.org
Subject: Re: [urn] Some initial thoughts on draft-ietf-urnbis-rfc3188bis-nbn-urn-02
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, 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,
  Alfred.


> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/