Hi, authors of draft-ietf-alto-new-transport:
Based on our earlier discussion, this draft will be break down into four
components: (1) version independent structures; (2) client (long)
poll; (3) server push to client, and (4) server (as http client) put to client
(as http server).
See the latest version of draft-ietf-alto-new-transport, my impression the base
model draft
(i.e.,https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/)
is still mixed version independent part with version specific part. I recommend
to take out version specific part (i.e., server push) and move it to another
I-D, therefore all
other components including server push, client long poll, and server put can
reference based component which focus on version independent part. Then we will
have a more clean base document.
Take the chair hat off, here are a few quick review comments on this draft:
1. Abstract
separate HTTP/2 specific server push part from abstract
2. Introduction said:
"
Figure 1 shows the
architecture and message flow of ALTO/SSE, which can be considered as
a more general transport protocol than the ALTO base transport
protocol.
"
I am not sure SSE architecture and message flow is a more general transport
protocol than the ALTO based transport protocol.
I see one provides pub sub support, the other provides polling support, which
are complementary to each other.
3. Section 2 ALTO New Transport Design Requirement said:
"
If a design is
based on a particular HTTP version, it should respect its semantics:
* R6: The design respects specific HTTP semantics such as the
semantics of PUSH_PROMISE, if the feature is used.
"
I think R6 can be separated out and references this base document and explore
version specific extension in
https://datatracker.ietf.org/doc/draft-schott-alto-new-transport-push/
4. Section 3 said:
"
* The transport state from the ALTO server to an ALTO client (or a
set of clients) for an ALTO information resource is conceptually
through a transport queue. A static ALTO information resource
(e.g., Cost Map, Network Map) has a single transport queue, and a
dynamic ALTO information resource (e.g., Filtered Cost Map) may
create a queue for each unique filter request.
"
In this bullet, you more focus on clarifying what ALTO information resource
really is. Can you be more specific
on what the transport state looks like? This comment is also applied to other
neighboring bullets, e.g.,
receiver set state, transport queue state, server state, provide some example
will be helpful, e.g.,
s/receiver set state/receiver set state (e.g.,xxxx)
5. Change the abbreviated title in the header and footer of each page into
ALTO/HTTP
6. Section 6, should client pull be separated out as a separate document?
-Qin
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
