I reviewed the document previously, so this is an incremental review.

Two major issues remain in the document.  I don't believe that it would be responsible to publish this document without correcting these issues.

1. The first relates to assumptions of connection-bound state and a fix would require some small, but fundamental, changes to the protocol.

2. The second relates to the appendix on use of HTTP server push and might be fixed either by dropping the capability along with some minor editorial changes, or by reworking the design of the appendix.


A lot of the explanation of the data model and the expected interaction models are clearer in this version.  The polling design seems reasonable, modulo the first issue I note below.  That said, I am not expert enough in this area to say whether there is a need to create per-client state on servers to support this interaction mode.

Issue 1: Connection affinity

Section 4.2 of the document is a defense of the decision in the protocol that binds state to a connection.  HTTP does not recognize connections as having any state.  The last paragraph of Section 4.11 of RFC 9205 explains this very clearly:

> Applications MUST NOT make assumptions about the relationship between separate requests on a single transport connection; doing so breaks many of the assumptions of HTTP as a stateless protocol and will cause problems in interoperability, security, operability, and evolution.

There are several recognized ways of working around the sorts of issues that this document is trying to deal with.  One might be to build a stateful protocol that is not HTTP (as in Section 2.1 of RFC 9205).

If the goal is to use HTTP, then you might be able to provide clients with URLs that only reference the server instances that they are currently interacting with.  For instance, when the client opens a new TIPS view, the server could provide an absolute URL to a resource that is hosted exclusively on that instance (for instance, instance12345.alto.example as opposed to alto.example).  Clients would still be able to use the URL template style of queries relative to that view, but the state would not be assumed to exist across the entire service.

This approach has some drawbacks, in that it can expose instances to more powerful denial of service attacks, but it might provide the sort of properties that Section 4.2 claims to be seeking.

Issue 2: Server push design

The use of HTTP server push described in Appendix C is not consistent with HTTP/2 or HTTP/3 and will not work.

I've attempted to explain several times why this design is unworkable.  I won't try again here.

Cheers,
Martin