Re: [precis] WGLC: draft-ietf-precis-mappings-07.txt

[Barry Leiba <[e-mail]>]

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