Re: [precis] Ambiguity in specification of case mapping in RFC 7613 and draft-ietf-precis-nickname

John C Klensin <john-ietf@jck.com> Wed, 04 November 2015 20:05 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2731B33BC for <precis@ietfa.amsl.com>; Wed, 4 Nov 2015 12:05:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmnv1qiSzBHp for <precis@ietfa.amsl.com>; Wed, 4 Nov 2015 12:05:03 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38B51B33BB for <precis@ietf.org>; Wed, 4 Nov 2015 12:04:59 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Zu4Id-000LFO-ES; Wed, 04 Nov 2015 15:04:51 -0500
Date: Wed, 04 Nov 2015 15:04:46 -0500
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre <peter@andyet.net>, Tom Worster <fsb@thefsb.org>, Alexey Melnikov <Alexey.Melnikov@isode.com>
Message-ID: <7407A8C7DB30384DF67C0EA5@JcK-HP8200.jck.com>
In-Reply-To: <563A261F.2040904@andyet.net>
References: <0347834EBDC481BD99BDBE67@JcK-HP8200.jck.com> <56302E6D.5030901@andyet.net> <56312AAC.1000300@andyet.net> <56313616.8000801@andyet.net> <563143B9.7020707@andyet.net> <56383B2F.6080505@andyet.net> <D25E1ABD.673A9%fsb@thefsb.org> <DB8A468B42BB20CDC0E06929@JcK-HP8200.jck.com> <563A261F.2040904@andyet.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/CrX1nUA_PDwvFegc4ND6aR8egLc>
Cc: precis@ietf.org
Subject: Re: [precis] Ambiguity in specification of case mapping in RFC 7613 and draft-ietf-precis-nickname
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 20:05:04 -0000


--On Wednesday, November 04, 2015 08:37 -0700 Peter Saint-Andre
<peter@andyet.net> wrote:

>> I could take a shot at a paragraph explaining that if it is
>> what people want.  Otherwise, I'd be very careful about
>> getting further into that space than the present text goes.
>> Personally, I think the text is still dancing around the
>> issue too much, rather than addressing it, but I may be in
>> the rough.
> 
> That may be. We could simply remove the offending sentence:
>...
> NEW
> 
> 
>     3.  Case Mapping Rule: Unicode Default Case Folding MUST
> be applied,
>         as defined in the Unicode Standard [Unicode] (at the
> time of this
>         writing, the algorithm is specified in Chapter 3 of
>         [Unicode7.0]).  In applications that prohibit
> conflicting
>         nicknames, this rule helps to reduce the possibility of
>         confusion by ensuring that nicknames differing only by
> case
>         (e.g., "stpeter" vs. "StPeter") would not be presented
> to a
>         human user at the same time.
> 
> If we do that, we're no longer dancing around issues.

Different dance, I think, but we may have different objectives.
If we keep the explanatory text, it should be accurate.  The
sentence you removed, by itself, is misleading, so, in that
sense, getting rid of it improves accuracy and is an improvement.

On the other hand, if we remove the explanation, we encourage
those who build libraries to simply apply toCaseFold and believe
they don't need to think further about the situation and those
who build user-facing systems to call those libraries and do the
same thing, secure in the belief that the IETF told them things
would be ok.

The problem remains that, while toCaseFold works well and as
predicted in most locales, in "minority" locales and script and
language contexts, it produces results that are surprising and
that may be bizarre.  It doesn't even catch/match all of the
cases one would prefer as well as matching some things that
shouldn't be (probably the more harmless of the two types of
errors).  

let me say this strongly: unless the IETF is willing to take the
position that we are interested in and supporting an Internet
only for "majority" languages and writing systems ("majority"
defined by "what works well with Unicode generally and
toCaseFold in particular), then a document like this almost
certainly needed a paragraph warning about local issues and
sensitivities.   I can imagine several ways to do that and have
suggested outlines for some of them.   But just dropping text to
avoid saying anything wrong except by implication doesn't do
much for me, largely because I believe that an IETF that takes
such a position would have outlived its usefulness to the global
Internet community.

     john