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

From: Yoshiro YONEYA <[email-masked]>
Date: Tue, 18 Feb 2014 16:14:06 +0900

Dear all,

As discussed on the mailing list in recent months, the latest mappings 
document seemed to address issues raised in Vancouver, and seemed to 
have good relation with the latest framework well, so co-chairs decided 
to perform WG LC again to the document.

This message starts two weeks Working Group Last Call (WGLC) on 
draft-ietf-precis-mappings-07.txt (Mapping characters for PRECIS classes).
<http://www.ietf.org/id/draft-ietf-precis-mappings-07.txt>

Please review the document and send comments to the list ([email-masked]), 
the co-chairs ([email-masked]), or the authors 
([email-masked]) by the end of WGLC.

The WGLC start at on Tuesday, Feb 18th and will end on Monday, Mar 3rd.

Regards,

-- Marc & Yoshiro, co-chairs

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 18 Feb 2014 17:38:23 -0700

On 02/18/2014 12:14 AM, Yoshiro YONEYA wrote:
> Dear all,
> 
> As discussed on the mailing list in recent months, the latest
> mappings document seemed to address issues raised in Vancouver, and
> seemed to have good relation with the latest framework well, so
> co-chairs decided to perform WG LC again to the document.
> 
> Please review the document and send comments to the list
> ([email-masked]), the co-chairs ([email-masked]), or
> the authors ([email-masked]) by the end
> of WGLC.

Overall it looks very good. Here are a few relatively small comments...

First, I think this document should be standards track. It defines
technical rules that could be subject to testing and further
improvement, and thus does not seem completely informational to me.

ABSTRACT

   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.

I think this would be a bit clearer:

   The delimiter mapping and special mapping rules described here are
   applied as "additional mappings" beyond those defined in the PRECIS
   framework, whereas the "local case mapping" rule is applied as an
   alternative to Unicode Default Case Folding, which is the case
   mapping rule specified in the PRECIS framework.

The same text can be found in Section 1.

SECTION 2.3

I suggest...

OLD
   characters, targeting characters which mapping depends on locale or
   locale and context.
NEW
   characters, targeting characters for which case mapping depends on
   locale or on locale and context.

There is a small typo here: "if the case of Turkish" should be "in the
case of Turkish". (There are also a few instances of subject-verb
disagreement and such, but I assume those will be fixed during
processing by the RFC Editor team.)

This section says:

   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.

I have been thinking about this further. The PRECIS framework says
that Unicode Default Case Folding is RECOMMENDED. The framework also
says that a PRECIS profile needs to specify which case mapping rule to
apply. The choices are Unicode Default Case Folding, the "local case
mapping" rule from this document, or something else. The nature of
this "something else" is not mentioned. I think it might be simpler to
say "either use Unicode Default Case Folding as recommended by the
PRECIS framework, or use local case mapping as defined by the PRECIS
mapping document, but never both".

If we go in that direction, then I would suggest the following
modified text:

   This local case mapping provides an alternative to Unicode Default
   Case Folding, which is recommended by the PRECIS framework. Because
   these methods are strictly alternatives, if a PRECIS profile
   specifies the use of local case mapping then it MUST NOT also apply
   Unicode Default Case Folding.

APPENDIX A.1

I am not quite sure about the purpose of this table, but in any case I
suggest the following clarification.

OLD
   This table is the mapping type list for each protocol.
NEW
   This table is the mapping type list for each protocol mentioned in
   the PRECIS problem statement document [RFC6885].

Thanks!

Peter

---

From: Yoshiro YONEYA <[email-masked]>
Date: Wed, 26 Feb 2014 17:24:21 +0900

Dear all,

This is reminder.  The WG LC will end next week.
Please review the document and give your feedback.

Regards,

On Tue, 18 Feb 2014 16:14:06 +0900 Yoshiro YONEYA <[email-masked]> wrote:

> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis
> 
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 26 Feb 2014 09:02:44 -0800

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

---

From: "Black, David" <[email-masked]>
Date: Fri, 28 Feb 2014 11:30:32 -0500

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):

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:[email-masked]] On Behalf Of Barry Leiba
> Sent: Wednesday, February 26, 2014 12:03 PM
> To: [email-masked]
> Subject: Re: [precis] WGLC: draft-ietf-precis-mappings-07.txt
>