Technical Summary
The ALTO Protocol (RFC 7285) leverages HTTP/1.1 and is designed for
the simple, sequential request-reply use case, in which an ALTO
client requests a sequence of information resources, and the server
responds with the complete content of each resource one at a time.
ALTO incremental updates using Server-Sent Events (SSE) (RFC 8895)
defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO
server can incrementally push resource updates to clients whenever
monitored network information resources change, allowing the clients
to monitor multiple resources at the same time. However, HTTP/2 and
later versions already support concurrent, non-blocking transport of
multiple streams in the same HTTP connection.
To take advantage of newer HTTP features, this document introduces
the ALTO Transport Information Publication Service (TIPS). TIPS uses
an incremental RESTful design to give an ALTO client the new
capability to explicitly, concurrently (non-blocking) request (pull)
specific incremental updates using native HTTP/2 or HTTP/3, while
still functioning for HTTP/1.1.
Working Group Summary
No controversy was raised during the development of this specification from the
WG participants. There were some discussions about various design options to
meet the new transport requirements, naturally. These options were presented
and discussed in many WG meetings. No objections from the WG were raised
against the actual design (especially during the two WGLCs organized for this
document).
Some concerns were raised by some directorate reviewers, e.g., server Push
usage, 1:1 relationship between clients and connections, etc. The document
includes NEW text to motivate these design choices when appropriate. The
specification was also updated to reflect the comments from the reviewers
(e.g., ordering requirement, explicit the transport requirements, avoid the
impression of design-by-example by indicating the expected behavior (e.g.,
increment by 1), etc.
The author also included a new section to describe to what extent this work
adheres to "Building Protocols with HTTP" BCP. The authors also updated the
language to align with the recommendation in RFC9205#Section 3.1.
During the IETF LC, the server Push usage and 1:1 relationship between clients
and connections were re-challenged, especially given the considerations in the
last paragraph of Section 4.11 of RFC 9205. As an outcome, the design was
updated by removing the 1:1 connection affinity and the appendix related to
Server Push. The text was also updated to highlight the URLs that point to
specific server instances.
Document Quality
There is one known implementation.
Personnel
The Document Shepherd for this document is Mohamed Boucadair. The
Responsible Area Director is Martin Duke.