- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 3 Feb 2021 10:38:00 +1100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, ietf-http-wg@w3.org
If a non-backwards-compatible change is needed to the semantics of HTTP, it's a different protocol. If you need to negotiate something, negotiate the additional feature, not the version of HTTP semantics. Otherwise we'll have HTTP2022-over-HTTP3 and people's heads will (further) explode. Cheers, > On 3 Feb 2021, at 4:28 am, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > -------- > Julian Reschke writes: > >>> Personally I think the most sensible thing to do is to make it the job of the messaging layer (or lower) to negotiate it, and simply noting that expectation, *should* it ever happen, works for me. >>> >>> Issuing a standard without even having thought about revisions would be standardization malpractice IMO. >> >> Do you have a concrete proposal what to do? > > As I just wrote: > > Personally I think the most sensible thing to do is to make it the > job of the messaging layer (or lower) to negotiate it (which semantic > version), and simply noting that expectation, *should* it ever > happen, works for me. > > Part of the reason why I think so, is that our experience so far > indicates that traffic-steering is used to send "new traffic" to > a dedicated set of "test-servers", so the earlier the choice can > be made, ideally at the TLS layer, the better. > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 2 February 2021 23:38:21 UTC