Early Review of draft-bray-unichars-09
review-bray-unichars-09-artart-early-leiba-2024-10-23-00
Request | Review of | draft-bray-unichars-09 |
---|---|---|
Requested revision | 09 (document currently at 11) | |
Type | Early Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2025-02-14 | |
Requested | 2024-10-04 | |
Requested by | Orie Steele | |
Authors | Tim Bray , Paul E. Hoffman | |
I-D last updated | 2024-10-23 | |
Completed reviews |
Genart Early review of -09
by Dale R. Worley
(diff)
Artart Early review of -09 by Barry Leiba (diff) Artart Early review of -09 by Harald T. Alvestrand (diff) |
|
Comments |
This document provides general guidance regarding the use of unicode in protocols. Please consider the internationalization, interoperability and security implications of the document. Since this document is AD sponsored, please note the mailing list for discussion is: https://mailarchive.ietf.org/arch/browse/art/?q=draft-bray-unichars |
|
Assignment | Reviewer | Barry Leiba |
State | Partially completed | |
Request | Early review on draft-bray-unichars by ART Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/art/0_-yK70_e4dJ1UStb5h5W9dwTFE | |
Reviewed revision | 09 (document currently at 11) | |
Result | Ready w/nits | |
Completed | 2024-10-23 |
review-bray-unichars-09-artart-early-leiba-2024-10-23-00
Thanks for this document and registering these profiles. They appear to cover the necessary substance, and I have only two small editorial comments: — Section 2.2.1 — A surrogate which occurs in text encoded in any transformation format other than UTF-16 has no meaning and may cause malfunction in software that encounters it. In particular, it is impossible to represent a surrogate in well-formed UTF-8. I think this is a bit confusingly put — I find the combination of “impossible” and “well-formed” to be correct but unclear. The issue is dealt with later, in Section 3, but here might it make more sense to change “impossible” to “forbidden”? — Section 3 — [RFC9413] emphasizes that when encountering problematic input, software should consider the field as a whole, not individual code points or bytes. 9413 says a bunch of things, and I can’t figure out what, specifically, you’re referring to here. Can you add at least a section reference, and perhaps a quotation (as opposed to paraphrasing or summarizing)?