RFC 5892 defines a category called Exceptions, which lists codepoints
whose assignment differs from what the assignment would have been based
solely on the core property value. For example, while working on the
PRECIS codepoint table I just found U+0F0B (TIBETAN MARK INTERSYLLABIC
TSHEG), which has a core property value of Po ("Punctuation, other") and
which thus would have been DISALLOWED in IDNA2008 if it had not been
explicitly placed in the Exceptions category.Unfortunately, the decisions of the IDNA2008 team with regard to these exceptions are not documented in RFC 5892 or elsewhere (AFAIK), so it's not easy to understand whether it would be best for PRECIS to follow IDNA2008 here or instead to base our assignments on the core property values for some or all of the codepoints in the Exceptions category. (Using the same example, if we follow IDNA2008 then U+0F0B would be PVALID, whereas if we base assignment on the core property value then this codepoint would be FREE_PVAL and NAME_DIS.) I understand the reasoning behind codepoints like sharp S and Greek final sigma because they were extensively discussed on the IDNA list, but other codepoints were not as controversial. I suppose the safest course would be to follow IDNA2008 here. The second-safest course would be to base all assignments on the core property value. The least safe course would be revisiting each codepoint individually and thus defining a PrecisExceptions table that differs in subtle ways from the IDNA2008 Exceptions table. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
