-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/21/13 6:29 PM, Florian Zeitz wrote: > On 22.11.2013 01:41, Peter Saint-Andre wrote: >> On 11/21/13 2:19 PM, Florian Zeitz wrote: >> >>> 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. >> > 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. >>> 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). >> > 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. >> 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. >> > 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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSjsbqAAoJEOoGpJErxa2pqzMP/A1G09TfVJj1aTKgATf3CRjG yw0625IJrlWuMf86TRXOjTULLdteGVl/38+eDbAyTHBPZS2Bzg0Ai/g++OdV98J6 kInnO8D0+Y3qmMnCVucTwWDPs5WOJ9PeFMH+fEShPRUZqdg/hr02nW4ckg6qtksF OxtponOTMPmk7kXlILT/7fC2UblZ3rR7r8uOGOTGx1JolW5k9+6J6KL25Qcg8kBD nwE6FM6g80M7qXzgyHYGIH4eJg/ce1mLrer3x0g80Ht4BtYiEUTdA6tLojkTA+Ge 8FGY7G9aYzN/e0KdQvlVeOJNI0wHUyMY+BjQi4BzoXVyQ/rtX74mR9y7O2hCXv0k +hXTJDotYwhRNlaynzvqnnFHU+6NEv4I1yZ0WJ1KGkvdo1KxekYb55TEfgExqVJK uLYnCJ3SQeLusHo/bL0YyqRuXxkinJAdapeX15Gp0yNZz2JrXENhkPipXvK8SGKD IGZCV7V1ao2H5tNQ9RdLcvyuChTdPX2oCOH+SnqffDARuDrUsDnnxNVRIb3O6r5z M7V9ph3qXZfvO7zDPDaf7TNvrRGQJNffQKvfYhnB47bwEDAlwv/3tDR44BskmbnA TtM6yTHixw6AwL0cqmcrHhir4EW3FgssibUqGfIxr45p2bmDqy1Pxcf73lq7DzNA 2NQLa2s8mtU+9ojD+39y =BzqQ -----END PGP SIGNATURE----- _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
