Subject: [precis] U+19DA

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 30 Jul 2014 18:48:07 +0000

Draft-17 of the precis-framework doc says:

"The PRECIS framework, which is defined in terms of the latest version
   of Unicode as of the time of this writing (6.3), treats the character
   U+19DA NEW TAI LUE THAM as DISALLOWED.  Implementers need to be aware
   that this treatment is different from IDNA2008 (originally defined in
   terms of Unicode 5.2), which treats U+19DA as PVALID."

RFC 6452 amends IDNA to say:

"1.3.  U+19DA NEW TAI LUE THAM DIGIT ONE

   The GeneralCategory for this character changes from Nd to No.  This
   implies that the derived property value changes from PVALID to
   DISALLOWED."

So the "PVALID" part of the precis draft likely needs to change.

Further, I get FREE_PVAL for U+19DA, because it now hits the
OtherLetterDigits rule (R), since its general category is No.

-- 
Joe Hildebrand

---

From: John C Klensin <[email-masked]>
Date: Wed, 30 Jul 2014 15:48:58 -0400

Joe,

Thanks for spotting this.

FWIW, it shows _exactly_ why I am concerned about two separate
sets of rules, tables, and experts for PRECIS and IDNA.   If we
can't manage to keep things synchronized when PRECIS is under
active development, with a WG that is presumably paying
attention, then getting everything right and keeping it
consistent when we are depending on a few overloaded individuals
seems implausible.   

There is, of course, an alternate hypothesis, which is that
participants in PRECIS either aren't paying attention or that
they are paying attention to the intersection of the particular
protocols and languages most of interest to them, but I can only
hope that is not the case.

best,
   john

--On Wednesday, July 30, 2014 18:48 +0000 "Joe Hildebrand
(jhildebr)" <[email-masked]> wrote:

> "The PRECIS framework, which is defined in terms of the latest
> version    of Unicode as of the time of this writing (6.3),
> treats the character    U+19DA NEW TAI LUE THAM as DISALLOWED.
> Implementers need to be aware    that this treatment is
> different from IDNA2008 (originally defined in    terms of
> Unicode 5.2), which treats U+19DA as PVALID."
> 
>    The GeneralCategory for this character changes from Nd to
> No.  This    implies that the derived property value changes
> from PVALID to    DISALLOWED."
>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 30 Jul 2014 19:57:53 +0000

Or I could just be wrong, which is what I was hoping. :)

-- 
Joe Hildebrand

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Jul 2014 16:41:08 -0400

> consistent when we are depending on a few overloaded individuals

Yeah, it's a good example of the problem.  I know in my own case, when
Joe poked me I thought, "Uh, isn't that the thing that changed
categories?  I thought we dealt with that?"  Then I looked and
realised things had moved around.  I certainly fell down in missing
this.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 31 Jul 2014 10:27:49 +0900

I amended the subject. I think it helps tremendously if these things 
come with names. Also, indicating the (potential) issue in the subject 
helps a lot. I suggest to do the same for the other threads.

Regards,   Martin.