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

[Mark Nottingham <[e-mail]>]

> 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

> 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...

> 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. Constraining the available versions is one way that can happen.

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. 

Cheers,


--
Mark Nottingham   https://www.mnot.net/