Subject: Versioning -semantics ?

From: Poul-Henning Kamp <[email-masked]>
Date: Tue, 02 Feb 2021 13:09:00 +0000

Have we thought about how future incompatible changes to -semantics will be versioned? 

The obvious "send a header saying 'using new -semantics' will not work, if the request semantics are incompatible.

Are we assuming the -messaging layer will figure this out ?

Or have we (implicitly) decided that it will never happen in the first place ?

Should we mention any of this in the document ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 2 Feb 2021 14:57:28 +0100

Am 02.02.2021 um 14:09 schrieb Poul-Henning Kamp:
> ...

Have we *ever* done a change to the "semantics" part of HTTP in the past?

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 02 Feb 2021 14:31:38 +0000

--------
> Have we *ever* done a change to the "semantics" part of HTTP in the past?

"PUSH" did ?

It went 180 degrees counter to the "request-response" model we had
and which we still espouse in the -semantic draft.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 2 Feb 2021 15:40:09 +0100

> and which we still espouse in the -semantic draft.

I would call that an extension of HTTP semantics, not an incompatible
change.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 02 Feb 2021 16:34:10 +0000

--------
Julian Reschke writes:
> >>> Have we thought about how future incompatible changes to -semantics wi=
> ll be versioned?
> >>> ...
> >>
> >> Have we *ever* done a change to the "semantics" part of HTTP in the pas=
> t?
> >
> > "PUSH" did ?
> >
> I would call that an extension of HTTP semantics, not an incompatible change.

Call it what you will, it disproves that the semantic layer has been forever cast in stone[1].

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.

Poul-Henning

[1] And if it had been, we wouldn't need to produce 200 pages about it now :-)

---

From: Julian Reschke <[email-masked]>
Date: Tue, 2 Feb 2021 17:58:29 +0100

> Issuing a standard without even having thought about revisions would be standardization malpractice IMO.

Do you have a concrete proposal what to do?

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 02 Feb 2021 17:28:38 +0000

--------

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Feb 2021 10:38:00 +1100

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 <[email-masked]> wrote:
> 
> --------
> Julian Reschke writes:
> 

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 03 Feb 2021 06:19:12 +0000

--------

> it's a different protocol.

Then we should simply say that in the -semantics document.