Subject: [Webtransport] A comment on draft-kinnear-httpbis-http2-transport-02

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Nov 2019 10:41:29 +0800

This is a straightforward draft, so my questions don't relate to the
content such much as the context:

The draft extends the CONNECT handshake to allow "bytestream" to be
provided for the :protocol pseudo-header field, instead of "websocket".

Is there corresponding JS API work contemplated (or ongoing) to support
this?

The "WebSocketStream API design"
<https://docs.google.com/document/d/1La1ehXw76HP6n1uUeks-WJGFgAnpX2tCjKts7QFJ57Y/>
indicates "a 1:1 correspondence between chunks and WebSocket messages" so
that it doesn't appear to take "bytestream" into account.

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 19 Nov 2019 04:53:48 +0000

I have a question somewhat similar to Bernard's question.

> that it doesn't appear to take "bytestream" into account.

The WebSocket protocol and API use messages. The draft provides the 
"datagram" :protocol pseudo-header for message-based communication. The 
implementation is very simple: each HTTP/2 DATA frame is a message aka 
datagram. So far so good.

But the WebSocket protocol distinguishes two types of messages: Text 
messages and Binary messages (in terms of implementation, the 
distinction is carried on frames, which make up messages, but the type 
has to be the same for all frames of a message). Also, text messages are 
strictly restricted to always use UTF-8 (see 
https://tools.ietf.org/html/rfc6455#section-1.2).

The distinction between binary and text datagrams, and the limitation of 
text datagrams to UTF-8, considerably simplifies the creation of 
datagram-based protocols and increases interoperability.

I wonder why this wasn't included in the Webtransport draft, and hope 
that it can be added.

[cc.ed to the W3C i18n WG]

Regards,   Martin.

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 19 Nov 2019 13:56:41 +0800

> I wonder why this wasn't included in the Webtransport draft, and hope

Hello Martin,

WebTransport does not make any assumptions about the nature of the payload
it transmits, that is to say, all of the payload is assumed to be binary.
That is consistent with the general way the similar recent API has handled
this (e.g. streaming fetch), as well as the design of underlying
protocols.  TextEncoderStream/TextDecoderStream can be used to easily
transform one into the other.

I'm especially confused about this being related to the datagrams; almost
all datagram protocols I've seen are binary-based, since ~1200 bytes is
typically too small for text-based protocols.

  -- Victor.

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 19 Nov 2019 18:31:09 +0800

Agreed, I think these are somewhat separate concepts. I think draft-kinnear-httpbis-http2-transport is working towards extending HTTP/2 for bidirectional transport *beyond* WebSockets, if you’re intending to send WebSocket data on a stream, you’d use “websocket”, not “bytestream”, and you really probably should register another :protocol value to use for your protocol. The latest rev of the draft here indicates that if you’re going to use “bytestream” you must have negotiated what’s on the bytestream in a different manner. 

Lots more to unpack here, and always happy to chat, but that’s the short version of “bytestream” =/= “websocket”.

Thanks,
Eric

> On Nov 19, 2019, at 1:56 PM, Victor Vasiliev <vasilvv=[email-masked]> wrote:
> 
> On Tue, Nov 19, 2019 at 12:54 PM Martin J.. Dürst <[email-masked]..ac.jp <mailto:[email-masked]>> wrote:
> WebTransport does not make any assumptions about the nature of the payload it transmits, that is to say, all of the payload is assumed to be binary.  That is consistent with the general way the similar recent API has handled this (e.g. streaming fetch), as well as the design of underlying protocols.  TextEncoderStream/TextDecoderStream can be used to easily transform one into the other.
> 
> I'm especially confused about this being related to the datagrams; almost all datagram protocols I've seen are binary-based, since ~1200 bytes is typically too small for text-based protocols.
> 
>   -- Victor.
> -- 
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 19 Nov 2019 18:35:48 +0800

And to the original question about JS API work, I’m not aware of any, however there is a (not-yet-publicly-available) implementation of a native interface that does support this as a general abstraction. I think one of the key goals in WebTransport is going to be making sure that what we’re defining here has a clear boundary between: 

(a) Protocol mechanisms that are expressed on the wire
(b) Mappings to APIs that provide better abstraction, both Web and native.

I can see several possibilities for (b), but we should likely discuss that much more.

Thanks,
Eric

> On Nov 19, 2019, at 6:31 PM, Eric Kinnear <[email-masked]> wrote:
> 
>> On Nov 19, 2019, at 1:56 PM, Victor Vasiliev <vasilvv=[email-masked] <mailto:vasilvv=[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>