First, thanks very much for accepting most of my earlier comments. -- General -- We use the term "codepoint" sometimes (and, in the Abstract and Introduction, "code point") to refer to a Unicode character. I suggest that we avoid the term entirely in this document, always call them "characters", and make it clear that "character" always means "Unicode character".
-- Section 2.3 -- I find the last paragraph awkwardly worded and, consequently, a bit confusing. I suggest the following: OLD If a codepoint is a target, the case folding method for the codepoint is mapping into lower case as defined in SpecialCasing.txt. On the other hand, if a codepoint is not a target, the case folding method for the codepoint is the same with case mapping in PRECIS framework. This local case mapping provides alternative case folding method to Unicode Default Case Folding as case mapping in the PRECIS framework, therefore if a PRECIS profile chooses local case mapping, it should not choose case mapping. The reason for this is written in the Appendix B. NEW The case folding method for a target character is to map into lower case as defined in SpecialCasing.txt. The case folding method for all other, non-target characters is as specified in Section 4.1.3 of the PRECIS framework. The local case mapping defined here is an alternative to the Unicode Default Case Folding for non-target characters. See Appendix B for more information. END If this suggestion isn't right, please take that as evidence that the existing text is unclear, and try to fix my replacement text to make it correct. Now, I don't understand why you have a short explanation in Appendix B, when you're already using the Turkish "i" example up here in the main section. Why not just edit the eszett text in Appendix B (I think it needs editing for clarity anyway) and put it here as a paragraph in Section 2.3? -- Section 3 -- Are you really saying that the three can be applied in any order, and then suggesting an order, which suggestion can be accepted or ignored as the implementation pleases? Or do you mean to say that this order is specifically recommended, and that implementations shouldn't ignore it? As it's written, it's very wishy-washy, and saying "they could be applied in any order" in one sentence, and "here's an ordering" in the next seems odd. I'd like to see this section tightened up, making the sense of your recommended order clearer. -- Section 4 -- My earlier comments noted the inadequacy of the Security Considerations section, and it hasn't changed since then. It's, therefore, still inadequate. It says it might cause confusion, without explaining why. It doesn't say anything about the security implications of that confusion, nor what anyone could do about it. I really think you need to say something more here. If you disagree, that's fine, but please explain why. -- Barry _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
