Hi Zahed, Thanks for the comments! Please see the responses inline. I already have the updates in place but would like to submit a new revision after you review the proposed texts.
Best, Kai -----Original Messages----- From:"Zaheduzzaman Sarker" <[email protected]> Send time:Tuesday, 11/28/2023 20:02:44 To: "Kai GAO" <[email protected]> Cc: "The IESG" <[email protected]>, [email protected], [email protected], [email protected], "Kai Gao" <[email protected]> Subject: Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT) Hello, Thanks for addressing the comments. The -19 version looks improved. Some more reflections below. //Zahed On Tue, Nov 21, 2023 at 4:09 PM Kai GAO <[email protected]> wrote: Hi Zaheduzzaman, We are sorry for the late reply -- the mail was blocked by the spam detector. Please see our responses inline. Best, Kai On Thu, Oct 26, 2023 at 6:56 PM Zaheduzzaman Sarker via Datatracker <[email protected]> wrote: Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-alto-new-transport-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for working on this specification. I have following points which I want to discuss further - - I understand this new transport is supposed to take advantages of HTTP/2 and HTTP/3 features and have backward compatibility with HTTP/1.x (x=1, likely). My take is, if I want to server ALTO server over HTTP2/ or HTTP/3 I would use this new transport. Now if I also want to also support HTTP1.x for whatever reasons then I have issue, should this new transport is sufficient to support all the HTTP versions up to HTTP/3? if yes, then why this does specification not update or even obsolete rfc8895? if the answer is NO, does that mean I need to implement both this specification and rfc8895 for HTTP1.1? This relation is not explicitly defined in this current draft, which it should. [KAI] Thanks for the comment. Yes, the new transport is sufficient to support all HTTP versions up to HTTP/3. The relationship between new transport and RFC8895 is also raised by the IoT telechat review by Wesley Eddy. Our understanding is that new transport is not a replacement of ALTO/SSE, and these two extensions can be combined (see the introduction of -18 for more complete discussions). This looks better in -19 version. Thanks - I am not convinced that incremental update actually reduces storage at ALTO server, how is that so? I don't think there is an strict requirement that all the ALTO clients need to be updated to the recent version to be functional (as described in this specification), that means unless the serve is sure that all the clients are updated to certain version it has to keep the update versions. As storage reduction is a motivation for the transport requirement this motivation need to be well described to derive the requirement. [KAI] The "reduced storage" is compared to the case where the server stores the contents of each version. It is a motivation to use incremental updates (which applies to RFC 8895 as well) and we consider incremental updates as one motivation for the new transport. Does this make sense? The draft still just mentions this as a statement. I think it would be better if it is clear that the comparison is done with the case where the server stores the contents of the each version. [KAI] Got it. The proposed text is: NEW: Incremental updates only maintain and transfer the "diff" upon changes. Thus, it is more efficient than storing and transferring the full updates, especially when the change of an ALTO resource is minor. - I didn't find any explanation of how the "Concurrent, non-blocking update transmission" requirement is meet by the new transport. is this solved by the use of HTTP/3 with uses QUIC and does not have HOL blocking within a connection? Or is this addressed by multiple concurrent HTTP connection to the ALTO server? This need to be understood better and we should define what actually "Concurrent, non-blocking update transmission" means in this context of fetching updates. [KAI] The requirement basically requires that incremental updates can be transmitted at the same time (concurrent) and the transmission of one update will not be blocked by the transmission of another update. This can be realized by 1) multiple HTTP connections, or 2) HTTP/3 using multiple streams. This is compared with RFC 8895 where SSE multiplexes the updates in a single sequence. You make a good point that we should clarify how this can be done with new transport. We will add a paragraph to Sec 2.1 and upload a revision soon. - The encoding or data type of "updates graph (ug)" and "version" is not defined. The example uses numeric numbers which is easy to understand with incremental values. However, unless and otherwise this data type is defined then it is up to the implementers to select that and which will lead to interoperability issues. or may be I am missing something here, that is why I need to discuss the intention here. [KAI] The data type of the version tag (the one held by the client) is a string (JSONString) but the "version" used to compute the URLs is a sequence number (JSONNumber), both specified in Sec 6.2. do you mean "UpdatesGraphSummary" ? can we put the inline ref to the section where version datatype is defined to avoid confusion? [KAI] The proposed texts are added to the "Updates graph" and "Version" entries in Sec 2.2. NEW: ... Encoding of a updates graph is specified in Section 6.1. NEW: ... Version is encoded as a JSONNumber, as specified in Section 6.1. - Here we are composing URIs from the ug , that tells me without proper encoding on ug defined there might be some internationalization issues (see rfc6365). Has there been any thoughts or discussions on this encoding and potential issues? [KAI] Good point. According to RFC 7285 (the base ALTO protocol), the contents of the ALTO maps only allow ASCII characters. I think this document should have the same restrictions. have you mentioned this in -19 version? if not then please write the restriction. [KAI] I checked the charset for JSON (e.g. RFC 4627). Seems that the encoding is unicode (and UTF-8 by default). In that case, there is only one potential risk that a tips-view-uri may contain international characters, as other parts of the constructed URLs are all ASCII. In Sec 6.2, we require tips-view-uri to follow RFC 3986 which only uses ASCII characters for the URL. Our proposal is to add a text in Sec 6.2: NEW: The field [tips-view-uri] MUST contain only ASCII characters. If the original URL contains international characters (e.g., in the domain name), they MUST be properly encoded into the ASCII format (e.g., using the "urlencode" function). //Zahed and I am also supporting Roman's discuss. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think my other AD colleagues have already identified nits and typos. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
