Re: [Idna-update] Genart telechat review of draft-faltstrom-unicode11-08

Martin J. Dürst <> Wed, 20 March 2019 05:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3854130F33 for <>; Tue, 19 Mar 2019 22:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.923
X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OuvWWnScXBEW for <>; Tue, 19 Mar 2019 22:19:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75374130EF2 for <>; Tue, 19 Mar 2019 22:19:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wHPwv9TEhcJtZGzCjjOskUqpk9yYL/kDiiSWD+J+BJs=; b=xgc0018yqsUOfaMVMw04qy3tkYi3YwisbcbrTmvHt+sP4ccNOy9bJOXJvIpoK8LfOLl10EH6dYxOVarNNLbI8DncOCcDJ8rGFtSkU3I/ZzPcb5PdHRxO8lh36gpvvrNLOyC156rFJ0N3SmCMEwA+16xcz1e5tZSw4MorGjO6qns=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Wed, 20 Mar 2019 05:19:41 +0000
Received: from ([fe80::98b6:d90e:9ae7:302]) by ([fe80::98b6:d90e:9ae7:302%3]) with mapi id 15.20.1709.015; Wed, 20 Mar 2019 05:19:41 +0000
From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= <>
To: "Asmus Freytag (c)" <>
CC: "" <>
Thread-Topic: [Idna-update] Genart telechat review of draft-faltstrom-unicode11-08
Date: Wed, 20 Mar 2019 05:19:41 +0000
Message-ID: <>
References: <> <458987D953A5B3227D3A791F@PSB> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-clientproxiedby: (2603:1096:404::17) To (2603:1096:404:12e::18)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c5ed4e1c-c6d0-4301-13bc-08d6acf3a81e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7025125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:TYAPR01MB3167;
x-ms-traffictypediagnostic: TYAPR01MB3167:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 098291215C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39840400004)(136003)(366004)(52314003)(199004)(189003)(6116002)(2906002)(5660300002)(8936002)(3846002)(76176011)(15650500001)(53546011)(26005)(6506007)(86362001)(386003)(102836004)(85202003)(106356001)(31686004)(446003)(305945005)(11346002)(74482002)(6486002)(476003)(2616005)(25786009)(229853002)(186003)(486006)(105586002)(52116002)(6436002)(316002)(786003)(14444005)(68736007)(97736004)(81166006)(93886005)(4326008)(6916009)(6512007)(966005)(66574012)(14454004)(256004)(71200400001)(508600001)(99286004)(31696002)(71190400001)(85182001)(6246003)(8676002)(6306002)(66066001)(81156014)(53936002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB3167;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: BUlf2QPs623S2eNN+D+05gWzWQuEebciB4O/SEkWNhL2f/yZ5M8sNYCPOKaxQ92Xz3Zq+g9H1ge17Wl/8VXnCwtCIp0RU8he0MYMhNziRjRWe8llhSdKfu2kLC55CKqaxmKuem+4a3Xj4M4jVQgXnDS7gqReETU116nIV8tmmbATbmrmV4g3wSdVQbty/L75eqQdlukPEEkf/rtf8qPilSJQHnoO1Zft6c59oN2CuFUejDv/kiBLYJQDyOXBRmmlVxq4rzpgjt0mpDQpgTdqDhGcf65wJ5d2pwx6Ec5Fiw2b2sddH3tduPcfIANlF1Wt4ARS8FAppv/nku3ppzfbxajeQHcGaKTc4uOog5w45fGLN9gqbV4e+kPJ8e/WZ+0zEA3OGkas8Vl5SeM5V2EeWUye7iYzpfxjVXtkYHNlPsE=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c5ed4e1c-c6d0-4301-13bc-08d6acf3a81e
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2019 05:19:41.8959 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3167
Archived-At: <>
Subject: Re: [Idna-update] Genart telechat review of draft-faltstrom-unicode11-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Mar 2019 05:19:47 -0000

Sorry I forgot to mention it, but I think the change of the Unicode 
property for U+19DA NEW TAI LUE THAM DIGIT ONE happened because the 
General_Category value "Nd" was tightened to only apply to consecutive 
decimal digits that start with zero. See, page 175:

The Numeric_Type = Decimal property value (which is correlated with the 
General_Category = Nd property value) is limited to those numeric 
characters that are used in decimal-radix numbers and for which a full 
set of digits has been encoded in a contiguous range, with ascending 
order of Numeric_Value, and with the digit zero as the first code point 
in the range.

Either the tightening must have happened in the 6.0.0 timeframe, or 
U+19DA NEW TAI LUE THAM DIGIT ONE was originally classified wrongly.

Anyway, the DNS doesn't need decimal digits to be in a contiguous block 
starting with zero.

Regards,   Martin.

On 2019/03/20 13:39, Martin J. Dürst wrote:
> Hello Asmus,
> On 2019/03/20 01:24, Asmus Freytag (c) wrote:
>> On 3/19/2019 3:19 AM, Martin J. Dürst wrote:
>>> In the 6.0.0 timeframe, there were both more actual changes (3), and
>>> there was one change where we moved from PVALID to DISALLOWED, which I
>>> personally think is the tougher one (see
>>> And looking at the
>>> code chart at, one may even
>>> reasonably argue that keeping U+19DA NEW TAI LUE THAM DIGIT ONE would
>>> have been the better choice, because when one compares U+19B1 NEW TAI
>>> LUE VOWEL SIGN AA and U+19D1 NEW TAI LUE DIGIT ONE and finds them having
>>> (at least on first approximation) the same glyph shape, one can easily
>>> guess that U+19DA NEW TAI LUE THAM_DIGIT_  ONE is used (this is only a
>>> quick conjection which would have to be confirmed) exactly in situations
>>> where the distinction between letters and digits is important, of which
>>> we know domain names are a good example.
>> Here's a telling example of how a formal problem can be practically
>> irrelevant:
>> I looked up New Tai Lue on Omniglot:
>> "The new script is used exclusively in Jinghong, so could be called the
>>     New Jinghong Tai Lue script, and is used for shop and street signs.
>> *Fe**w people can read it*. "   (Emphasis mine).
>> If you read the full text you get the impression that the whole script
>> represents a failed state-imposed "simplification". Unicode still needs
>> to encode it, so that archival texts from the period between 1950 and 1980
>> can be encoded, but it's surely of no practical relevance for domain names.
> Interestingly enough, their page (at
> shows the U+19DA NEW TAI LUE
> _THAM_ DIGIT ONE glyph rather than the U+19D1 NEW TAI LUE DIGIT ONE
> glyph in the Numerals section.
> Regards,   Martin.
> _______________________________________________
> IDNA-UPDATE mailing list