The new text looks good. Thanks // Zahed
On Thu, 30 Nov 2023 at 02:03, <[email protected]> wrote: > Hi Zahed, > > Please see inline for the new text. If it works, I will submit a new > revision with the proposed changes. Thanks for the helpful review! > > Best, > > Kai > > > -----Original Messages----- > *From:* "Zaheduzzaman Sarker" <[email protected]> > *Send time:* Wednesday, 11/29/2023 20:01:10 > *To:* [email protected] > *Cc:* "Kai GAO" <[email protected]>, "The IESG" <[email protected]>, > [email protected], [email protected], > [email protected] > *Subject:* Re: Re: [alto] Zaheduzzaman Sarker's Discuss on > draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT) > > > > > > 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. > > [KAI] Makes sense. How about the following text? > > NEW: > > The field [tips-view-uri] MUST contain only ASCII characters. In case the > original URL contains international characters (e.g., in the domain name), > the ALTO server implementation MUST properly encode the URL into the ASCII > format (e.g., using the "urlencode" 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
