Subject: [precis] WGLC: draft-ietf-precis-framework-11.txt

From: Yoshiro YONEYA <[email-masked]>
Date: Tue, 12 Nov 2013 11:15:28 +0900

Dear all,

As we discussed at WG meeting in Vancouver, the latest framework 
document seemed fine but updated a lot since previous WG LC, so chairs 
decided to perform WG LC again to the document.

This message starts two weeks Working Group Last Call (WGLC) on 
draft-ietf-precis-framework-11.txt (PRECIS Framework: Preparation and 
Comparison of Internationalized Strings in Application Protocols).
<http://tools.ietf.org/id/draft-ietf-precis-framework-11.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 will end on Monday, Nov 25th.

Regards,

-- Marc & Yoshiro, co-chairs

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Nov 2013 13:50:59 -0700

On 11/11/13 7:15 PM, Yoshiro YONEYA wrote:
> document seemed fine but updated a lot since previous WG LC, so
> chairs decided to perform WG LC again to the document.

Thanks, Yoneya-san!

While updating draft-ietf-xmpp-6122bis to track the framework, I
discovered at least one error in the codepoint table:

   214F..2182  ; DISALLOWED  # SYM FOR SAMAR SOURCE..ROM NUM TEN T

But, for example, U+2163 should be FREE_PVAL.

I'll perform another complete review of the codepoint table during the
second WGLC.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Yoshiro YONEYA <[email-masked]>
Date: Wed, 20 Nov 2013 02:35:33 +0900

Dear all,

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

Regards,

On Tue, 12 Nov 2013 11:15:28 +0900 Yoshiro YONEYA <[email-masked]> wrote:

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Nov 2013 22:06:04 -0700

On 11/15/13 1:50 PM, Peter Saint-Andre wrote:
> I'll perform another complete review of the codepoint table during
> the second WGLC.

Done. I did find several more errors. The fixes will be in the next
version. (I'll also re-read the entire document while I'm at it.)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 21 Nov 2013 22:19:26 +0100

> The WGLC will end on Monday, Nov 25th.

I've reread the draft in its entirety now that some time has passed.
I have a few minor comments (some of them nits, which IMHO is a good
sign), but overall I'm very pleased with it and think all feedback has
been addressed.

Generally I think we need to update the draft to Unicode 6.3. If we
don't, at least the claims that Unicode 6.2 is the latest version at the
time of writing should be removed ;).

Section 4.1.1 claims width mapping is an aspect of NFKC. While this is
true it is more generally an aspect of compatibility decomposition, and
therefore happens when NFKD is employed. I think the text should reflect
this.

Section 4.1.3 right now says: «Use of the Unicode Default Case Folding
algorithm is RECOMMENDED.» That statement is broader than we want it to
be. Use of that algorithm is certainly recommended, but if and only if
case-preservation is not desired.

Section 7.11 says the category exempts printable 7-bit ASCII from other
rules. This is untrue. The algorithm does this, utilizing the category.

In Section 8 the paragraph preceding the actual algorithm should say
"Exception*s*" instead of "Exception" in two places.

Regards,
Florian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Nov 2013 17:41:03 -0700

On 11/21/13 2:19 PM, Florian Zeitz wrote:
>> draft-ietf-precis-framework-11.txt (PRECIS Framework: Preparation
>> and Comparison of Internationalized Strings in Application
>> Protocols). 
>> 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.
>> 
> I've reread the draft in its entirety now that some time has
> passed. I have a few minor comments (some of them nits, which IMHO
> is a good sign), but overall I'm very pleased with it and think all
> feedback has been addressed.

Thanks for the review!

> Generally I think we need to update the draft to Unicode 6.3. If
> we don't, at least the claims that Unicode 6.2 is the latest
> version at the time of writing should be removed ;).

Yes, I noticed that while completing my own review earlier this week.

> Section 4.1.1 claims width mapping is an aspect of NFKC. While this
> is true it is more generally an aspect of compatibility
> decomposition, and therefore happens when NFKD is employed. I think
> the text should reflect this.

How about this?

OLD
   Because one aspect of Unicode
   normalization form KC (NFKC) is width mapping, a profile that uses
   NFKC does not need to specify width mapping.

NEW
   Because Unicode normalization
   form KC (NFKC) performs width mapping via compatibility decomposition
   and subsequent recomposition, a profile that uses NFKC does not need
   to specify width mapping.

> Section 4.1.3 right now says: «Use of the Unicode Default Case
> Folding algorithm is RECOMMENDED.» That statement is broader than
> we want it to be. Use of that algorithm is certainly recommended,
> but if and only if case-preservation is not desired.

Correct.

A minor note: the Unicode specification does not use the term "Unicode
Default Case Folding algorithm", so it seems better to refer to it as
the "Unicode case folding algorithm" (and also to reference Chapter 5
of the Unicode Standard).

Thus:

   If case preservation is not desired, it is RECOMMENDED to use the
   Unicode case folding algorithm (see Chapter 5 of the Unicode
   Standard).

> Section 7.11 says the category exempts printable 7-bit ASCII from
> other rules. This is untrue. The algorithm does this, utilizing the
> category.

Good point. How about:

   By applying this PRECIS-specific category, the algorithm specified
   under Section 8 exempts most characters in the (printable) ASCII-7
   range from other rules that might be applied during PRECIS
   processing, on the assumption that these code points are in such wide
   use that disallowing them would be counter-productive.

> In Section 8 the paragraph preceding the actual algorithm should
> say "Exception*s*" instead of "Exception" in two places.

Noted.

I too have found some other nits during my review (which I'll try to
complete tonight), so I might make a few more comments on the list.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Fri, 22 Nov 2013 02:29:30 +0100

On 22.11.2013 01:41, Peter Saint-Andre wrote:
>> passed. I have a few minor comments (some of them nits, which
>> IMHO is a good sign), but overall I'm very pleased with it and
>> think all feedback has been addressed.
> 
> Thanks for the review!
> 
>> Section 4.1.1 claims width mapping is an aspect of NFKC. While
>> this is true it is more generally an aspect of compatibility 
>> decomposition, and therefore happens when NFKD is employed. I
>> think the text should reflect this.
> 
> How about this?
> 
> OLD Because one aspect of Unicode normalization form KC (NFKC) is
> width mapping, a profile that uses NFKC does not need to specify
> width mapping.
> 
> NEW Because Unicode normalization form KC (NFKC) performs width
> mapping via compatibility decomposition and subsequent
> recomposition, a profile that uses NFKC does not need to specify
> width mapping.
> 
That actually misses my point. I'd suggest:
NEW
   Since width mapping is performed as a part of compatibility
   decomposition, a profile employing either normalization
   form KD (NFKD), or normalization form KC (NFKC) does not need
   to specify width mapping.

>> Folding algorithm is RECOMMENDED.» That statement is broader
>> than we want it to be. Use of that algorithm is certainly
>> recommended, but if and only if case-preservation is not
>> desired.
> 
> Correct.
> 
> A minor note: the Unicode specification does not use the term
> "Unicode Default Case Folding algorithm", so it seems better to
> refer to it as the "Unicode case folding algorithm" (and also to
> reference Chapter 5 of the Unicode Standard).
> 
That is untrue. Section 3.13 "Default Case Algorithms" in the Unicode
standard refers to this as the "Default Case Folding", always eliding
the "algorithm" though. Chapter 5 later makes a reference to "the
default case folding algorithm". My instinct would also have been to
refer to Chapter 3, rather than Chapter 5.

>> Section 7.11 says the category exempts printable 7-bit ASCII
>> from other rules. This is untrue. The algorithm does this,
>> utilizing the category.
> 
> Good point. How about:
> 
> processing, on the assumption that these code points are in such
> wide use that disallowing them would be counter-productive.
> 
Purely for stylistic reasons, i.e. being more in line with how other
categories are worded, I would suggest:
   This PRECIS-specific category consists of all printable, non-space
   characters from the 7-bit ASCII range.
   By applying this category, the algorithm specified under Section 8
   exempts these characters from other rules that might be applied
   during PRECIS processing, on the assumption that these code points
   are in such wide use that disallowing them would be
   counter-productive.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Nov 2013 19:52:26 -0700

On 11/21/13 6:29 PM, Florian Zeitz wrote:
>>> Generally I think we need to update the draft to Unicode 6.3.
>>> If we don't, at least the claims that Unicode 6.2 is the latest
>> OLD Because one aspect of Unicode normalization form KC (NFKC)
>> is width mapping, a profile that uses NFKC does not need to
>> specify width mapping.
>> 
> That actually misses my point.

I don't think it misses your point, although it's not as complete as
your suggested text because it doesn't mention NFKD.

> I'd suggest: NEW Since width mapping is performed as a part of
> compatibility decomposition, a profile employing either
> normalization form KD (NFKD), or normalization form KC (NFKC) does
> not need to specify width mapping.

WFM.

> That is untrue. Section 3.13 "Default Case Algorithms" in the
> Unicode standard refers to this as the "Default Case Folding",
> always eliding the "algorithm" though. Chapter 5 later makes a
> reference to "the default case folding algorithm". My instinct
> would also have been to refer to Chapter 3, rather than Chapter 5.

Yes, that's better. I forgot about the definition in Chapter 3.

>> By applying this PRECIS-specific category, the algorithm
>> specified under Section 8 exempts most characters in the
>> (printable) ASCII-7 range from other rules that might be applied
>> during PRECIS processing, on the assumption that these code
>> points are in such wide use that disallowing them would be
>> counter-productive.
>> 
> Purely for stylistic reasons, i.e. being more in line with how
> other categories are worded, I would suggest: This PRECIS-specific
> category consists of all printable, non-space characters from the
> 7-bit ASCII range. By applying this category, the algorithm
> specified under Section 8 exempts these characters from other rules
> that might be applied during PRECIS processing, on the assumption
> that these code points are in such wide use that disallowing them
> would be counter-productive.

Agreed.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/