________________________________ From: Tatuya Jinmei via Datatracker <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) > - 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
Received on Friday, 12 September 2025 19:38:56 UTC