--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9faba33e-8503-4600-910d-caa72c20be83n%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUqka9zyAWt9eQ0WSd9TpeVObOTgq3Bi8ZWVjUe3ocekfA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MTc2EYT6%2BmGcYrtKhbH-5UFFy%2BGc0_CdmePbUKyGpBTw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-1KMKx7B%3Dk5y1Z0KHj_yzLr3%3D9Sw9nd5yJuDQXExAJjQ%40mail.gmail.com.
How would you all like low-level network protocol changes to be handled? I'm thinking about things like new versions or extensions to TLS. A lot of those changes live entirely on the IETF side of things, without any W3C/WHATWG bits.The changes are, strictly speaking, visible to the overall web platform, so most of the Blink process makes sense. But they don't affect any APIs per se and sometimes not even HTTP, so it's a slightly different audience (more server operators and developers of server software) and a slightly different ecosystem. It's also a somewhat different standardization process.I've typically marked such intents as not needing TAG review (e.g. TLS 1.3), on the assumption that this sort of thing was outside of the TAG's scope. Is that right, or should those also request TAG reviews? (I'm fine either way. Just wanted to check what you all prefer here.)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaC5uEPQ54sLxMBS85tBRCFwbGqdQLW%2BURYMC1oU_caoNA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-1KMKx7B%3Dk5y1Z0KHj_yzLr3%3D9Sw9nd5yJuDQXExAJjQ%40mail.gmail.com.
How would you all like low-level network protocol changes to be handled? I'm thinking about things like new versions or extensions to TLS. A lot of those changes live entirely on the IETF side of things, without any W3C/WHATWG bits.
The changes are, strictly speaking, visible to the overall web platform, so most of the Blink process makes sense. But they don't affect any APIs per se and sometimes not even HTTP, so it's a slightly different audience (more server operators and developers of server software) and a slightly different ecosystem. It's also a somewhat different standardization process.
I've typically marked such intents as not needing TAG review (e.g. TLS 1.3), on the assumption that this sort of thing was outside of the TAG's scope. Is that right, or should those also request TAG reviews? (I'm fine either way. Just wanted to check what you all prefer here.)
To clarify the JS/Wasm position a bit, occasionally there *are* features in TC39 (not sure about the wasm CG) that have significant interaction with the web platform, e.g. WeakRefs. Those features should and do require TAG review, and currently the more web-exposed folks in TC39 (myself, Dan Ehrenberg) have been making sure champions of that kind of proposals request TAG reviews. Since the bulk of JS features do not have such interaction, I very much welcome the default of being not needing TAG reviews.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e8WPWv1T6HkRfErkuSa4iXkewAQRXET20WjVcgfGr-1Zw%40mail.gmail.com.