Re: [Lucid] Communication.

Asmus Freytag <asmusf@ix.netcom.com> Thu, 19 March 2015 23:52 UTC

Return-Path: <asmusf@ix.netcom.com>
X-Original-To: lucid@ietfa.amsl.com
Delivered-To: lucid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BC01A0111 for <lucid@ietfa.amsl.com>; Thu, 19 Mar 2015 16:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 m63dRgwblSxu for <lucid@ietfa.amsl.com>; Thu, 19 Mar 2015 16:52:48 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id E55761A0141 for <lucid@ietf.org>; Thu, 19 Mar 2015 16:52:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=jjdFpO8NSOvZOzkzAmSDkrMFiVyOfsxzEdCknrKT+Y/bHIx2pptFOZpqBb8hW6S9; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [72.244.206.133] (helo=[192.168.0.107]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <asmusf@ix.netcom.com>) id 1YYkF4-0006fw-Te; Thu, 19 Mar 2015 19:52:47 -0400
Message-ID: <550B6150.20705@ix.netcom.com>
Date: Thu, 19 Mar 2015 16:52:48 -0700
From: Asmus Freytag <asmusf@ix.netcom.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, Shawn Steele <Shawn.Steele@microsoft.com>, lucid@ietf.org
References: <BLUPR03MB1378075831687B9D8DCE68A382010@BLUPR03MB1378.namprd03.prod.outlook.com> <550B54CA.1050202@andyet.net>
In-Reply-To: <550B54CA.1050202@andyet.net>
Content-Type: multipart/alternative; boundary="------------090204010400000906060805"
X-ELNK-Trace: 464f085de979d7246f36dc87813833b2b65b6112f891153763f60484aeba024d329077a82ed40bc1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 72.244.206.133
Archived-At: <http://mailarchive.ietf.org/arch/msg/lucid/Up4NRWRwAyerr-LQitZg37cMB28>
Subject: Re: [Lucid] Communication.
X-BeenThere: lucid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Locale-free UniCode Identifiers \(LUCID\)" <lucid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lucid>, <mailto:lucid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lucid/>
List-Post: <mailto:lucid@ietf.org>
List-Help: <mailto:lucid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lucid>, <mailto:lucid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 23:52:49 -0000

On 3/19/2015 3:59 PM, Peter Saint-Andre - &yet wrote:
> On 3/19/15 4:37 PM, Shawn Steele wrote:
>> I think Asmus said that well " Character encoding is not the process
>> of numbering entities by shape. It's the process of numbering
>> entities by their underlying identity in writing."
>>
>> The PRECIS effort's language is all about characters are encoded by
>> shape.  Unicodes language defined them as being encoded by their
>> underlying identity.
>
>
> Just as with IDNA2008, we structured PRECIS so that decisions are
> made algorithmically based on the properties of code points (which
> together constitute the code point's identity), not the shapes of glyphs.
>
> Peter
>
Peter,

nobody argues that IDNA or PRECIS are not based on
character properties.  They most clearly are.

What I was trying to highlight is the fact that there may be
a misunderstanding of how Unicode (and pretty much all
character encoding, except for, the most trivial cases)
is conceived.

By basing your specification on properties, you can
ensure uniqueness of underling encoded identity,
but, unless the particular properties happen to take into
account information on shape, you won't get uniqueness
in shape.

I'm all for helping IDNA and PRECIS by having Unicode
provide some additional properties that can help address
the case of "apparent identity" where the shapes agree,
but the identity actually is distinct.

A./