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

Peter Saint-Andre <peter@andyet.net> Wed, 04 November 2015 15:37 UTC

Return-Path: <peter@andyet.net>
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 E2C4C1B31DD for <precis@ietfa.amsl.com>; Wed, 4 Nov 2015 07:37:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] 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 BHau8zhcdwcu for <precis@ietfa.amsl.com>; Wed, 4 Nov 2015 07:37:07 -0800 (PST)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8801B31DC for <precis@ietf.org>; Wed, 4 Nov 2015 07:37:07 -0800 (PST)
Received: by iofz202 with SMTP id z202so57322621iof.2 for <precis@ietf.org>; Wed, 04 Nov 2015 07:37:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet_net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=k5fj2eFyiqM2jlU2ba4/pqWwiNuWOIISGeWFN9ynyMU=; b=Jp6n0ZMW7rZUSSK42WhH62xdWPU63JueYRj/PJKPZ7hmZhSx5augV9Y9LWU2PReBr6 Li3exRv/tL8CJRlXpkyAIsj6fR2lcvV+/5zhKP8ksKe4W47hB60kxZKPZD7p2faMlidz oWPJoPGWpJc3ni9HBjW6xPQW/+rbVVctbmwZeYXCiMVuX6lQ1JmJqK+w71ojYzk34MDc dcw7WpIXmYiQsX8MA7c+xRDAWZVYpkSQ0JsLoW5StvsO2K1T/GhjmRLIIkRoeYMG60Zc x2Fqnz8lxoTus6Y1oy3QyS87szOhp3akP4L2ftd8ewdyn0tVIVmT3Cu8sDaDqhKMt7aP rDYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=k5fj2eFyiqM2jlU2ba4/pqWwiNuWOIISGeWFN9ynyMU=; b=BYmB1/WP01dW62UgiaH+RnoLhAEjX9130E37MgCc9yfiPivH8vwHClI/yWN9WZbGEj 9TF/FLStBjDF/pLR32bEGMs0SA/rpeOa3CVg3HBjHHYx+GXc8hxAgNdFhy5hqY5aHJop 7n2wq7efHVaG/WLEJ8TMKFBRdd5wrzNnY1k6OslJQZbarY2Bu7JQanTsHd/jf1wTsANV aOW0ttmA5MLP4/D5KWIzaiTOLQo3RIDe1/NA2CO1mPldPfHgH2zFvPoVan/vLf+mjv/o GR3u6IkeFQRHhWm3fKCZYPKxS34OcO3fAVCVok0ew3QrwQtPbCI8kfV4JaOtlXvZyGJV fYzw==
X-Gm-Message-State: ALoCoQlXEjOIxLLhwvOpUw3v0PJZfLZQyypuLdHHgK/l7emjqoVvDscziIW9/+2R0c79J8rT9pga
X-Received: by 10.107.136.216 with SMTP id s85mr3574381ioi.142.1446651426466; Wed, 04 Nov 2015 07:37:06 -0800 (PST)
Received: from aither.local ([2601:282:4201:ef5b:65c1:aacb:2a70:f39d]) by smtp.googlemail.com with ESMTPSA id rt5sm1128936igb.20.2015.11.04.07.37.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 07:37:05 -0800 (PST)
To: John C Klensin <john-ietf@jck.com>, Tom Worster <fsb@thefsb.org>, Alexey Melnikov <Alexey.Melnikov@isode.com>
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>
From: Peter Saint-Andre <peter@andyet.net>
Message-ID: <563A261F.2040904@andyet.net>
Date: Wed, 04 Nov 2015 08:37:03 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <DB8A468B42BB20CDC0E06929@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/precis/PEwfT8HjPsnWVHWms4XUocjWYUU>
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 15:37:09 -0000

On 11/3/15 6:42 AM, John C Klensin wrote:
>
>
> --On Tuesday, November 03, 2015 08:16 -0500 Tom Worster
> <fsb@thefsb.org> wrote:
>
>> The informative sentence in 2.1 Rule 3:
>>
>>      "The primary result of doing so is that uppercase
>> characters are     mapped to lowercase characters."
>>
>> is good but I think it's worth spending a few more words to
>> spell out that "primary" implies exceptions.
>>
>>      "While the primary result is that uppercase characters are
>> mapped to     lowercase characters, there are exceptions."
>>
>> It might nudge a few fore implementers to understand that
>> toLowerCase() isn't the right thing.
>
> But Tom, for many purposes, forms, and language-script
> combinations, toLowerCase() is _exactly_ the right thing.  For
> others, if one adopts the principle of doing no harm, whether
> toLowerCase() or toCaseFold() are likely to do less harm depends
> on some rather subtle issues including the perspective from
> which "harm" is viewed.
>
> I think one could more accurately restate your comment above as
> "... to understand that toLowerCase() is sometimes not the right
> thing and that sometimes toCaseFold() is sometimes not the right
> thing either.
>
> 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:

OLD

    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]).  The primary result of doing so is that uppercase
        characters are mapped to lowercase characters.  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.

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.

Peter