On Wed, Jan 19, 2022 at 5:40 AM Corentin <corentin.jabot_at_[hidden]> wrote:
>
> 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.

Thanks for the ping!

> ---
> 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, but they are also reaching design freeze, and we are trying to keep both languages in sync.

C is past design freeze stages for C23 at this point, so anything we
receive that's a new design intent would be a proposal for C2y or
later. However, a rebuttal paper would be a "continuing proposal" and
so there's a chance we'll still have time to review it before we ship.

In terms of getting the paper submitted to WG14, we document our
process here: http://www.open-std.org/jtc1/sc22/wg14/www/contributing,
but feel free to reach out to me if you have specific questions about
the process.

> ----
>
> 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.

One thing to note is that WG14 tends to be even more conservative
about breaking code than WG21 is. As Jens pointed out in another
reply, the proposal seems like it could plausibly break existing,
working code and that should be called out in the paper with some
examples of what will and won't break. FWIW, it's usually easier to
justify a breakage when the recommendation comes from another
standards body (such as Unicode). So we're definitely interested in
seeing what advice comes out of the Unicode committee, which I believe
is still evolving pretty quickly right now.

~Aaron

>
> I hope this helps,
>
> Regard,
>
> Corentin Jabot
>
>