If we plan to update the document later with more explanations (reflecting on the issue resolution) then rather rejecting we can put it state = "Held for Document Update”.
//Zahed > On 5 Nov 2022, at 10:46, Martin Thomson <m...@lowentropy.net> wrote: > > 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, <rfc-edi...@rfc-editor.org> >>> 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 <jai.forums2...@gmail.com> >>>> >>>> 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
smime.p7s
Description: S/MIME cryptographic signature
