Hi authors, Below my comments, thanks. (Writing as a separate thread from Qin's comments to avoid collisions.)
Comments related to the abstractions: ----------------------------------------------------- It seems to me that the doc introduces the following abstractions: * Information resource directory (IRD) * Transport state (ts) * Updates queue (uq) * Server push (sp) * Content of an update item Because these are first class citizens in the doc, I would suggest adding a section up-front early in the doc (e.g., "New Abstractions" or similar) introducing these objects with a 1 paragraph description for each. This will help the reader quickly understand the information flow as he/she reads through the rest of the doc. (I had to read the doc twice to figure out these are the key objects.) Comments related to protocol semantics: ------------------------------------------------------------- * Figure 1 talks about Information Resource #1, #2, etc. But throughout the whole text we call these Information Resource Directory or IRDs. Are they the same? If they are, should we update Figure 1 to use IRD instead of "Information Resource". If they are not the same, could the document formally define what they are and how they differ? * This is related to Qin's question in the other thread. If a client creates a transport state, can another client read from it too? If allowed, could this create incremental update sync issues if multiple clients are allowed to read from the same updates queue? If not allowed, how does the server implement isolation between clients? * While 'Transport state' is a first-class citizen in TIPS, the first instance of this name is weakly introduced in the following paragraph (Section 2.1) and inside brackets: "A key design of the ALTO TIPS is to distinguish between network information resource and the transport information (referred to as transport state)". Given its importance, I suggest properly defining it (this is related to my previous comment on abstractions): * "The complete framework of TIPS defines 3 types of services". Looks like this should be "4" instead of "3". * "This document defines the first two." Looks like this should be "the first three", instead of "the first two". * The specification defines a "support-server-push" but it does not define a "support-client-pull". Does that mean that support for client-pull is mandatory so there is no need for the server to flag whether it supports it or not? * About this sentence: "The resource-id of an ALTO resource and MUST be in the TIPS' "uses" list". How does the client get the TIPS "uses" list? Perhaps adding an HTTP request/response example (if any) would help. * About this MUST requirement: "Note that the client MUST support all incremental methods from the set announced in the server's capabilities for this resource. If a client does not support all incremental methods from the set announced in the server's capabilities, the client MUST NOT use the TIPS service". Could the client optionally include in the HTTP request the list of incremental methods that it supports in the case that it does not support all of them? * This sentence is a bit confusing (missing predicate): "Let absolute-transport-state-uri as the absolute URI after resolution" * I see there are some "TBD" words (e.g., in Section 4.5, 5.6, etc.) * "Assume the client wants to get the contents of updates 101". I think this should be "of updates item 101". * "We leave the specification to a companion document". Is there an I-Draft reference that could be added here? * "see below on client timeout on waiting for updates of dependent resources". I could not find anywhere below any description about client timeouts, could you clarify this sentence? * "see Section 6.7.1". I could not find section 6.7.1. * I think where it says "update queue" should be "updates queue" * I think where it says "update element" should be "update item"? Comments about grammar and nits -------------------------------------------------- Quick search and replace suggestions: s/and ideally/and, ideally/ s/Hence there can/Hence, there can/ s/Next consider/Next, consider/ s/Work Flow/Workflow/ s/Work flow/Workflow/ s/work flow/workflow/ s/An TIPS/A TIPS/ s/the server then need to send/the server then needs to send/ s/with field:/with the following fields:/ s/If request has any errors/If the request has any errors/ s/UpdateQueueMeta/UpdatesQueueMeta/ Thanks, Jordi (Speaking as individual)
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
