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 protected]> wrote: > 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. _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
