Hi, Lachlan, Thanks for address my comments and this further investigation. This looks much more precise.
Regards, -------------- Sheng Jiang >Hi Sheng, > >Thank you for raising this issue - Kai Gao and I looked further into this >and have discovered that the cases are actually different for a "https" >connection and a "http" connection. There is a negotiation procedure >defined for "https" in RFC 7301. However, there does not seem to be one >established for "http." As such, I believe Kai is thinking of writing a >short, separate draft to address this, but regardless, it falls outside the >scope of this new-transport document which concerns only what happens after >a connection is made. See the new proposal below. > >OLD >The HTTP version a connection uses is negotiated between client and server >based on the respective HTTP RFC documents. > >NEW >The HTTP version a "https" connection uses is negotiated between client and >server using the TLS ALPN extension, described in Section 3.1 of [RFC9113] >for HTTP/2 and Section 3.1 of [RFC9114] for HTTP/3. For a "http" >connection, the explicit announcement of HTTP/2 or HTTP/3 support by the >server is outside the scope of this document. > >Best, >Lachlan > >On Sun, Apr 9, 2023 at 4:39 AM Sheng Jiang <[email protected]> wrote: > >> 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 < >> [email protected]> >> >> >> >> >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. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
