Re: draft-ietf-httpbis-optimistic-upgrade-05 telechat Intdir review

Thanks for helping me to understand why this text was confusing.  I've uploaded new text that replaces the "logical converse" framing with a "necessary vs. sufficient conditions" framing: https://github.com/httpwg/http-extensions/commit/e7ef3167533962ed3d7b35d9a6541e5c023ffa82.

I hope this makes the meaning clearer.

Regards,
Ben Schwartz
________________________________
From: JINMEI Tatuya / 神明達哉 <jinmei@wide.ad.jp>
Sent: Tuesday, September 16, 2025 1:25 AM
To: Ben Schwartz <bemasc@meta.com>
Cc: int-dir@ietf.org <int-dir@ietf.org>; draft-ietf-httpbis-optimistic-upgrade.all@ietf.org <draft-ietf-httpbis-optimistic-upgrade.all@ietf.org>; ietf-http-wg@w3.org <ietf-http-wg@w3.org>; last-call@ietf.org <last-call@ietf.org>
Subject: Re: draft-ietf-httpbis-optimistic-upgrade-05 telechat Intdir review

Thank you for the prompt response, and sorry for my delay. I talked about this entire paragraph: However, because of the possibility of rejection, the converse is not true: a client cannot necessarily begin using a new protocol merely because

Thank you for the prompt response, and sorry for my delay.

I talked about this entire paragraph:
   However, because of the possibility of rejection, the converse is not
   true: a client cannot necessarily begin using a new protocol merely
   because it has finished sending the corresponding request message.

I indeed interpreted "converse" in the formal logic sense initially. In fact, while reviewing the draft I tried to transform the RFC9110 text to the IF-THEN form and build the corresponding converse. But, that attempt simply made me more confused, perhaps due to other reasons below.

One source of confusion is that it wasn't obvious whether the clause beginning with 'a client cannot necessarily...' is itself the converse, or a paraphrase of 'the converse is not true.' From context it’s the latter, but the wording made me pause.

I was also confused about how "because of the possibility of rejection" works in the entire paragraph, but now that I understand what you meant, I guess that was mainly due to other issues.

Maybe one other source of confusion is that it's not clear to me whether this paragraph is something already documented somewhere or it's a clarification this draft is making (I guess it's the latter, and what is stated makes sense).

Considering these, I'd do the following if I were an editor:
- Avoid using the logic terminology. I don't see the advantage of it. It rather confused me on my first read as I explained above.
- Make it (a bit) clearer that the "converse is not true" is a clarification of this draft.
- Perhaps it's also better to rearrange this and the last paragraph of this section.

Specifically, we might change the last two paragraphs to:

   In some cases, the client might expect that the protocol transition
   will succeed.  If this expectation is correct, the client might be
   able to reduce delay by immediately sending the first bytes of the
   new protocol "optimistically" as soon as it has finished sending
   the request, without waiting for the server's response.

   It should be noted, however, a client cannot necessarily begin
   using a new protocol merely because it has finished sending the
   corresponding request message, since the server might reject the
   request.  This document explores the security implications of this
   "optimistic" behavior in such cases.

If I'm an outlier here, I'm fine with keeping the current text; I just wanted to share how I got tripped up and offer a concrete alternative.

--
jinmei

On Fri, Sep 12, 2025 at 12:38 PM Ben Schwartz <bemasc@meta.com<mailto:bemasc@meta.com>> wrote:


________________________________
From: Tatuya Jinmei via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>>

...

> I have one possible editorial issue: in section 2, the draft states:
>
>    However, because of the possibility of rejection, the converse is not
>    true: a client cannot necessarily begin using a new protocol merely
>    because it has finished sending the corresponding request message.
>
> It was difficult for me to understand. Specifically,
> - The term “the converse” is ambiguous.

To be clear, this text is referring to the logical converse: https://en.wikipedia.org/wiki/Converse_(logic)<https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Converse_(logic)__;!!Bt8RZUm9aw!9hJMa5g7DSGWd_uSdyb3GM__NrFI2L7M9fapIvco4LQjicSvoqhntUBrbYz_OzEWqZWWKhBk3ODpXg$>

> - The role of “because of the possibility of rejection” is unclear.

This is explaining why the statement is true, but its converse is false.  Rejection is the situation in which the converse fails.

> Based on context, I interpreted the intended meaning as:
>
>    A client is allowed to begin using a new protocol once it has
>    finished sending the corresponding request message, even if the
>    request can be rejected by the server.
>
> At least to me, the latter is much easier to understand. If this interpretation
> is incorrect, the original text may need clarification in case I'm not the only
> confused reader.

I'm not sure which statement you are interpreting.  To clarify:

* RFC 9110 says (paraphrasing) "IF the client **has not** finished sending the request message, THEN it **cannot** begin using an upgraded protocol".
* The logical converse/inverse is "IF the client **has** finished sending the request message, THEN it **can** begin using the upgraded protocol.".  This is equivalent to the statement you wrote above.
* The converse statement is not correct.  Even if the client has finished sending the request message, there are still situations in which it must not begin using the upgraded protocol: if the server responds by rejecting the upgrade.

I'm happy to adjust the text of this paragraph if you see a way to improve its clarity.

--Ben