[netconf] Re: Francesca Palombini's Discuss on draft-ietf-netconf-http-client-server-23: (with DISCUSS)

[Mahesh Jethanandani <[e-mail]>]

Hi Mark,

Francesca’s DISCUSS, which is a proxy for your HTTPDIR review was discussed in the telechat last Thursday. I am following up to find out if Kent’s reply below addresses your concerns or not. If my understanding is correct, the main sticking point is the client trying to specify a HTTP version it wants to use, and its possible impact on the HTTP ecosystem. 

Let us know. Thanks.

> On Aug 20, 2024, at 10:25 PM, Kent Watsen <[e-mail]> wrote:
> 
>>> Negotiating version at runtime (startup handshake) is common practice.   The way it usually goes is that the client has a list of what it allows, and the server has a list of what it supports, and the latest/newest common version is selected.  This is how it works in HTTP also, yes?
>> 
>> No. See:
>> 
>> https://httpwg.org/specs/rfc9112.html#http.version
>> https://httpwg.org/specs/rfc9113.html#starting
>> https://httpwg.org/specs/rfc9114.html#discovery
> 
> Fine, but your point is only made because HTTP keeps changing its transport  ;)
> 
> Assuming HTTP/4 stays with QUIC, then RFC 7301, Section 1 says:
> 
>    With ALPN, the client sends the list of supported application
>    protocols as part of the TLS ClientHello message.  The server
>    chooses a protocol and sends the selected protocol as part of
>    the TLS ServerHello message.
> 
> In such a case, the client’s ALPN list would be [h3, h4], and the server returns one or the other, depending on what it supports, which is effectively what I wrote. 
> 
> 
> I also note that RFC 9114 Section 3.1 says:
> 
>    A client MAY attempt access to a resource with an "https" URI by
>    resolving the host identifier to an IP address, establishing a
>    QUIC connection to that address on the indicated port (including
>    validation of the server certificate as described above), and
>    sending an HTTP/3 request message targeting the URI to the server
>    over that secured connection. 
> 
> This optimization is possible if the client knows it only wants QUIC-based HTTP.   This is faster than first establishing an HTTP/2 connection and switching after receiving the "alt-svc” header.  This is also faster than the client optimistically switching after receiving a "TCP RST”, assuming the server isn't listening on tcp/443.
> 
> 
>>> Let’s say there exists an HTTP-client that requires multiplexing, so it requires at least HTTP/2.  But it connects to a server that only supports HTTP/1.1.  IMO the negotiation should fail, letting the HTTP-client to try another server.  Isn’t this proper?
>> 
>> A "HTTP-client that requires multiplexing" (i.e., an application using HTTP that wants to multiplex) can use multiple HTTP/1 connections, or HTTP/2, or HTTP/3, or...
> 
> It was just an example.  The general point is that each HTTP version comes with a set of features (e.g., scalability, performance, security, etc.) and a client may require a specific feature-set.
> 
> 
>>> The configuration -23 regards setting the client’s "list of what it allows".  It can be a list of versions, or the special wildcard value “any”.   It is expected that this “list of versions" will feed into the negotiation.  IDK, maybe you thought that the draft was always setting the client to a single version?
>> 
>> No; I'm only attempting to make sure that your specification doesn't actively harm the HTTP ecosystem.
> 
> Good - and thank you!
> 
> 
>> Constraining the available versions is one way that can happen.
> 
> Can you provide a scenario where the client being configured to use specific versions harms the HTTP ecosystem?
> 
> 
>> I continue to be concerned that you're defining a configuration language for HTTP without a strong understanding of the protocol's core concepts or common implementation patterns. 
> 
> It could also be that you don’t appreciate that, by nature of this being “configuration”, it is not a "first contact” scenario.  That is, this is much more like a script using `curl` than a user using a browser.
> 
> 
> Thanks again!
> Kent
> 
> 


Mahesh Jethanandani
[e-mail]