[precis] HasCompat()

[Peter Saint-Andre <[e-mail]>]

In an off-list conversation, John Klensin pointed out to me that there 
could be confusion about the definition of the HasCompat() category from 
Section 9.17 of RFC 7564 and of draft-ietf-precis-7564bis-04.

I can't speak for my co-author Marc Blanchet, but I've always considered 
HasCompat to apply in a "unidirectional" way to the input characters. 
For instance, if we have three code points P0, P1, and P2 such that 
NFKC(P1P2) = P0P0, then the HasCompat() category is assigned to P1 and 
P2 but not to P0. That is, P1 and P2 are decomposed and then recomposed 
in a lossy way because we can't tell from the output string P0P0 what 
the input string was, and there is way to determine all the characters 
that could be decomposed and recomposed into P0P0. It seems that the 
current text might be a bit confusing (as I understand what John wrote, 
the term "has a compatibility equivalent" could be taken to apply to P0 
in this example), so I will try to make it clearer.

Furthermore, John pointed out that the HasCompat() categorization for a 
given input string could potentially change across Unicode versions 
(e.g., if the input string includes a precomposed character that was 
added in a recent version of Unicode). Although I'm not sure if this is 
unavoidable, it does seem that we need to at least mention the potential 
instability of this category.

Peter