On Wed, Nov 29, 2023 at 12:41 PM <[email protected]> wrote: > 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. >
LGTM. > > > >> >> >>> - 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. > Better now. > >> >>> - 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). > I think we need to hint on "who" is going to convert them using that function. //Zahed > > > //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
