Or I could just be wrong, which is what I was hoping. :)
On 7/30/14, 1:48 PM, "John C Klensin" <[email protected]> wrote: >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. > > > > > -- Joe Hildebrand _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
