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

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Feb 2012 13:47:46 -0700

<hat type='individual'/>

On 1/24/12 7:37 AM, Alfred � 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?

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.

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.

Peter

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

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 10 Feb 2012 21:21:24 +0100 (MEZ)

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

> <hat type='individual'/>
>
> On 1/24/12 7:37 AM, Alfred Hönes wrote:
>

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

>    implementations SHOULD make the NBN string case insensitive as well.

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

>    two URNs are not equivalent if the procedure above says they are

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.