Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Chris Harrelson]

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  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
>>
>> victor...@chromium.org, miketa...@chromium.org, david...@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  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
>> 
>>
>> 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-posi

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

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  
> 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 
>>>
>>> victor...@chromium.org, miketa...@chromium.org, david...@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  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 
>>> 
>>>
>>> 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

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Yoav Weiss (@Shopify)]

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

 victor...@chromium.org, miketa...@chromium.org, david...@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  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
 

 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
 HTT

RE: [blink-dev] Re: Intent to Ship: New ALPS code point

['Erik Anderson' via blink-dev]

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) 
Sent: Monday, January 22, 2024 7:39 AM
To: Victor Tan 
Cc: blink-dev ; Chris Harrelson 
; David Benjamin ; Mike Taylor 

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 
mailto:victor...@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 
mailto:miketa...@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

victor...@chromium.org<mailto:victor...@chromium.org>, 
miketa...@chromium.org<mailto:miketa...@chromium.org>, 
david...@chromium.org<mailto:david...@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 T

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

['Victor Tan' via blink-dev]

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)  
> *Sent:* Monday, January 22, 2024 7:39 AM
> *To:* Victor Tan 
> *Cc:* blink-dev ; Chris Harrelson <
> chri...@chromium.org>; David Benjamin ; Mike Taylor 
> 
> *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  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  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 TL

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

['Victor Tan' via blink-dev]

To be clarify,  currently David is not working on the standardizing ALPS 
feature.  


On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:

> 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)  
>> *Sent:* Monday, January 22, 2024 7:39 AM
>> *To:* Victor Tan 
>> *Cc:* blink-dev ; Chris Harrelson <
>> chri...@chromium.org>; David Benjamin ; Mike 
>> Taylor 
>> *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  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  
>> 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

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Rick Byers]

Oof, I agree it's not good that the only documentation for the actual code
point value is in Chromium code - that's the sort of thing our blink I2S
process is supposed to prevent. In addition to confusion, there's also
potential IP-risk downsides to this. Our blink process is generally to
block shipping on the existence of some specification for everything
necessary for a compatible implementation in a forum that ensures IP
protection. While this isn't typically an adoption barrier for many
companies, I know it has been in the past for some (including Microsoft).
This doesn't mean we have to block on getting consensus in the "right"
standards venue, we can just do a monkey-patch spec in a venue like the
WICG, or an unlanded PR in a formal WG where the PR counts as an IP
contribution. Then we can ship it as an "incubation" while doing the
standards maturation work in parallel. Erik, can you comment on the extent
to which such incubation spec work would help with Microsoft adoption?

Victor, is there any chance you can throw something together quickly (spec
PR or monkey-patch) that would cover the gaps in what's necessary for
compatible implementations? This particular delta seems very tiny and
straightforward to me, so I was originally thinking I'd just approve it.
But in principle I don't think we should be continuing to approve changes
to APIs which we realize are struggling with adoption due to the standards
work not quite being up to our I2S bar.

Erik, thank you for your offer of help on the standardization front! It
definitely sounds to me like we should be pushing on the full standards
effort in parallel to this specific intent. Having Microsoft and Google
work together on that would hopefully be able to accelerate it.

Rick


On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
blink-dev@chromium.org> wrote:

> To be clarify,  currently David is not working on the standardizing ALPS
> feature.
>
>
> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>
>> 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) 
>>> *Sent:* Monday, January 22, 2024 7:39 AM
>>> *To:* Victor Tan 
>>> *Cc:* blink-dev ; Chris Harrelson <
>>> chri...@chromium.org>; David Benjamin ; Mike
>>> Taylor 
>>> *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  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 
>>> 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 clien

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Yoav Weiss (@Shopify)]

On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:

> Oof, I agree it's not good that the only documentation for the actual code
> point value is in Chromium code - that's the sort of thing our blink I2S
> process is supposed to prevent. In addition to confusion, there's also
> potential IP-risk downsides to this. Our blink process is generally to
> block shipping on the existence of some specification for everything
> necessary for a compatible implementation in a forum that ensures IP
> protection. While this isn't typically an adoption barrier for many
> companies, I know it has been in the past for some (including Microsoft).
> This doesn't mean we have to block on getting consensus in the "right"
> standards venue, we can just do a monkey-patch spec in a venue like the
> WICG, or an unlanded PR in a formal WG where the PR counts as an IP
> contribution. Then we can ship it as an "incubation" while doing the
> standards maturation work in parallel. Erik, can you comment on the extent
> to which such incubation spec work would help with Microsoft adoption?
>
> Victor, is there any chance you can throw something together quickly (spec
> PR or monkey-patch) that would cover the gaps in what's necessary for
> compatible implementations? This particular delta seems very tiny and
> straightforward to me, so I was originally thinking I'd just approve it.
> But in principle I don't think we should be continuing to approve changes
> to APIs which we realize are struggling with adoption due to the standards
> work not quite being up to our I2S bar.
>

+1 to defining these codepoints somewhere. Where are such codepoints
typically defined? I'd have assumed they'd go into one of the relevant
I-Ds..


>
> Erik, thank you for your offer of help on the standardization front! It
> definitely sounds to me like we should be pushing on the full standards
> effort in parallel to this specific intent. Having Microsoft and Google
> work together on that would hopefully be able to accelerate it.
>
> Rick
>
>
> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> To be clarify,  currently David is not working on the standardizing ALPS
>> feature.
>>
>>
>> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>>
>>> 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) 
>>>> *Sent:* Monday, January 22, 2024 7:39 AM
>>>> *To:* Victor Tan 
>>>> *Cc:* blink-dev ; Chris Harrelson <
>>>> chri...@chromium.org>; David Benjamin ; Mike
>>>> Taylor 
>>>> *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 
>>>> 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

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

Rick, thanks for question, I will create a PR on the ALPS RFC draft to 
document the new code point regarding the early experiment. 

On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:

> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:
>
>> Oof, I agree it's not good that the only documentation for the actual 
>> code point value is in Chromium code - that's the sort of thing our blink 
>> I2S process is supposed to prevent. In addition to confusion, there's also 
>> potential IP-risk downsides to this. Our blink process is generally to 
>> block shipping on the existence of some specification for everything 
>> necessary for a compatible implementation in a forum that ensures IP 
>> protection. While this isn't typically an adoption barrier for many 
>> companies, I know it has been in the past for some (including Microsoft). 
>> This doesn't mean we have to block on getting consensus in the "right" 
>> standards venue, we can just do a monkey-patch spec in a venue like the 
>> WICG, or an unlanded PR in a formal WG where the PR counts as an IP 
>> contribution. Then we can ship it as an "incubation" while doing the 
>> standards maturation work in parallel. Erik, can you comment on the extent 
>> to which such incubation spec work would help with Microsoft adoption?
>>
>> Victor, is there any chance you can throw something together quickly 
>> (spec PR or monkey-patch) that would cover the gaps in what's necessary for 
>> compatible implementations? This particular delta seems very tiny and 
>> straightforward to me, so I was originally thinking I'd just approve it. 
>> But in principle I don't think we should be continuing to approve changes 
>> to APIs which we realize are struggling with adoption due to the standards 
>> work not quite being up to our I2S bar.
>>
>
> +1 to defining these codepoints somewhere. Where are such codepoints 
> typically defined? I'd have assumed they'd go into one of the relevant 
> I-Ds..
>   
>
>>
>> Erik, thank you for your offer of help on the standardization front! It 
>> definitely sounds to me like we should be pushing on the full standards 
>> effort in parallel to this specific intent. Having Microsoft and Google 
>> work together on that would hopefully be able to accelerate it.
>>
>> Rick
>>
>>
>> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> To be clarify,  currently David is not working on the standardizing ALPS 
>>> feature.  
>>>
>>>
>>> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>>>
>>>> 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)  
>>>>> *Sent:* Monday, January 22, 2024 7:39 AM
>>>>> *To:* Victor Tan 
>>>>> *Cc:* blink-dev ; Chris Harrelson <
>>>>> chri...@chromium.org>; David Benjamin ; Mike 
>>>>> Taylor 
>>>>> *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, J

RE: [blink-dev] Re: Intent to Ship: New ALPS code point

['Erik Anderson' via blink-dev]

Thanks, it will be helpful to make sure this is documented outside of Chromium. 
I will also chat with some folks on Microsoft’s end that both own server 
implementations and have more IETF experience to explore how we can help with 
moving things forward.

From: Victor Tan 
Sent: Wednesday, January 24, 2024 9:00 AM
To: blink-dev 
Cc: Yoav Weiss ; blink-dev ; 
Erik Anderson ; Chris Harrelson 
; David Benjamin ; Mike Taylor 
; Victor Tan ; Rick Byers 

Subject: Re: [blink-dev] Re: Intent to Ship: New ALPS code point

You don't often get email from 
victor...@chromium.org<mailto:victor...@chromium.org>. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
Rick, thanks for question, I will create a PR on the ALPS RFC draft to document 
the new code point regarding the early experiment.
On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:
On Wed, Jan 24, 2024 at 4:48 PM Rick Byers 
mailto:rby...@chromium.org>> wrote:
Oof, I agree it's not good that the only documentation for the actual code 
point value is in Chromium code - that's the sort of thing our blink I2S 
process is supposed to prevent. In addition to confusion, there's also 
potential IP-risk downsides to this. Our blink process is generally to block 
shipping on the existence of some specification for everything necessary for a 
compatible implementation in a forum that ensures IP protection. While this 
isn't typically an adoption barrier for many companies, I know it has been in 
the past for some (including Microsoft). This doesn't mean we have to block on 
getting consensus in the "right" standards venue, we can just do a monkey-patch 
spec in a venue like the WICG, or an unlanded PR in a formal WG where the PR 
counts as an IP contribution. Then we can ship it as an "incubation" while 
doing the standards maturation work in parallel. Erik, can you comment on the 
extent to which such incubation spec work would help with Microsoft adoption?

Victor, is there any chance you can throw something together quickly (spec PR 
or monkey-patch) that would cover the gaps in what's necessary for compatible 
implementations? This particular delta seems very tiny and straightforward to 
me, so I was originally thinking I'd just approve it. But in principle I don't 
think we should be continuing to approve changes to APIs which we realize are 
struggling with adoption due to the standards work not quite being up to our 
I2S bar.

+1 to defining these codepoints somewhere. Where are such codepoints typically 
defined? I'd have assumed they'd go into one of the relevant I-Ds..


Erik, thank you for your offer of help on the standardization front! It 
definitely sounds to me like we should be pushing on the full standards effort 
in parallel to this specific intent. Having Microsoft and Google work together 
on that would hopefully be able to accelerate it.

Rick


On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
To be clarify,  currently David is not working on the standardizing ALPS 
feature.

On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
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) mailto:yoav...@chromium.org>>
Sent: Monday, January 22, 2024 7:39 AM
To: Victor Tan mailto:vict...@chromium.org>>
Cc: blink-dev mailto:blin...@chromium.org>>; Chris 
Harrelson mailto:chri...@chromium.org>>; David Benjamin 
mailto:davi...@chromium.org>>; Mike Taylor 
mailto: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 
mailto: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: w

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

create a PR for the code point change on the RFC draft, will work on 
there: https://github.com/vasilvv/tls-alps/pull/15, thanks. 

On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik Anderson wrote:

> Thanks, it will be helpful to make sure this is documented outside of 
> Chromium. I will also chat with some folks on Microsoft’s end that both own 
> server implementations and have more IETF experience to explore how we can 
> help with moving things forward.
>
>  
>
> *From:* Victor Tan  
> *Sent:* Wednesday, January 24, 2024 9:00 AM
> *To:* blink-dev 
> *Cc:* Yoav Weiss ; blink-dev <
> blink-dev@chromium.org>; Erik Anderson ; 
> Chris Harrelson ; David Benjamin <
> david...@chromium.org>; Mike Taylor ; Victor Tan <
> victor...@chromium.org>; Rick Byers 
> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>
>  
>
> You don't often get email from victor...@chromium.org. Learn why this is 
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> Rick, thanks for question, I will create a PR on the ALPS RFC draft to 
> document the new code point regarding the early experiment. 
>
> On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:
>
> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:
>
> Oof, I agree it's not good that the only documentation for the actual code 
> point value is in Chromium code - that's the sort of thing our blink I2S 
> process is supposed to prevent. In addition to confusion, there's also 
> potential IP-risk downsides to this. Our blink process is generally to 
> block shipping on the existence of some specification for everything 
> necessary for a compatible implementation in a forum that ensures IP 
> protection. While this isn't typically an adoption barrier for many 
> companies, I know it has been in the past for some (including Microsoft). 
> This doesn't mean we have to block on getting consensus in the "right" 
> standards venue, we can just do a monkey-patch spec in a venue like the 
> WICG, or an unlanded PR in a formal WG where the PR counts as an IP 
> contribution. Then we can ship it as an "incubation" while doing the 
> standards maturation work in parallel. Erik, can you comment on the extent 
> to which such incubation spec work would help with Microsoft adoption?
>
>  
>
> Victor, is there any chance you can throw something together quickly (spec 
> PR or monkey-patch) that would cover the gaps in what's necessary for 
> compatible implementations? This particular delta seems very tiny and 
> straightforward to me, so I was originally thinking I'd just approve it. 
> But in principle I don't think we should be continuing to approve changes 
> to APIs which we realize are struggling with adoption due to the standards 
> work not quite being up to our I2S bar.
>
>  
>
> +1 to defining these codepoints somewhere. Where are such codepoints 
> typically defined? I'd have assumed they'd go into one of the relevant 
> I-Ds..
>
>   
>
>  
>
> Erik, thank you for your offer of help on the standardization front! It 
> definitely sounds to me like we should be pushing on the full standards 
> effort in parallel to this specific intent. Having Microsoft and Google 
> work together on that would hopefully be able to accelerate it.
>
>  
>
> Rick
>
>  
>
>  
>
> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> To be clarify,  currently David is not working on the standardizing ALPS 
> feature.   
>
>  
>
> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>
> 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)  
> *Sent:* Monday, January 22, 2024 7:39 AM
> *To:* Victor Tan 
> *Cc:* blink-dev ; Chris Harrelson <
> chri...@chromium.o

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Victor Tan]

the code point PR is merged. Feel free to take a look again. Thanks. 

On Wednesday, January 24, 2024 at 3:34:44 PM UTC-5 Victor Tan wrote:

> create a PR for the code point change on the RFC draft, will work on 
> there: https://github.com/vasilvv/tls-alps/pull/15, thanks. 
>
> On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik Anderson wrote:
>
>> Thanks, it will be helpful to make sure this is documented outside of 
>> Chromium. I will also chat with some folks on Microsoft’s end that both own 
>> server implementations and have more IETF experience to explore how we can 
>> help with moving things forward.
>>
>>  
>>
>> *From:* Victor Tan  
>> *Sent:* Wednesday, January 24, 2024 9:00 AM
>> *To:* blink-dev 
>> *Cc:* Yoav Weiss ; blink-dev <
>> blink-dev@chromium.org>; Erik Anderson ; 
>> Chris Harrelson ; David Benjamin <
>> david...@chromium.org>; Mike Taylor ; Victor Tan 
>> ; Rick Byers 
>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>>
>>  
>>
>> You don't often get email from victor...@chromium.org. Learn why this is 
>> important <https://aka.ms/LearnAboutSenderIdentification>
>>
>> Rick, thanks for question, I will create a PR on the ALPS RFC draft to 
>> document the new code point regarding the early experiment. 
>>
>> On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:
>>
>> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:
>>
>> Oof, I agree it's not good that the only documentation for the actual 
>> code point value is in Chromium code - that's the sort of thing our blink 
>> I2S process is supposed to prevent. In addition to confusion, there's also 
>> potential IP-risk downsides to this. Our blink process is generally to 
>> block shipping on the existence of some specification for everything 
>> necessary for a compatible implementation in a forum that ensures IP 
>> protection. While this isn't typically an adoption barrier for many 
>> companies, I know it has been in the past for some (including Microsoft). 
>> This doesn't mean we have to block on getting consensus in the "right" 
>> standards venue, we can just do a monkey-patch spec in a venue like the 
>> WICG, or an unlanded PR in a formal WG where the PR counts as an IP 
>> contribution. Then we can ship it as an "incubation" while doing the 
>> standards maturation work in parallel. Erik, can you comment on the extent 
>> to which such incubation spec work would help with Microsoft adoption?
>>
>>  
>>
>> Victor, is there any chance you can throw something together quickly 
>> (spec PR or monkey-patch) that would cover the gaps in what's necessary for 
>> compatible implementations? This particular delta seems very tiny and 
>> straightforward to me, so I was originally thinking I'd just approve it. 
>> But in principle I don't think we should be continuing to approve changes 
>> to APIs which we realize are struggling with adoption due to the standards 
>> work not quite being up to our I2S bar.
>>
>>  
>>
>> +1 to defining these codepoints somewhere. Where are such codepoints 
>> typically defined? I'd have assumed they'd go into one of the relevant 
>> I-Ds..
>>
>>   
>>
>>  
>>
>> Erik, thank you for your offer of help on the standardization front! It 
>> definitely sounds to me like we should be pushing on the full standards 
>> effort in parallel to this specific intent. Having Microsoft and Google 
>> work together on that would hopefully be able to accelerate it.
>>
>>  
>>
>> Rick
>>
>>  
>>
>>  
>>
>> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>> To be clarify,  currently David is not working on the standardizing ALPS 
>> feature.   
>>
>>  
>>
>> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>>
>> 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?
>>
>>

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Yoav Weiss (@Shopify)]

LGTM1

Thanks for including these values in the I-D.

On Fri, Feb 2, 2024 at 9:17 PM Victor Tan  wrote:

> the code point PR is merged. Feel free to take a look again. Thanks.
>
> On Wednesday, January 24, 2024 at 3:34:44 PM UTC-5 Victor Tan wrote:
>
>> create a PR for the code point change on the RFC draft, will work on
>> there: https://github.com/vasilvv/tls-alps/pull/15, thanks.
>>
>> On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik Anderson wrote:
>>
>>> Thanks, it will be helpful to make sure this is documented outside of
>>> Chromium. I will also chat with some folks on Microsoft’s end that both own
>>> server implementations and have more IETF experience to explore how we can
>>> help with moving things forward.
>>>
>>>
>>>
>>> *From:* Victor Tan 
>>> *Sent:* Wednesday, January 24, 2024 9:00 AM
>>> *To:* blink-dev 
>>> *Cc:* Yoav Weiss ; blink-dev <
>>> blink-dev@chromium.org>; Erik Anderson ;
>>> Chris Harrelson ; David Benjamin <
>>> david...@chromium.org>; Mike Taylor ; Victor
>>> Tan ; Rick Byers 
>>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>>>
>>>
>>>
>>> You don't often get email from victor...@chromium.org. Learn why this
>>> is important <https://aka.ms/LearnAboutSenderIdentification>
>>>
>>> Rick, thanks for question, I will create a PR on the ALPS RFC draft to
>>> document the new code point regarding the early experiment.
>>>
>>> On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:
>>>
>>> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:
>>>
>>> Oof, I agree it's not good that the only documentation for the actual
>>> code point value is in Chromium code - that's the sort of thing our blink
>>> I2S process is supposed to prevent. In addition to confusion, there's also
>>> potential IP-risk downsides to this. Our blink process is generally to
>>> block shipping on the existence of some specification for everything
>>> necessary for a compatible implementation in a forum that ensures IP
>>> protection. While this isn't typically an adoption barrier for many
>>> companies, I know it has been in the past for some (including Microsoft).
>>> This doesn't mean we have to block on getting consensus in the "right"
>>> standards venue, we can just do a monkey-patch spec in a venue like the
>>> WICG, or an unlanded PR in a formal WG where the PR counts as an IP
>>> contribution. Then we can ship it as an "incubation" while doing the
>>> standards maturation work in parallel. Erik, can you comment on the extent
>>> to which such incubation spec work would help with Microsoft adoption?
>>>
>>>
>>>
>>> Victor, is there any chance you can throw something together quickly
>>> (spec PR or monkey-patch) that would cover the gaps in what's necessary for
>>> compatible implementations? This particular delta seems very tiny and
>>> straightforward to me, so I was originally thinking I'd just approve it.
>>> But in principle I don't think we should be continuing to approve changes
>>> to APIs which we realize are struggling with adoption due to the standards
>>> work not quite being up to our I2S bar.
>>>
>>>
>>>
>>> +1 to defining these codepoints somewhere. Where are such codepoints
>>> typically defined? I'd have assumed they'd go into one of the relevant
>>> I-Ds..
>>>
>>>
>>>
>>>
>>>
>>> Erik, thank you for your offer of help on the standardization front! It
>>> definitely sounds to me like we should be pushing on the full standards
>>> effort in parallel to this specific intent. Having Microsoft and Google
>>> work together on that would hopefully be able to accelerate it.
>>>
>>>
>>>
>>> Rick
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
>>> To be clarify,  currently David is not working on the standardizing ALPS
>>> feature.
>>>
>>>
>>>
>>> On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote:
>>>
>>> Hi Erik,
>>>
>>> We are actively working on it, but we need to put more efforts to
>>> standardization.
&

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Domenic Denicola]

LGTM2

On Mon, Feb 5, 2024 at 5:38 PM Yoav Weiss (@Shopify) 
wrote:

> LGTM1
>
> Thanks for including these values in the I-D.
>
> On Fri, Feb 2, 2024 at 9:17 PM Victor Tan  wrote:
>
>> the code point PR is merged. Feel free to take a look again. Thanks.
>>
>> On Wednesday, January 24, 2024 at 3:34:44 PM UTC-5 Victor Tan wrote:
>>
>>> create a PR for the code point change on the RFC draft, will work on
>>> there: https://github.com/vasilvv/tls-alps/pull/15, thanks.
>>>
>>> On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik Anderson wrote:
>>>
>>>> Thanks, it will be helpful to make sure this is documented outside of
>>>> Chromium. I will also chat with some folks on Microsoft’s end that both own
>>>> server implementations and have more IETF experience to explore how we can
>>>> help with moving things forward.
>>>>
>>>>
>>>>
>>>> *From:* Victor Tan 
>>>> *Sent:* Wednesday, January 24, 2024 9:00 AM
>>>> *To:* blink-dev 
>>>> *Cc:* Yoav Weiss ; blink-dev <
>>>> blink-dev@chromium.org>; Erik Anderson ;
>>>> Chris Harrelson ; David Benjamin <
>>>> david...@chromium.org>; Mike Taylor ; Victor
>>>> Tan ; Rick Byers 
>>>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point
>>>>
>>>>
>>>>
>>>> You don't often get email from victor...@chromium.org. Learn why this
>>>> is important <https://aka.ms/LearnAboutSenderIdentification>
>>>>
>>>> Rick, thanks for question, I will create a PR on the ALPS RFC draft to
>>>> document the new code point regarding the early experiment.
>>>>
>>>> On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote:
>>>>
>>>> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers  wrote:
>>>>
>>>> Oof, I agree it's not good that the only documentation for the actual
>>>> code point value is in Chromium code - that's the sort of thing our blink
>>>> I2S process is supposed to prevent. In addition to confusion, there's also
>>>> potential IP-risk downsides to this. Our blink process is generally to
>>>> block shipping on the existence of some specification for everything
>>>> necessary for a compatible implementation in a forum that ensures IP
>>>> protection. While this isn't typically an adoption barrier for many
>>>> companies, I know it has been in the past for some (including Microsoft).
>>>> This doesn't mean we have to block on getting consensus in the "right"
>>>> standards venue, we can just do a monkey-patch spec in a venue like the
>>>> WICG, or an unlanded PR in a formal WG where the PR counts as an IP
>>>> contribution. Then we can ship it as an "incubation" while doing the
>>>> standards maturation work in parallel. Erik, can you comment on the extent
>>>> to which such incubation spec work would help with Microsoft adoption?
>>>>
>>>>
>>>>
>>>> Victor, is there any chance you can throw something together quickly
>>>> (spec PR or monkey-patch) that would cover the gaps in what's necessary for
>>>> compatible implementations? This particular delta seems very tiny and
>>>> straightforward to me, so I was originally thinking I'd just approve it.
>>>> But in principle I don't think we should be continuing to approve changes
>>>> to APIs which we realize are struggling with adoption due to the standards
>>>> work not quite being up to our I2S bar.
>>>>
>>>>
>>>>
>>>> +1 to defining these codepoints somewhere. Where are such codepoints
>>>> typically defined? I'd have assumed they'd go into one of the relevant
>>>> I-Ds..
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Erik, thank you for your offer of help on the standardization front! It
>>>> definitely sounds to me like we should be pushing on the full standards
>>>> effort in parallel to this specific intent. Having Microsoft and Google
>>>> work together on that would hopefully be able to accelerate it.
>>>>
>>>>
>>>>
>>>> Rick
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev <
&g

Re: [blink-dev] Re: Intent to Ship: New ALPS code point

[Daniel Bratell]

LGTM3

/Daniel

On 2024-02-05 11:47, Domenic Denicola wrote:

LGTM2

On Mon, Feb 5, 2024 at 5:38 PM Yoav Weiss (@Shopify) 
 wrote:


LGTM1

Thanks for including these values in the I-D.

On Fri, Feb 2, 2024 at 9:17 PM Victor Tan 
wrote:

the code point PR is merged. Feel free to take a look again.
Thanks.

On Wednesday, January 24, 2024 at 3:34:44 PM UTC-5 Victor Tan
wrote:

create a PR for the code point change on the RFC draft,
will work on there:
https://github.com/vasilvv/tls-alps/pull/15, thanks.

On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik
Anderson wrote:

Thanks, it will be helpful to make sure this is
documented outside of Chromium. I will also chat with
some folks on Microsoft’s end that both own server
implementations and have more IETF experience to
explore how we can help with moving things forward.

*From:*Victor Tan 
*Sent:* Wednesday, January 24, 2024 9:00 AM
*To:* blink-dev 
*Cc:* Yoav Weiss ; blink-dev
; Erik Anderson
; Chris Harrelson
; David Benjamin
; Mike Taylor
; Victor Tan
; Rick Byers 
*Subject:* Re: [blink-dev] Re: Intent to Ship: New
ALPS code point




You don't often get email from victor...@chromium.org.
Learn why this is important
<https://aka.ms/LearnAboutSenderIdentification>



Rick, thanks for question, I will create a PR on the
ALPS RFC draft to document the new code point
regarding the early experiment.

On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5
Yoav Weiss wrote:

On Wed, Jan 24, 2024 at 4:48 PM Rick Byers
 wrote:

Oof, I agree it's not good that the only
documentation for the actual code point value
is in Chromium code - that's the sort of thing
our blink I2S process is supposed to prevent.
In addition to confusion, there's also
potential IP-risk downsides to this. Our blink
process is generally to block shipping on the
existence of some specification for everything
necessary for a compatible implementation in a
forum that ensures IP protection. While this
isn't typically an adoption barrier for many
companies, I know it has been in the past for
some (including Microsoft). This doesn't mean
we have to block on getting consensus in the
"right" standards venue, we can just do a
monkey-patch spec in a venue like the WICG, or
an unlanded PR in a formal WG where the PR
counts as an IP contribution. Then we can ship
it as an "incubation" while doing the
standards maturation work in parallel. Erik,
can you comment on the extent to which such
incubation spec work would help with Microsoft
adoption?

Victor, is there any chance you can throw
something together quickly (spec PR or
monkey-patch) that would cover the gaps in
what's necessary for compatible
implementations? This particular delta seems
very tiny and straightforward to me, so I was
originally thinking I'd just approve it. But
in principle I don't think we should be
continuing to approve changes to APIs which we
realize are struggling with adoption due to
the standards work not quite being up to our
I2S bar.

+1 to defining these codepoints somewhere. Where
are such codepoints typically defined? I'd have
assumed they'd go into one of the relevant I-Ds..

Erik, thank you for your offer of help on the
standardization front! It definitely sounds to
me like we should be pushing on the full
standards effort in parallel to this specific