Re: [precis] Category changes with Unicode 6.3

Peter Saint-Andre <stpeter@stpeter.im> Thu, 24 October 2013 17:44 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B99C11E8368 for <precis@ietfa.amsl.com>; Thu, 24 Oct 2013 10:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.359
X-Spam-Level:
X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, 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 LgTuMO5wPZ6h for <precis@ietfa.amsl.com>; Thu, 24 Oct 2013 10:43:48 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E25D621E8056 for <precis@ietf.org>; Thu, 24 Oct 2013 10:42:49 -0700 (PDT)
Received: from sjc-vpn7-728.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B95264100F; Thu, 24 Oct 2013 11:49:33 -0600 (MDT)
Message-ID: <52695C15.6010303@stpeter.im>
Date: Thu, 24 Oct 2013 11:42:45 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: John C Klensin <klensin@jck.com>
References: <525DFB1F.8040401@it.aoyama.ac.jp> <7693B3B4-7204-48F0-8C42-EBF5D701BAF4@frobbit.se> <525E3A7F.9040204@it.aoyama.ac.jp> <DA8691AD-408B-409B-B6B6-3ECC048AB09A@frobbit.se> <11194FD50DDFBDB190254386@JcK-HP8200.jck.com>
In-Reply-To: <11194FD50DDFBDB190254386@JcK-HP8200.jck.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: precis@ietf.org
Subject: Re: [precis] Category changes with Unicode 6.3
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 24 Oct 2013 17:44:31 -0000

[ removing idna-update ]

On 10/16/13 7:46 AM, John C Klensin wrote:
> 
> 
> --On Wednesday, October 16, 2013 10:16 +0300 Patrik Fältström
> <paf@frobbit.se> wrote:
> 
>> Yeah, I had to do it anyways -- as I am expert reviewer of the
>> IANA tables. New versions of the IANA tables where created by
>> IANA the other day, and I just approved them as they match my
>> own calculations. I.e. we have two completely independent
>> implementations of IDNA2008 (one at IANA, one that I have --
>> see link below) and I compare the output of the two. If the
>> output matches, then we are pretty sure we are correct.
> 
> This is great.   To a considerable extent, it reinforces the
> utility and importance of the IDNA2008 approach.   YOu (and
> IANA) reapply the rules to a new version of Unicode, verify that
> nothing  significant has changed and your results are the same,
> and we move on.
> 
> In addition, because mapping is defined on top of those rules
> and the collection of allowable code points they create, we
> don't end up with different profiles for different domains or
> applications.
> 
> It remains to be seen whether the PRECIS approach will work as
> well.  On the one hand, generation rules have replaced the
> normative Stringprep table.  On the other, that system leads,
> not to a definitive list but to string classes that are then
> profiled, potentially on an application-by-application or even
> implementation-by-implementation basis, to yield actual
> practices.  Different behavior in different applications may be
> inevitable but it is certain that it will confuse at least some
> users.  And, because different profiles will address different
> parts of the basic PRECIS code space, it is possible that the
> same evaluations that are run against the generation rules for
> IDNA (and exceptional adjustments added if needed) will need to
> be performed for each profile, resulting in temporal
> instability.    Perhaps it will all work out and the profiles
> will be completely stable, but it is hard to be completely
> confident about that.

Unfortunately, I have to agree. It seems to me that with IDNA2008 we
don't end up with different profiles for different applications because
there's only one application. With PRECIS we're again attempting to
generalize beyond the IDN case to a wider variety of applications, and
different applications have different requirements with regard to case
preservation and case mapping, normalization, excluded characters, etc.
It strikes me that we'll need code to test all of the PRECIS profiles,
not just the string classes. I haven't had time to keep my PrecisMaker
code up to date, let alone extend it for all of the profiles, but I will
try to work on those tasks after the Vancouver meeting.

Peter

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