Re: [alto] Fwd: HTTP Review (draft-ietf-alto-new-transport)

Hi Martin,

Sorry that I did not include you in the previous email--auto completion of
email address included a different Martin :-( My apologies.  Please kindly
see this message:
https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE/

Please see below for more comments.

On Mon, Jul 11, 2022 at 1:28 AM Martin Thomson <mt@lowentropy.net> wrote:

> ALTO is very much a protocol that is defined in terms of core HTTP
> semantics (see RFC 9205, Section 4.1).  It refers to RFC 7230 (the
> then-current version) rather than RFC 7231 as perhaps it should have, but I
> couldn't see any place where the use of HTTP semantics were
> version-specific.
>
> That makes this document a little surprising.  Most protocols that use
> HTTP benefit from HTTP/2 and HTTP/3 by doing exactly nothing in
> specifications.  You just update software.  This document is a fair bit
> more than nothing.
>
>
Please see the generic discussion in the previous email (
https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE/) on
why the current version specified the additional details.

To summarize shortly, the problem is that
(1) a server needs to push a set of resources Ui to a client, there can be
dependencies among the Ui, and how to map each Ui to which stream (in
HTTP/2 or HTTP/3);
(2) each Ui already has a media type, and if multiple Ui are mapped to the
same stream, how to indicate so in the push header and what is the
container media type.

The decision in the current document is:
- Map each Ui to an independent stream (so that no container issue for (2)
-  Instruct the server to respect the dependency to optimize the
transmissions (e.g., by transmitting Ui before Uj, if Uj depends on Ui).

> The new concept of transport queues is added, but I couldn't work out what
> they do.  Maybe there is something related to server push.  I found this
> part to be poorly rationalized and the explanation concentrates on
> mechanisms to the detriment of explaining what the functions provided are
> intended to do.  I can guess based on RFC 8895 what they might do, but I
> think that this document should probably do some more explaining about that.
>
>
Good suggestion. We can add some text to explain, and here is the
high-level reasoning motivating the transport queue concept:
- Pull: Allow a client to see the possible request points;
- Push: When a client indicates an interest to receive the incremental
updates for a resource, the server can start to push incremental updates to
the client; the transport queue is a resource to tell a client the push
status and also reflect the push URI.

> Even with some guessing, I couldn't easily see how the non-push version is
> supposed to work.  How does the client know which URI to GET?  It looks
> like there is some magical URI construction going on based on examples, but
> that isn't written down.
>
>
We should update the whole workflow: The starting point is the Information
Resource Directory (IRD), which provides the entry point. We put the IRD
example in the later part and we can refer to it before the examples. How
does this sound?

> It looks like Section 8 is over-specifying, with details of stream
> dependencies and so forth.
>
>
Please see the generic email. We will try to simplify when we update. I see
two approaches to simplifying the spec: (1) let the application layer
handle it (each Ui as an independent message in the transport layer); and
(2) only specify the dependency of the resources but do not go to stream
dependency.

> I *think* there is a new resource type here, but that isn't registered in
> the IANA section.

That shouldn't be called "-h2"; a better name would describe what the
> resources are for.  There is also a new media type apparently, but I
> couldn't see where that is defined.
>
> Good catch. We have not included it yet as we are finalizing the semantics
and not the grammar yet, but it is a good point and the new version will
include the spec.

Thank you so much!

Richard

>
>
> On Mon, Jul 11, 2022, at 13:37, Mark Nottingham wrote:
> > Hi folks,
> >
> > I've been asked to forward this request for early review; does anyone
> > want to take a look?
> >
> > Feedback to alto@ietf.org.
> >
> > Cheers,
> >
> >
> >> Begin forwarded message:
> >>
> >> *From: *<mohamed.boucadair@orange.com>
> >> *Subject: **HTTP Review (draft-ietf-alto-new-transport)*
> >> *Date: *6 July 2022 at 12:56:56 am AEST
> >> *To: *Mark Nottingham <mnot@mnot.net>
> >> *Cc: *Qin Wu <bill.wu@huawei.com>, "
> draft-ietf-alto-new-transport@ietf.org" <
> draft-ietf-alto-new-transport@ietf.org>
> >>
> >> 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
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>