Date: Wed, 19 Jan 2022 11:40:17 +0100
Hello,
Concerning your request here
https://github.com/sg16-unicode/sg16/issues/48#issuecomment-1014698519
For WG21, please follow the procedure here
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
Adding Aaron Ballman who can help you with the WG14 side of things.
Concerning your request here
https://github.com/sg16-unicode/sg16/issues/48#issuecomment-1014698519
For WG21, please follow the procedure here
https://isocpp.org/std/standing-documents/sd-7-mailing-procedures-and-how-to-write-papers
Adding Aaron Ballman who can help you with the WG14 side of things.
--- It might be best to synchronize with SG16 (unicode study group) as suggested by Tom before going to the C committee though. Note that C++ already accepted P1949 and is reaching design freeze - but your paper can be considered a bug fix if accepted. C is less advanced with their paper <https://www9.open-std.org/JTC1/SC22/WG14/www/docs/n2836.pdf>, but they are also reaching design freeze, and we are trying to keep both languages in sync. ---- Concerning your paper, both committees need to decide whether security considerations should be part of the standard, rather than being quality-of-implementation, hopefully come with a consistent answer. >From there the paper can be refined and... you will need specification wording, which is likely to be different for both languages. I hope that helps with the organization side of things. --- Now, for my unsolicited opinions: Great paper! However, I'm afraid security considerations are a moving target and keeping them as warnings/QoI avoid a huge burden on the committee(s) while granting more flexibility to implementers. In particular the set allowed/disallowed/recommended scripts is likely to be unstable. I expect more research to come out of the unicode consortium in the coming months in regard to security/confusable/bidi attacks. A big selling point of UAX31/P1949 is that it avoids a huge burden on 2 slow moving standard bodies (who have limited Unicode expertise and even less expertise with the impact on specific affected scripts). This is the approach chosen by other languages, notably rust: confusable detection is implemented but not part of the spec. Furthermore the same attack vectors exist for string literals, where standards are even less the right place for these restrictions. Maybe other folks will have very different ideas. I hope this helps, Regard, Corentin Jabot
Received on 2022-01-19 10:40:29