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

Martin Thomson <mt@lowentropy.net> Mon, 11 July 2022 05:28 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F472C157B5F for <alto@ietfa.amsl.com>; Sun, 10 Jul 2022 22:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.127
X-Spam-Level:
X-Spam-Status: No, score=-7.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=a6F3/0zS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=2HHa5Ddk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyRrfMu5H8eL for <alto@ietfa.amsl.com>; Sun, 10 Jul 2022 22:28:23 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB724C14F743 for <alto@ietf.org>; Sun, 10 Jul 2022 22:28:23 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DADBE5C00E9 for <alto@ietf.org>; Mon, 11 Jul 2022 01:28:21 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Mon, 11 Jul 2022 01:28:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1657517301; x=1657603701; bh=Wd4h/GyEXf 6sbwbRelrJ3Cn1l8QzzZ3x+TEMbD0229E=; b=a6F3/0zSeMIU9uFxLqCh5etPe2 jLQLvQhLX1zkrnFQDIGYENG+xINN9/ToAI65xB1zbdoC4gHXLhE0Zc5q9l4B2EYq Hh5v5fH5vwxtLBWf31TlH/OtJV6fVluyBwN+3OLuTCA9mBkqjjEuAP6wTb0y3/7A f4lYkREtQoXTfCnHaxs1LohhKqJjomlrAZNNJ5lkYsYIoUp4Turj6Hd0UUN+W5hj 1IGdVUSSLBYiYUnDBNAKft1R944VqazFJeIWkKwWA5YIs5x5PMw581fgjP2tsJUn KFmIMqLiAN/CVKbKwuLzA4WWQFOYSr1SlU2g8qAapDe6PpAdH+enGNAeIk1w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1657517301; x=1657603701; bh=Wd4h/GyEXf6sbwbRelrJ3Cn1l8Qz zZ3x+TEMbD0229E=; b=2HHa5DdkdHe3XQOrQP+xIsLTJXy7nMz8BMRqPbM/71Q+ MsYtz1LpEQeGWxhDQmr696Km+0F8YOr0TIlQdkPJDrhDha248X5Z2LxvQL3Snidg 9XgZs1LYsQfT30Wb1/ceiGnyk9Ua7Vtwx4AiLj1pjSm8UJzYa3+AYsiuJogKw+R7 E1RL9O1AknclnOW1+qHpk7E5dmdoq8NG4GnowxU2qo5MP0f/+0tiaGiCFr8O13Sr cLCr9faqiYK2yasriU0mTUn4IqNLndhnGqlfyIs4mTBzurfCZwzHFGS5pPsbK1lQ Us8N35j1gBJIZzEn5TlWhcR/eMdzrSJ5/x8XbGGjeA==
X-ME-Sender: <xms:9bTLYpWJmkLjaRPYkYdhPBw3-TfPd-lB8tMSCUIZC801MDf2m6wq4g> <xme:9bTLYpmOuob9lWF6iqpO-f5In6W7Y2c7ggEc0fVj097I_hGqFDp52P4Mtyj2o-FRP 5_Zs7T7jEh3H6VliJQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejvddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeeggeelfeetleejteejff eiuefgffelgfehjeffjeetvdffjeelhfetkeevffelteenucffohhmrghinhephhhtthhp fegshiguohhinhhgvgigrggtthhlhihnohhthhhinhhgihhnshhpvggtihhfihgtrghtih honhhsrdihohhupdhivghtfhdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphi drnhgvth
X-ME-Proxy: <xmx:9bTLYlaF-BOEFP5tXzDUgVM02H28Hn4Dsg6VjvivZuPaCl4WFveD5w> <xmx:9bTLYsV1x4z7z2tlh67eRXpz0jDLIT2H7kBsd80We8lIb65swrXiaQ> <xmx:9bTLYjnnm8iHADIHNETJSJqjQoY0rlKygb2n1uyGuCrdGQe2aOTDIQ> <xmx:9bTLYvyxOIsS_biMZu-Uud4q0gGWeoPmnmyfIEmcnTpVzUxY08d35Q>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7897D2340077; Mon, 11 Jul 2022 01:28:21 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-720-gbf5afa95ff-fm-20220708.001-gbf5afa95
Mime-Version: 1.0
Message-Id: <5cf0f987-4bdb-4dbc-9938-098b2653339c@beta.fastmail.com>
In-Reply-To: <8888D7E2-2482-44B4-8972-5C0E75D8C8B9@mnot.net>
References: <9979_1657033016_62C45138_9979_197_42_f6e3825994624da7bcbe2ef353e5f718@orange.com> <8888D7E2-2482-44B4-8972-5C0E75D8C8B9@mnot.net>
Date: Mon, 11 Jul 2022 15:28:02 +1000
From: Martin Thomson <mt@lowentropy.net>
To: alto@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/sa1Pv7jmTfBF3TbGuJr_PffIjXg>
Subject: Re: [alto] Fwd: HTTP Review (draft-ietf-alto-new-transport)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2022 05:28:28 -0000

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.

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.

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.

It looks like Section 8 is over-specifying, with details of stream dependencies and so forth.

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.



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/