Hi Mark, Thank you so much for the feedback. Could you please see https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE/ for an attempt to formulate a generic problem.
As soon as we have a discussion on the generic issue, we will update the document accordingly, for example, to decide to use HTTP/1.x textual representation---we used HTTP/1.1 textual and then found that the example need to illustrate details such as the promised stream (see Promised Stream 4 as an example). We will update as soon as we have a discussion on the generic thread. Thanks again! Richard On Sun, Jul 17, 2022 at 4:05 AM Mark Nottingham <[email protected]> wrote: > I've taken a look at this document. > > My high-level feedback is that in principle it's reasonable use of HTTP, > but how it talks about HTTP versioning and a few other details isn't > appropriate. I think that a few small editorial updates could improve > things, and would be happy to make a pull request if you happen to be using > a Github-based process. > > What raises concerns for me is referring to this as 'ALTO/h2' and similar > things. If you're designing an application that uses HTTP, you need to > acknowledge that you can't always control the end-to-end version of the > protocol used, and while you can optimise for newer versions of the > protocol, you have to be prepared for downgrading to previous ones. > > That means that this isn't really "ALTO/h2", it's a new version of ALTO > that operates more smoothly under later versions of the protocol. > > DoH threaded this particular needle as well; rather than branding it as > "DNS/h2", they merely said " HTTP/2 [RFC7540] is the minimum RECOMMENDED > version of HTTP for use with DoH." and then: "Earlier versions of HTTP are > capable of conveying the semantic requirements of DoH but may result in > very poor performance." > > In this spirit, I'd recommend avoiding using the HTTP/2 textual > representation for examples; most developers are much more familiar with > HTTP/1.1 when consuming examples, and HTTP/2 contains details which aren't > relevant for the purpose of conveying an example (we've settled on this > approach in the HTTP editorial style, see < > https://httpwg.org/admin/editors/style-guide>). > > Note that I haven't done a full review; these are just the things I saw > after a quick look. > > Cheers, > > > > > On 11 Jul 2022, at 1:37 pm, Mark Nottingham <[email protected]> wrote: > > > > Hi folks, > > > > I've been asked to forward this request for early review; does anyone > want to take a look? > > > > Feedback to [email protected]. > > > > Cheers, > > > > > >> Begin forwarded message: > >> > >> From: <[email protected]> > >> Subject: HTTP Review (draft-ietf-alto-new-transport) > >> Date: 6 July 2022 at 12:56:56 am AEST > >> To: Mark Nottingham <[email protected]> > >> Cc: Qin Wu <[email protected]>, " > [email protected]" < > [email protected]> > >> > >> The ALTO WG is currently working on the specification available at: > https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/. The > current version focuses on H2 with the intent to cover at least common > H2/H3 functionalities. > >> > >> The WG is seeking for early reviews so that issues/advice are taken > into account early in the process. > >> > >> We are particularly interested in comments about the handling of H3, > especially with regards to the guidelines in RFC9250 about HTTP versioning. > >> > >> Of course, comments related to other considerations in the draft are > more than welcome. > >> > >> Thank you. > > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
