W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: draft-kinnear-httpbis-http2-transport questions

From: Andy Green <andy@warmcat.com>
Date: Fri, 22 Mar 2019 14:28:49 +0800
To: Kari Hurtta <kari.hurtta@welho.com>, HTTP Working Group <ietf-http-wg@w3.org>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Message-ID: <66e275ad-7510-1660-e90c-31b45bfedfc2@warmcat.com>


On 22/03/2019 13:52, Kari Hurtta wrote:
>> Putting datagram thing to one side, perhaps I missed it but it seems it
>> doesn't buy anything compared to RFC8441:
>>
>> https://datatracker.ietf.org/doc/rfc8441/?include_text=1
>>
>> That already has the same idea of CONNECT-ing the stream to be
>> different, non-http transport over stream DATA frames.  Although RFC8441
>> is focused on transporting websockets, it defines an upgrade name
>> registry so you can upgrade to something else (Section 9.2).

> Well, draft-kinnear-httpbis-http2-transport-01 seems do just that
> ( giving new upgrade token, as you suggest )

You're right, I scanned the introduction that was starting from CONNECT 
first principles and missed it mentions RFC8441 halfway through.

Still...

>> 5.  IANA Considerations
>>
>>    This specification registers two entries in the "HTTP Upgrade Tokens"
>>    registry that was established by [RFC7230].
> 
> What I missed ?

What it creates is a single registered upgrade type "bytestream" that is 
anonymous and has no description of what protocol or versioning or 
subframing is inside it.

 From ws perspective, it's the same as a ws protocol that doesn't 
provide subprotocol names... the vhost can only offer one of those and 
if you made that mistake, this doesn't have the escape hatch of 
subprotocol negotation that ws has.  If different vendors feel that 
different things should go in the anonymous transport, more than one 
vendor's products couldn't talk to the same vhost.

It could maybe get around it by registering something tied to a specific 
format, like "ethernet-encapsulation".  But if it wants to just be 
"bytestream" it should maybe think about ws-style subprotocol (which can 
include versioning in the name).

Compared to RFC8441's UPGRADE type, there is some low-hanging fruit 
because that deliberately encapsulated RFC6455 framing wholesale inside 
h2 DATA frames (including masking).  There is an opportunity to define 
an UPGRADE that uses h2 DATA framing directly, or a new h2 frame type 
that doesn't have the extra framing overhead and legacy ws framing stuff.

-Andy
Received on Friday, 22 March 2019 06:29:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 22 March 2019 06:29:33 UTC