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

["Black, David" <[e-mail]>]

First of all, many thanks to the authors for all of the work invested
in this draft.  

Focusing on the case mapping text, I think this sentence in 2.3 is not
quite right:

   The target characters of local case
   mapping are characters defined in the SpecialCasing.txt
   [Specialcasing] file in section 3.13 of the Unicode Standard
   [Unicode].

I read that as requiring that précis local case mapping *always use
all* of the mappings in the SpecialCasing.txt file, and I don't think
that's wanted.

While any use of précis needs to specify its context-dependencies
(e.g., the context is the protocol to which the précis profile applies),
but locale dependencies are locale-specific [ok, that was obvious :-) ],
and protocols are generally locale-independent.

I'm not sure what to do about this as interoperability problems are
clearly possible when LATIN CAPITAL LETTER I is locale-dependent case
folded in Turkish and English locales for the same protocol, but I
don't think it's right to specify that all of SpecialCasing.txt always
has to be used if any of it is used (that file will change, eventually),
so I'd change the above text to:

   The target characters of local case
   mapping are selected in a locale-specific manner from the characters
   defined in the SpecialCasing.txt [Specialcasing] file in section 3.13
   of the Unicode Standard [Unicode].

and I'd like to discuss the interoperability implications of locale-
dependent local case mapping in the WG meeting.

I also found the same concern that Barry found in Section 2.3, namely
that the nature of the relationship of "local case mapping" in this
draft to the use of Unicode Default Case Folding in the framework draft
is unclear.  I would go further and make the relationship to Unicode
Default Case Folding clear here ...

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 [Barry]
   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.
NEW [David]
   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 (i.e., Unicode
   Default Case Folding SHOULD be used for all non-target characters).
   The local case mapping defined here is an alternative to use of
   Unicode Default Case Folding for all characters.
   See Appendix B for more information.
END

I think Barry also may be off slightly on the use of "non-target"
in the last line of his new text (I changed it to "all" in my text
above), but this entire area is subtle ...

In turn, that leads to this sentence in the abstract (final sentence):

   The mappings described here are
   expected to be applied as an additional mapping and alternative to
   Unicode Default Case Folding as case mapping in the PRECIS framework.

Well, the SpecialCasing.txt file is rather small, so most characters get
Unicode Default Case Folding applied independent of which case mapping
approach is taken.  Here's some suggested alternative text for the
abstract:

   This document defines additional mappings for delimiters and characters
   requiring special protocol-specific treatment, plus a local case mapping
   that is an alternative to the case mapping in the PRECIS framework
   document. 

I see Barry's concern on section 3 (the text in section 3 was clear to me,
but I can see how it could be misread).  I suggest deleting this sentence
for clarity:

   The mappings described in
   this document could be applied in any order.

so that the following sentence is clearer in context:

   This section specifies
   a particular order to minimize the effect of codepoint changes
   introduced by the mappings.

Although, in the latter sentence I'd also change:

  "minimize the effect of" -> "provide consistent results from"

Thanks,
--David

> -----Original Message-----
> From: precis [mailto:[e-mail]] On Behalf Of Barry Leiba
> Sent: Wednesday, February 26, 2014 12:03 PM
> To: [e-mail]
> Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-07.txt
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/precis