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
