Re: [alto] Opsdir early review of draft-ietf-alto-new-transport-07

[Sheng Jiang <[e-mail]>]

Hi，Lachlan,

Thanks for your reply and address my comments. The sentence "The HTTP version a connection uses is negotiated between client and server based on the respective HTTP RFC documents." assuming that "HTTP RFC documents" are some references in which the negotiation procedures have been defined.

Regards,


--------------



Sheng Jiang



>Hi Sheng,



>



>Thank you so much for taking the time to review the document.



>



>In regards to your comment, thank you for pointing out the ambiguity. For



>some background clarification:



>



>Based on other review comments, Kai has since added a requirements section



>about TIPS that mentions HTTP/1.x support is desired for "backwards



>compatibility ... as many development tools and current ALTO



>implementations are based on HTTP/1.x." Additionally, early versions of



>this draft did constrain the HTTP version to HTTP/2 and HTTP/3 but after



>the discussion with Mark Nottingham (after the HTTP early review) and the



>chairs, we realize that the core of the design does not rely on HTTP/2 or



>HTTP/3. Thus, the decision was to make the core mechanism independent of



>HTTP versions but enable enhanced features when HTTP/2 or HTTP/3 is used.



>



>To specifically address your issue: the main loop of the TIPS protocol is



>that a client receives successive incremental updates of a monitored



>resource when the resource changes. This can be done with either Client



>Pull defined in Section 6 or Server Push defined in Section 7. Client Pull



>is predominately 1 outstanding request at a time to fetch the most recent



>update which works regardless of the HTTP version. Server Push only works



>over an HTTP/2 or /3 connection as HTTP/1.x doesn't support server push.



>



>Failures that cause a fallback to HTTP/1.x may include the ALTO server not



>supporting, say, HTTP/2 or HTTP/3. In which case, the negotiation of the



>HTTP protocol version is defined in the respective HTTP RFC documents and



>falls outside of the TIPS protocol, which focuses on what goes on after a



>persistent connection has been established.



>



>Here is the proposed modification to section 2.5 of the document to clarify



>this:



>OLD



><name>TIPS with HTTP/1.x<name>



>



><t>While TIPS is designed to take advantage of newer HTTP features, TIPS



>still functions with HTTP/1.x for client pull functionality only, with the



>limitation that it cannot cancel any outstanding requests or fetch



>resources concurrently over the same connection.<t>



>



>NEW



><name>TIPS with Different HTTP Versions<name>



>



><t>The HTTP version a connection uses is negotiated between client and



>server based on the respective HTTP RFC documents.</t>



>



> <t>While TIPS is designed to take advantage of newer HTTP features like



>server push and substreams for concurrent fetch, TIPS still functions with



>HTTP/1.x for client pull defined in Section 6, with the limitation that it



>cannot cancel any outstanding requests or fetch resources concurrently over



>the same connection due to the blocking nature of HTTP/1.x requests.



>Additionally, because HTTP/1.x does not support server push, the use of



>TIPS with server push defined in Section 7 is not available if a client



>connects to an ALTO server with HTTP/1.x. If a client only capable of



>HTTP/1.x desires to monitor multiple resources at the same time, it must



>open multiple connections, one for each resource. For HTTP/2 and /3,



>because of substreams, multiple resources can be monitored



>simultaneously.</t>



>



>On Tue, Apr 4, 2023 at 3:58 AM Sheng Jiang via Datatracker <[e-mail]>



>wrote:



>



>> Reviewer: Sheng Jiang



>> Review result: Has Nits



>>



>> Reviewer: Sheng Jiang



>> Review result: Ready with Nits



>>



>> I have reviewed this document as part of the OPS directorate's ongoing



>> effort to review all IETF documents being processed by the IESG. Comments



>> that



>> are not addressed in last call may be included in AD reviews during the



>> IESG



>> review. Document editors and WG chairs should treat these comments just



>> like



>> any other last call comments.



>>



>> Document: draft-ietf-alto-new-transport-07



>> Reviewer: Sheng Jiang



>> Review Date: 2023-04-04



>> Result: Ready with Nits



>>



>> This document intents for Standards Track. It  document specifies a new



>> ALTO Transport Information Publication Service (TIPS), which takes



>> advantage



>> of HTTP/2 and later versions already support concurrent, non-blocking



>> transport of multiple streams in the same HTTP connection. This document



>> is well-written and READY with minor Nits (below) for publication.



>>



>> In section 2.5 "TIPS With HTTP/1.x". This document claims "TIPS



>>    still functions with HTTP/1.x for client pull functionality only,



>>    with the limitation that it cannot cancel any outstanding requests or



>>    fetch resources concurrently over the same connection." However, it is



>> unclear what operations/procedure defined in this document will fail when



>> TIPS work over HTTP/1.x (also whether there are scenarios the server/client



>> have to fall back to HTTP/1.x), the signal or error code the TIPS will



>> provide, and how the server and client should act when these failures



>> happen.



>>



>> This looks like an operational hole that authors must fill before



>> publication.



>> However, I am not sure, if there is no scenarios that the server/client



>> have



>> to fall back to HTTP/1.x, the authors may simply declare the TIPS SHOULD



>> not



>> work with HTTP/1.x.



>>



>>



>>



>>



>>



>>