Re: [Last-Call] Secdir last call review of draft-ietf-httpbis-http2bis-06

[Sean Turner <[e-mail]>]

Martin,

Perfectly fine with how you resolved all of these.

Cheers,
spt

> On Dec 7, 2021, at 01:12, Martin Thomson <[e-mail]> wrote:
> 
> Hey Sean,
> 
> Most of your changes are pretty straightforward and easy to address.   Thanks for the review.
> 
> You can review the changes I'm proposing here: https://github.com/httpwg/http2-spec/pull/1001
> 
> On Tue, Dec 7, 2021, at 15:19, Sean Turner via Datatracker wrote:
>> s3.3 (editorial): Even though s3 is clear that this section is about starting
>> with http, I would have thought that the last sentence in para 2 would have
>> been the very 1st sentence in the section to make that point very clear in case
>> it missed in s3.
> 
> Yeah, this is a little buried.  At the same time, I do somewhat like the natural flow that this text has.  The pull request above tries to pull out the important piece, but I'm not sure that I made it better in the process.  We'll kick it around some.
> 
>> 5.2.1/s5.2.2 (question): s5.2.1 indicates flow control cannot be disabled, but
>> in s5.2.2 you explain how to do exactly that. In s5.2.1, are you really saying
>> you can’t skip implementing the flow control mechanism and frames related to
>> connection control, i.e., WINDOW_UPDATE?
> 
> Good question.  I've clarified by saying that endpoints have to respect flow control set by their peer, even though they can opt out of setting limits of their own.  The original was incorrect-ish, but I was never motivated to fix it before.
> 
>> s7 (question): Since we already have h3, is it worth adding an h3 required
>> error?
> 
> I don't think we need it for various reasons, mostly because HTTP/1.1 is very much lowest common denominator, from which we can kick off Alt-Svc and other stuff.  We've discussed various options in this space and we continue to have those discussions, but I don't get the impression that the HTTP11_REQUIRED thing is anything more than safety valve.
> 
>> s8.3.1 (question): s8.3.1 includes this:
>> 
>>     The recipient of a HTTP/2 request MUST ignore
>>      the Host header field if :authority is present.
>> 
>> And, it also includes this:
>> 
>>     A server SHOULD treat a request as malformed if
>>     it contains a Host header field that identifies a
>>     different entity to the :authority pseudo-header field.
>> 
>> If I follow the MUST, then is the SHOULD ever followed?
> 
> The MUST was not intended to be so broad; it's OK to validate as well.  What we don't want to see is the Host header field being used to determine the target URI.  I've narrowed it some (hopefully not too much).
> 
>> s11 (confirmation, and I guess this is somewhat related to the last GENART
>> comment): Because you obsolete RFC 7540 with this I-D, I am going with the
>> assumption that the obsoleting is about the protocol and not about the
>> registries. As a result, there’s no need to copy the IANA instructions for
>> what’s in 7540 to this I-D.
> 
> Yeah, I don't know that we're ever going to get this right, but I think that we can rely on what is in the registries already and save making another copy.  FWIW, IANA got the changes absolutely right first time, so I don't think this is going to produce a bad result.  It's just a bit odd, that's all.
> 
>> s12.1 (question): Is it worth referring to 8446bis instead of RFC 8446?
> 
> I am not sure that I want to wait behind that.  As that particular change is easy, it's something we can do if the stars align at any time before AUTH48, so I've been putting off that decision in the hopes that we can go out together.  Of course, I was hoping that this could go out with HTTP/3 and all the other HTTP docs, but that opportunity seems to have passed.
> 
> Thanks,
> Martin