Having a more of an explanation (along the lines of that Lucas provided) might 
be worthwhile.

The only question here is how that might be tracked.  I would suggest that we 
reject this erratum and open an issue on the spec repository.

On Fri, Nov 4, 2022, at 10:14, Jaikiran Pai wrote:
> Hello Lucas,
>
> Thank you for that explanation. I think your explanation is correct. 
> Your explanation makes it clear to me now what that RFC text meant to 
> convey. I am not a native English speaker, so I don't know if there's a 
> need to edit the RFC text to make this clearer.
>
> -Jaikiran (reporter of this errata)
>
> On 04/11/22 3:37 pm, Lucas Pardue wrote:
>> Hi, 
>> 
>> Speaking as an individual, I think the current RFC text is correct. The 
>> problem that is being described is where 1) a client sends a message smaller 
>> than MAX_FIELD_SECTION_SIZE and might expect that to work but 2) the server 
>> is an intermediary that needs to forward the message onto another server 
>> that, for example,  has a smaller value for MAX_FIELD_SECTION_SIZE 
>> preventing this.
>> 
>> In other words, even if the client plays by the rules of the first hop by 
>> staying under the limit, there is no guarantee that other hops that the 
>> client is not aware of won't reject the message.
>> 
>> Cheers
>> Lucas
>> 
>> On Fri, 4 Nov 2022, 09:49 RFC Errata System, <[email protected]> 
>> wrote:
>>> The following errata report has been submitted for RFC9114,
>>> "HTTP/3".
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid7238
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Jaikiran Pai <[email protected]>
>>> 
>>> Section: 4.2.2
>>> 
>>> Original Text
>>> -------------
>>> Because this limit is applied separately by each implementation that
>>> processes the message, messages below this limit are not guaranteed
>>> to be accepted.
>>> 
>>> 
>>> Corrected Text
>>> --------------
>>> Because this limit is applied separately by each implementation that
>>> processes the message, messages above this limit are not guaranteed
>>> to be accepted.
>>> 
>>> 
>>> Notes
>>> -----
>>> The section 4.2.2 specifies header size constraints and notes that 
>>> implementations can send a SETTINGS frame with a 
>>> SETTINGS_MAX_FIELD_SECTION_SIZE identifier to set a limit on the maximum 
>>> size of the message header. Since this a maximum size, the sentence that 
>>> states that intermediaries aren't guaranteed to accept a message below this 
>>> limit seems odd and I think it should instead say "above this limit".
>>> 
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party  
>>> can log in to change the status and edit the report, if necessary. 
>>> 
>>> --------------------------------------
>>> RFC9114 (draft-ietf-quic-http-34)
>>> --------------------------------------
>>> Title               : HTTP/3
>>> Publication Date    : June 2022
>>> Author(s)           : M. Bishop, Ed.
>>> Category            : PROPOSED STANDARD
>>> Source              : QUIC
>>> Area                : Transport
>>> Stream              : IETF
>>> Verifying Party     : IESG

Reply via email to