Hi Erik, We are actively working on it, but we need to put more efforts to standardization. In the last serval IETF, David is the only person is talking about the ALPS feature. We'd glad to combine more efforts to move it forward to standardization.
Bests, Victor On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote: > Is the ALPS draft being actively worked on? > > > > Various teams at Microsoft that own web sites leveraging client hints have > expressed interest in using it, but the lack of a finalized standard has > significantly slowed conversations with the teams that own the server code > that would need to add support first. > > > > Are you looking for help in moving standardization forward? > > > > *From:* Yoav Weiss (@Shopify) <yoav...@chromium.org> > *Sent:* Monday, January 22, 2024 7:39 AM > *To:* Victor Tan <vict...@chromium.org> > *Cc:* blink-dev <blin...@chromium.org>; Chris Harrelson < > chri...@chromium.org>; David Benjamin <davi...@chromium.org>; Mike Taylor > <mike...@chromium.org> > *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point > > > > Is the old code point defined somewhere? Would it be possible to add such > a definition to one of the I-Ds? Or is this something that's not > traditionally defined in IETF drafts? > > > > On Mon, Jan 22, 2024 at 4:03 PM Victor Tan <vict...@chromium.org> wrote: > > Currently, It's on the code: > https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247 > > Once we standardize the ALPS RFC draft, we can finalize the value. Hope > this helps. > > On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson wrote: > > Thanks for clarifying. Last question: where in the specifications is the > new 17613 code point documented? > > > > On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor <mike...@chromium.org> wrote: > > In our OWNERS meeting this week, there was some confusion on what's being > proposed here (which is understandable, this isn't quite a typical intent > for web exposed feature). Here's a summary of what we're trying to > accomplish: > > 1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in M96, > which relies on the TLS ALPS protocol extension. > 2) There are 2 parts to this: the client being able to understand > ALPS/ACCEPT_CH (and in return do something useful), and the server being > able to send it. > 3) Because of a (long fixed) bug present in Chromium's implementation, > it's risky for a server to send too much data via ACCEPT_CH, so it's > usefulness is potentially limited. > 4) In order to guarantee that older clients don't have this bug, we > propose to rev the version (aka, code point) at the protocol layer. This > way, if a server sends the new code point and the client understands it, it > can send a larger payload without triggering the bug (which may result in > sad things like a connection being refused). > 5) This is sort of web observable, but right now if servers that support > the old code point continue to send the old code point - nothing will > break. Chromium will support both for now, with hopes to deprecate and > remove the older one in the future when we're confident it won't result in > performance regressions for servers sending ACCEPT_CH (since this is a > performance optimization). > > I hope that helps clear it up, and I'm sure Victor or David will chime in > if I'm getting something wrong. :) > > And to be clear - this isn't a request for a deprecation or removal (yet), > but for shipping the new code point. > > On 1/17/24 11:16 AM, Victor Tan wrote: > > If the server received the new code point, while it doesn't support, the > ALPS extension will ignore. This also mean client might not know the > server's client hints preferences before the first request. Currently, only > few sites using the ALPS extension. As TLS extension is negotiated, the > server need to support both code points during the transition period, after > some time, the server can drop the old one. > > > > On Wednesday, January 17, 2024 at 11:00:13 AM UTC-5 Yoav Weiss wrote: > > On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote: > > *Contact emails* > > vict...@chromium.org, mike...@chromium.org, davi...@chromium.org > > > *Explainer* > > > https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md > > > > *Specification* > > https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability > > https://tools.ietf.org/html/draft-vvv-httpbis-alps > > https://tools.ietf.org/html/draft-vvv-tls-alps > > > > *Summary* > > Shipping a new code point (17613) for TLS ALPS extension to allow adding > more data in the ACCEPT_CH HTTP/2 and HTTP/3 frame. The ACCEPT_CH HTTP/2 > frame with the existing TLS ALPS extension code point (17513) had an > arithmetic overflow bug <https://crbug.com/1292069> in the Chrome ALPS > decoder. It limits the capability to add more than 128 bytes data (in > theory, the problem range is 128 bytes to 255 bytes) to the ACCEPT_CH > frame. With the new ALPS code point, we can fully mitigate the issue. > > > *Blink component* > > Blink>Network>ClientHints > <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints%2C&can=2> > > > *TAG review* > > https://github.com/w3ctag/design-reviews/issues/549 > > > *TAG review status* > > Closed > > > *Risks* > *Interoperability and Compatibility* > > This is switching to a new code point for the TLS ALPS extension. It won’t > change the design of ALPS and ACCEPT_CH mechanism implementation. The main > source of compatibility risk is that it causes conflicts with ALPS > negotiation since some clients could still use the old code point while > others are switching to use the new code point. The ALPS extension could > be ignored if the code point doesn’t match during negotiation, which means > the server's client hints preferences won’t be delivered in the ACCEPT_CH > HTTP/2 and HTTP/3 frame. We mitigate this by enabling servers to support > both code points, monitoring both code points usage and removing the old > ALPS code point support in a future intent once the usage is low enough. We > also split the rollout into two phases: we first start to enable the new > ALPS code point for ACCEPT_CH with HTTP/3 frame in a slow rollout, and > then eventually enable the new code point with HTTP/2 frame. > > > > Does the server have an indication if the client in question supports the > newer code point? > > If not, what would we expect servers that support the newer code point to > do? > > > > > > > > *Edge*: No signals > > *Firefox*: Pending > https://github.com/mozilla/standards-positions/issues/510 > *Safari*: Pending > https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html > > *Web/Framework developers*: > https://twitter.com/Sawtaytoes/status/1369031447940526080 > https://twitter.com/_jayphelps/status/1369023028735148032 > > > > *Activation* > > The site’s TLS and HTTP serving application would need to be updated to > support this new code point. We aren’t aware of many sites using this > feature yet, however. > > > *Debuggability* > > No special DevTools support needed. The effects of the code point change > of ACCEPT_CH frame will be visible in the DevTools’ network tab. Also, the > NetLog will record the ACCEPT_CH frame value if TLS ALPS extension is > negotiated successfully. > > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, Chrome OS, Android, and Android WebView)?* > > Yes > > > *Is this feature fully tested by **web-platform-tests* > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > *?* > > No, this feature is tested with browser-side tests. We can’t test > TLS-adjacent features currently through web-platform-tests. See this issue: > https://github.com/web-platform-tests/wpt/issues/20159 > > > *Flag name* > > UseNewAlpsCodepointHttp2 > > UseNewAlpsCodepointQUIC > > > *Tracking bug* > > b/289087287 > > > *Launch bug* > > https://launch.corp.google.com/launch/4299022 > > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5149147365900288 > > -- > > 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/c704d985-a5cc-4e5e-99b0-1f78cc4428e6%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c704d985-a5cc-4e5e-99b0-1f78cc4428e6%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > 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/CAOmohSJQu%2BjtN9hQ302XVW1_Y1b8BUYQUDr4ujMavPU1vU7%2Bzw%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJQu%2BjtN9hQ302XVW1_Y1b8BUYQUDr4ujMavPU1vU7%2Bzw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/235af7f9-013d-4133-be0a-4b90e589b451n%40chromium.org.
