Internet Engineering Task Force 106, 20 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF106-WEBTRANS-20191120-1330

Description

WEBTRANS meeting session at IETF106
2019/11/20 1330

https://datatracker.ietf.org/meeting/106/proceedings/

A

B

You can post it to the list. That would be great, even.

A

Posting reviews.

B

Welcome to the web trans buff 106 vehicle could take their seats. That would be great. As you may know, the mailing list is web transported. Itf org we'd encourage you to join. We have a jabber room web trans at Java, IETF org and the chairs are myself Bernardo, boba and David Shanae, Z, Ganassi, sorry dono! Well, hopefully, you've seen this before to reminder of IETF policies. In effect on various topics.

B

The IDF's patent policy is set forth in BCP 79. Please read it carefully as a reminder by participating the idea, if you agree to follow ITF processes and policies in a bunch of other things here, yeah.

C

And I also would like to highlight the code of conduct. If you haven't read it, the high order bit is be nice. If you don't know what that means, read it and we will be enforcing it, but I don't expect it to be a problem and.

B

Definitive information is in the documents listed below and other ITF BCPs, okay, so about the agenda, a few things we've talked about the note. Well, we should probably start distributing the blue sheets and get those going. We'd also like to tell you how volunteers for note takers and jabber scribe.

B

Do we have a volunteer for or volunteers for note takers.

B

Collin Jennings note-taker. Thank you. Do we have anybody else, no takers.

B

Okay, how about a jabber scribe somebody please to join the jabber room? Okay, thank you. Okay, so, on the agenda, we'll be talking a little bit about the context of this Boff as well as bashing the agenda, which is what we're doing right now we're going to start off with an overview of web transport which Victor will do. We then have about 35 minutes for relevant drafts. We have five of those and then we're going to have a general Q&A session of about 25 minutes. The goal is for us to get through the presentations.

B

If we have time within, each presentation will take clarifying questions, but it is a little tight. So we've have this big Q&A session at the end, where we'll take any question relating to the bath and then we'll have a pointer to a charter discussion. This is a non working group forming buff, so we're not going to get into a detailed discussion of a charter, but there is a charter discussion going on in the mailing list and then we'll have a wrap-up and summary. So, as I mentioned, the time management is fairly tight.

B

We'll try to enforce, enforce it, and I will be giving roughly a two minute warning for presentations if we come close and also cutting the mic, all right. So a little bit of context as I mentioned. This is a nonworking reforming buff. The focus is on client-server protocols, protocols, only not api's, we're assuming familiarity with some of the following RFC's, the original RFC for WebSockets, which was our c64 55.

B

For those of you who remember it, it uses the HTTP 1.1, upgrade mechanism to transition of TCP connection from HTTP to a WebSocket connection and then a RFC 8 4 4 1, which is bootstrapping WebSockets from HTTP to which uses the HTTP connect to method as specified in RFC 7540, and that provides a tunnel on a single HTTP, 2 stream to carry data, and it's multiplexed with other streams. So that's the context that we're assuming here and the big question is what's next. What do we do next?

B

After, given those those two documents, we'll hear a proposal for a Datagram transport that is only for background that was already presented in the quick worker, Europe and most likely will be handled there. So but it's useful to just get to know about it and then we're going to hear proposals in two categories. One is a set of two proposals for extending HTTP connect method for HTTP.

B

2 will hear two of those and then we'll hear proposals relating to something called the web transport protocol framework, which includes support for unidirectional, bi-directional streams, unreliable transport of datagrams, using the Datagram transport draft and then potential operation over HGB, 3 and then just over quick and some fallback considerations. So that's kind of framing what you're about to hear in the agenda today, all right so I'm going to hand the mic over to Victor to do the overview of web transport.

D

Good afternoon my name is Victor Vasily ephah, I work for Google and quick team and I about to explain what roughly, when transport is and what problem we're trying to solve here. So the problem we're trying to solve is the problem of bi-directional communication on the web. So there are many ways the websites can communicate. The servers and many api's that accompany the bi-directional ones means that the messages can freely flow at any time in both ways. So, for instance, the fetch API assumes request response and strictly enforces that and server-side events.

D

It seems that or web push are focused on server pushing to client, but here we're talking about interactive sessions, ah so the most the original way we did. It is using an API and protocol called WebSocket, which allows send messages in both directions. Then, eventually, somewhere along the way there was the rtcdatachannel, which is has more transport flexibilities and web sockets because WebSocket this TCP base.

D

So it only allows you to do whatever TCP allows rtcdatachannel, whereas our HTTP based, so they allow you to do partial or unreliable and unordered messages, but, however, are not solving our problem because they are designed for peer-to-peer use case. So there is a gap for reliable button orders and we're unreliable and ordered messages, communications that for client-server context, and we intend to address that gap using web transport.

D

So what is web transport web transport? It's roughly. It's not one protocol, because we found that there are multiple protocols that people would want to use depending on context, but all those protocols and api's provide two main features. One is that they allow you to send dreams and receive streams, and streams are well there if you're familiar of quakes. There are basically quick streams. They are in a lot of ways similar to things like WebSocket messages or HTTP messages or a lot of other contexts and senses.

D

There are reliable at least two things: a single stream and single stream were saved in the order. They are arbitrary size, so you can send as many data on a single stream as you want, which is Atlas, a property which is often desired, but in a lot of cases we fail the chief to us, okay and the extradition is set.

D

The streams are assumed to be independent, ie, a loss on packets of data on one stream does not block reading from I surf stream and they're assumed to be cancelable in the sense that if you close a stream, you can stop we're transmitting all of the data that you've already committed to that stream. The second feature provided by all web transport protocols or datagrams and data grants are roughly basically UDP. They are assumed to be at most M.

D

Psi stands they're assumed to be completely unreliable and I say when possible, because we define some transports which do map on TCP. You are that's often impossible. So what makes us interesting is that the webparts, the part where we expose web transport to basically arbitrary JavaScript code at Ranson user, imposes us a lot of requirements and a lot of the work most of the work around those protocols is about satisfying the requirements so number one. We need the encryption and authentication of TLS, so that's fairly straightforward number. Two.

D

We need to make sure that there is a feedback based congestion control ie there, unlike before all UDP sockets. You cannot overload the network with poorly behaving clients because we have no guarantees about behavior. There is a requirement and origin check, and this is a very important because on the web, you are assumed to enforce access through sending the origin of website which initiates as a connection, there's also currencies web. It's important for a quick transport connection to not be able to just pretend it's a regular, quick, socket or TCP socket or UDP socket.

D

So there's a defense against protocol attacks and they're lost in the interesting is that would have to integrate with things like content security policy. So we want all resources to be identifiable using Kri.

D

So why do we want this? There are roughly the original page is WebSocket for UDP. A lot of people want well some things that works a lot like WebSocket, they had simplicity of WebSocket but is not tied to TCP and for years. We struggle to provide this because there was no really good way to provide with security properties, but also provides and reliability, and the other is WebSockets, but without head-of-line blocking is like I have multiple independent streams of messages and I want them to be independent or we've reached out.

D

We've talked to a lot of people and we bill it. A lot of them are interested. There is wide range. One of them is web game developers who are very interested in doing online multiplayer games. It's a lot of interested for applications like remote, desktop or cloud gaming, where it's a wary user does something and it's a server.

D

And then you get picture back and it's very important for that to have little lag, which is impossible impossible with TCP and web chat is an example of an application which is possible right now, but would work much better if you have independence, so we preserve roughly four transports proposed and they can be split across two axes. First, access is really simple: it's whether it's based on quick or based on TCP and as well.

D

No quick is often blocked and network, so we almost always need a TCP based back and the second axis and more interesting czar transports which provide dedicated, very ross level connections and their higher level transport which provide pooled connections by pulling by using HTTP session polling.

D

So that access is a roughly exists because I've talked to many and users and there are roughly two cases. Well, there are people who want far most fine-grained control over transport and sort of people who care about real-time or people who care about having as little dependences as possible and HTTP. Free transport is more optimal because one it allows you to cut all of the handshake latency.

D

All of the slow start latency and it in general intro, has all the nice properties of HTTP like routing and naming, and the second axis is quick versus tcp and we have roughly two proposals. One is I've not written itself, it's called fallback transport and the idea is that you can write some things that looks like quick connection, but they send over WebSocket, so it is completely pol available in JavaScript. Web developers would just be able to use it today because it's just based on existing way.

D

Yes, second for HTTP free is a most natural fault, occurs, HTTP two, because they're intended to be semantically equivalent. So that's basically it's a short summary of what we're going to talk about today and what's it proposed code before case.

B

Yeah we have time for about two minutes of clarifying questions.

D

Any clarifying questions so anything I've, said so far.

E

Colonies just real question: you do you have a require on your requirement slide. You have a requirement as well for into you discovery, given the data grams or MTU sized cause.

D

That's a good question: I need to clarify that, but like basically like they're in API were required to give being able to give them to you. But that's like more detailed and we're required to empty you to be maintained across calls for like HTTP when you proxy it.

F

Tommy Polly Apple, so the question before you got to this slide. That I would have asked is like okay. How are we doing this fallback transport because TCP is not equivalent to quick, because you're not gonna get the multi streaming, so this makes sense. So I clarifying question is you say it's based on WebSocket is what, in what ways is it more than WebSocket? And can we call it something like WebSocket transport.

D

Patients, it looks like quick, so it has multiple strings where it's well suck. It doesn't have multi-streaming it's one string, but.

F

Websocket has like message delineation and framing in it, which is the key difference from just a TCP stream and so I assume you're, just using those messy yeah.

D

In three my face exactly.

F

The string mission- okay yeah- maybe we should work on the name to be.

G

Genetic, so a number of the use case, you had also have requirements on like low latency congestion control, which would require something a different control. Then it's like the standard bulk transfer for quick has to be looked at that at all, and how would that.

D

Short answer is on server. You can do whatever you want, because well, whatever you you'll tear your code, you put your quic library, allows you, so you have controls as you do, with TCP or UDP or anything. You control your server II of control, your operating system on client. It is a more interesting topic and roughly oh we've dated yeah, it's a very interesting topic. We have an open issue and yet have you're welcome to it. What we've discussed so far.

H

Erika scroller can just go back, I think one slide or to the triad.

I

H

You go fantastic, sorry.

I

H

This one right um so on as I on is it required that we standardize all these.

D

For fallback transfers, it's not actually required with standardized.

H

It would be nice, I mean I, guess I guess so, like supposing I'm of the opinion that, like HDPE, is everything and um then I don't need stuff on the right right. Yeah I'm, not arguing to understand what that with brizl is the.

D

Proposal of standardized the top ones required standardization, basically, uh okay, so right wonder cry standardization below us, we extend say IETF standard. That requires the top left. One requires basically cut point assignment and it requires some protocol which would be implement both by browsers and server. So the standards would be really it's there to make sure we have arrived to something into a purple. Okay,.

H

But some point the future would be interesting for me to understand why you think issue quick transport is needed, but perhaps not now. Okay might.

C

I suggest bringing this question back after the presentation on quick transport which microclimate.

B

I have right at but.

C

B

Think we should cut the mic and go on to the next presentation.

J

All right, that's better howdy. So if anybody was in quick this morning, you have seen all of these slides and we will make it very very fast. So we can get on to the next one that you haven't already seen so in talking about an unreliable data. Extension too quick we're looking at kind of that bottom section of what happens when we need unreliable data transmission and we've got lots of applications that want to do reliable control streams and unreliable flows.

J

List of use cases here, vectors list of use cases earlier, there's a lot more I hope nobody's offended if they're, not in that list. Right now, so quick is giving you a opportunity that we are using for the extension mechanism with quick where we would like to be able to have our reliable or our reliable data be transmitted alongside are unreliable data and we'd like to take advantage of the congestion controller and all of the other things in quick, like the ability to negotiate things via transport parameters.

J

The ability to have our unreliable data be act even if it's not retransmitted, we'd like to use the handshake in the authentication context and you're, also very, very likely to already have a quick connection up, especially if you're negotiating something. So in the standard use case where you you bring up a control string, you negotiate the use of some particular data channel that you're going to send, and then you send unreliable data over that channel in this case.

J

Instead of having to do another handshake to bring up that channel, you simply open or not open, but you simply start sending datagrams alongside your existing connection, that has all your reliable data. It looks like this. It's a frame, it's one of the more simple frames you could ever do you say it's a Datagram and then you put stuff in it. It has a length that is optional. If you'd like to have a link there, you can pack it in with other frames in a packet.

J

If you don't have a length, it extends to the end of the packet. That's exceptionally useful! If you are tunneling something over this and we negotiate it with the transport parameter, that also helps give you hints as to things like MTU and how big your Datagram should be they're a felicity. They are not retransmitted, they do not contribute to flow control. We got lots of really good feedback about this in quick this morning. So we will have more discussions about that.

J

If you'd like to talk, we'd love to chat, there's no more flow ID, although that is now in David's draft for h3 Datagram, and one of the comments that comes up here is that many many many of the potential uses of datagrams have a very, very similar concept of flow.

J

Id and people seem to be pretty split as to whether that's something that each application should define how that works, or if you should have a common one, since they all have it and you'd like to be able to run maybe more than one thing at the same time, which is seems pretty sensible but we'll get there.

J

We've got a bunch of people who are supporting us right now and since we put these slides up, we've got a couple more. So that's even fun, because it's not that hard to add support for a new frame types that you stick stuff in and we had some nice Interop during the hackathon. So that brings us to the end of datagrams the idea here being that we will have a way within quick to send unreliable data that is multiplexed alongside reliable stuff, which is kind of where web transport needs a building block.

B

Any clarifying questions.

C

And to repeat a quick point since someone asked offline, the current plan is for this extension to live in the quick working group. We're just having kindly give this presentation to give people context that weren't here this morning.

J

K

F

Tell me Paulie Apple, so this is not a question really for you as much as for the use of web transport of this, so we'll have a flow ID in the h3 layer, but not necessarily in the raw quick layer. Will we be talking about that later about, like? Is that one of the modifications that we'll have in quick transport well.

B

I think Victor will talk about the session ID in HD to b3 transport. Okay and we'll also have a presentation on quick transport. So hopefully that will cover so.

F

That will that should address, like the use of Floyd, easier, I. Think.

B

L

Cory Fairhurst, being very brief, but I mean, are we expected to multiplex different types of traffic together as in the web, sockets and other traffic, because I have concerns about the flock where the floor control might spin out in that direction and that might something for quick tilaka? Yes, we should talk.

B

J

All right we made it in under five minutes. Let's do it again, so we've talked about this a little bit in the past, in both TS vwg and in HTP phase, but this is kind of the. How do we do multiplexed byte streams over HB 2? So we want to have a generic way to transport on a single kind of on the wire transport connection, secure multiplex, byte streams that can be either unidirectional or bi-directional.

J

We'd like to have already done all the handshakes we need, so that we have a low setup cost for new streams, we'd like to be able to share a single congestion and recovery context for getting these reliable streams to the other side.

J

One of the use cases that comes up and will add to this list a little bit later is peer-to-peer communication if you're doing something like remote our pieces, remote, IPC or really any other time where you you need to have multiplexing of multiple streams of data where you'd like them to be bundled together.

J

As a group and we'd like to be able to do that, while we share the underlying transport with existing infrastructure that actually like gets across the internet, so HB 2 is a great candidate for this, because it gives you a way to exchange and negotiate things. It gives you multiple extremes. It gives you that same shared recovery, State, it gives you flow control.

J

It gives you stream relationships, and it also happens to work on the internet, which is kind of a nice benefit and, of course, some of these properties and a lot of the you know fact that it's secure, etc is coming from TLS and the reliability coming from TCP, etc, etc. But the whole point is H to taken as a transport provides. A lot of these functionalities aren't actually specific to hgp itself that have nothing to do with a particular request for a resource in a response to that.

J

So we've had a couple of different ways that we've solved. This we've talked about adding new frame types, the zero zero version of the draft actually added a new frame type, which you could use bi-directionally, based on some of the conversations that we had since then we moved on to extending the connect handshake, so we basically use connect to connect through a remote endpoint to somebody else, and then the WebSocket over H to RFC allows extending that connect to actually connect to a particular protocol.

J

Token, that's on the server and we can use the headers that go along with that connect request to add additional negotiation of like what are we going to be talking here, and so we want to be able to do the same thing where we have traditional HTTP request/response streams. On this connection and on the same connection, I've already got to somebody. I can say this: other stream is for X, and then we can talk X over that stream.

J

Alongside and in some versions of this document, we've had tunneling of messages or datagrams with additional framing or you can punt that out and treat it as a separate thing negotiated in a very similar manner, which is what we've done in the latest versions of the draft to keep things a little more focused, so basically extend to connect, as it is today defines WebSocket and has a bunch of other headers that are very specific to WebSockets. So pretty much.

J

What we're saying here is we'd like to define a new protocol value which is byte stream and say you, don't really have to send all these WebSocket specific things, because this is going to be generic, not WebSockets, so you can not do the parts that you previously had to do, and so we say here, if you specify byte stream, you capital must have already negotiated some way of knowing what is going to be on that byte stream.

J

But the suggestion there is that you can specify your own protocol token there the same way WebSocket does to say this is what I'm going to be speaking over this stream, which is where some of these other things that Victor is going to talk about come in. So we talked about how we could do this for some remote IPC stuff.

J

This also is interesting when it comes to things like quick, because HTP 3-over quick, can fall back to HB 2 over TLS TCP, so to victors question of what happens when quic is blocked, what happens when you're not doing H 3 but you're, actually just using quick, the transport parts of quick and that's blocked, and how do you get the equivalent thing over TCP, so H 2 gives you a lot of the same things that quick the transport does.

J

Can we use that alongside so the only thing that we're missing here is we defined a new setting that says we can now do this extended, connect, handshake, bidirectionally, the same way that quick can initiate a stream from either endpoint of the connection. So, in summary, we go through. We add some new protocol values, we stripped down the extended connect handshake and we allow you to do it in two directions. The key here, where I think this fits into web transports is we're looking to multiplex multiple things over a single connection.

J

We need to have some mechanism for negotiating what the use is of that stream.

J

What are you going to be talking on this byte stream is minimally useful for the use cases that we happen to have where we already know what the other guy is going to be talking, because we've already done that out of hand, but if you're doing this in a more generic way, you'd really like to be able to negotiate that, and we need to be able to do this by directionally, which means we need to be able to traverse intermediaries in both directions.

J

So you need some way to when the traditional server is saying, I'd like to open a stream to a client. You need some way to know which potential client do you want that to go to and it'd be real nice if this could be extended to support unreliable, unreliable delivery and datagrams, although unreliable delivery, when you're running over tos and tcp is a little bit harder, but at the very least, datagrams and messages are very useful concepts that we're looking for out of this general space.

B

Can any clarifying questions.

B

M

Repair tipping on Facebook I.

M

Am curious, why we're thinking it's okay, to not say what the protocol is, that we're tunneling, it's just a string and it could definitely be very useful and- and if this is a crazy question, you know just say crazy, we'll talk about it later, but in the past, when I worked on load balancers, knowing what kind of thing was tunneling could allow it to do de multiplexing, and/or reordering in ways that were very helpful, so the lack of that could be interesting anyway.

J

God thinks that would be totally reasonable to put in there. This is a legacy, because the use case that we were actually shipped for this does not need that, because it's already negotiate out of bin and there's only one particular value there. So for us it's a useless token, because we're not picking between anything but to use this more generically I think we do.

B

Okay, I think we'll move to the next presentation.

N

Hello, everyone next, though, I will present HTTP extension for messages case LM and from Facebook, and we already published. Listen this internet draft, so different from web browsing message will require by Direction communication. So, basically, client need to send a message to server and I get a little knowledge and server sometimes also needed to send a request down to a client and get a little spot. So we are not on the first one to build a list by direction.

N

Communication solution on top of HTTP last many existing solution, we categorize layer to two major groups, so first ones Street internally. Second wines, server push in the next I were talking about why they are not good enough for messenger use case when we said, say: string tunneling, so, basically, client established actually DB stream to server after lap.

N

The string is used as a tunnel based on the way of the user, usually string less many solution, many internet standard ones, lawn pooling another one to web socket and third ones aggregate just talking about changing strings in Manteca to byte stream. So once this is done already, server can initiate a communication. Took talk line fearlessly? No, so I wanted to point it's worthwhile to point out. This is a string. It's used as law socket. So basically, we are used actually the product application protocol as transport protocol. Here.

N

That means client server has to speak some product application, product Ovilus tunnel. So let's element even for listen, this kind of approach, so first one it introduces extra complexity. So basically the data needed to go through multiple, multiple layers of dreaming, for example, you have to go to application layer WebSocket earlier and that julia and they will be at an article head on top of it and make it a less efficient on a wire.

N

This is lab. We forced the web developer to this endless um protocol on top of just lister, no more important. Actually, by sending all message within one single string, we actually defeated many optimization introduced at the back actually db2 and that should easily. For example, if we send the all a message on one string, we reintroduce the head of line blocking in HTTP slickest and also because we send all that all a message, your state of rain, so we bypass a header compression scene.

N

So we only have one screen now and of course, we basilar stream prioritization and the sun control message. If, for example, go away is becomes less effective because there's no clear boundary with one string, so then the natural question: what about actually be to push server push so solar push it's optimal best ever optimization to regular content degree for latency from server to client. So let's take a look at how it works together. So we assume there's a social data stream. It's already established, flan client, the proxy and the server.

N

Now server wanted to send a message to client either we believe furnaces, open, a social stream and descended onto planned, because this is the best ever and this message you may are made may not make Trula claimed and it's not a reliable communication for messenger, so listen lack of a chronology making it unsuitable for our use case.

N

So what do we do? What do we do in the proposal? It's a way make a socialist dream: more generic. We caught Lord Hill Street in English, upped, as its name implies. This string is owning used for loading purpose. We also introduced a new frame call extended header, it's very similar to regular, actually DP had actually headers, let only into difference once this header can be sent by disappear to open the extend to the street, and it also needed to open street for loading purpose. So, let's take a look at how it works.

N

Assume the loading screens already established server lender can initiate extend astray by send out a extend ahead. Proxy will be useless, as referred Lorien stream to make a lot initiation and, finally, the way be loaded to the server. Then we get a response below server, so server can do this too. So basically, he opened a open, extended string with extend header and a get a response from client with Lisa. By deduction communication we can use actually db2 for messages use case.

N

So here it's more since about the hallway Hollis can use the to traverse media media's. So, let's assume we already have this lot in a lot instant, ready from client one declined to and the info server wanna send a message to climb the wall. He just need to refer this Lord history. He can do this one for kleiner too, and we also can use this worm for basically lists also can use the for grouping streets.

N

Let's assume we have this lot history and all the extension string reversed. When is lot in stream, we go to sever one and the server to so cool party. So we don't need all that extended string, don't need to carry about any headers for loading purpose so mostly close to work with with us. It's a web transport of a tree and need only be presented by difficulty next here, I want to give a head-to-head a comparison between our extension and over website web transport over street.

N

So firstly, it's a lot in stream versus web a transporter session, so they are very similar and posses used for loading purpose and post use data dependence, trees, extended stream vs. web trans went web transport stream. This is a fairly similar. They can create by either pier and less Lord. It's really depending on Laura string or session ID. It cannot have independent loaded, but we have some fundamental difference. It's. How do we model message? The data exchange between client and server? Our proposal is to try to model the data exchanged as actually be message.

N

So basically, when I say actually massively it's a structured metadata across data in web, which is virtually persuade the model data as by a string of bytes. So we believe actually be message: it's a better obstruction and it's a really broad building block and it's more friendly for end-users.

N

Okay, I will stop here and clarifying.

B

B

M

Repair to pay on just I'm gonna ask us to make sure we're all on the same page that a quick description of this could be that we are saying that we have a bunch of HTTP messages and we want to make sure that they are all routed to the same final destination: correct, mm-hmm, okay, thank you very much.

O

Relaying for Chris lemons do I correctly understand that every proxy between the client and server must support these extended streams for them to operate. Yes,.

N

It's neither to be what are you end-to-end? Yes,.

B

Okay, we'll go to the next presentation. Thank.

N

D

D

D

I've outlined before what what what transfer is and now that's I want to go over to particular protocols proposed, and one of them is called quick transport in our escalation. Free transport. So quick transport is basically it's IDs. It's like WebSocket, but for quick and unlike WebSockets, the design principle where I've adopted was we're going to take quick and extend it as minimal as possible. That is, we will not add features and make it as easy to implement and understand for people who already know what quickest.

D

So, what are the extensions that we do have to add and turns out? There are basically three things you need to add for quick to to allow your JavaScript to initiate quick connections wellness. You need to make sure that the connections Shadid from the web do not appear like regular connections and we use a TL TL SLBM mechanism forces with the finding KL p and values to make sure that it's WQ, as opposed to, for example, H free, which is HTTP free value, and the browser enforces that.

D

The second is that the client, the server, has to know what was the origin of the webpage, which initiated the connection, and in order to do this, we have a dedicated stream which would call client indication which I'll go out there. The surge is we need to your eye, since this is not a treaty viewing, it knew your ice cream. So client indication is just how we tell what the origin is.

D

It is a simple key value couple of that sentence from two: we define only two keys, one, its origin in which you specify origin code, it as defines itself see. The second is a path and the path I mentioned the URL. So the quick transport has very simple your eye. Seema, it's a you, have the hostname hostname is what you connect to in it's sent as a part of as an eyes. That's how the server knows.

D

What's the hostname is you have support number two which you connect, and there is a path in the query component, which are all sent as a part of that string to its well. It's that simple, oh okay, so here is a worked. Example of everything that happens, example.com tries to connect to server to test, to import 50 cells and using the your I specify there as a browser sends clan, hello and make sure say, L p.m. is that week you the server replies with LT and W. It which points a browser knows.

D

That's a server in fact wants to talk to a web client as opposed to just random, quick client on step. Four or the browser now can sense the origin and the path component and it senses in the stream, after which the browser basically can allow the client to send whatever client data wants. Whatever data client, once it's f5 the class, the server receives the origin, it's which has two options: either to accept the origin or to just tear down the connection appropriate error code. After this handshake happened.

D

The connection basically is not different from regular, quick connection. You can open quick streams and they are directly mapped to the streams you have and you can send. Data grams and the data grams are just like sick glasses, serve. The client can call send Datagram and whatever client sends a sense there. So that is overview at this entirety of quick transport protocol.

D

Http free transport is approximately that simple, except here it's a since it's over HTTP free the problems like your eye and origin or so for us, because we can send origin using headers and we send your own headers and we can just use HTTP URI.

D

So what HTTP free transport is is it gives you effectively illogical or some things that looks like a quick connection, ie, it's a collection of streams where you can send and receive strings in both direction and you can send data grams, but it's inside the existing HTTP free connection, which is your favorite connection and they check a single session can be a single HTTP. Free connection can have as many HTTP free session as the server allows, because they're all multiplex.

D

So the way you do establish that connection, it's very similar to the concept of the routing stream in the previous proposal, is that you use extended connect to send the request to establish the session if the server accepts it gives you an ID which is uniquely scoped to that connection, and once you have that ID, you can create streams on both sides by using a special I define in the draft, I define a special frame, and you say this belongs to an HTTP free transport.

D

This is the idea of that transport and the rest of the stream or the rest of the Datagram is whatever the application wants. I know that is written currently as a proposal. That's nothing fly any higher level semantics like headers or anything you using ATP, so it's mostly using HTTP as a channel, so I, similarly to quick transport. I have two worked. Example for this: it's like you this time you use an HTTP URL and it sends a connect request with predefined parameters. It's also used since its uses extended connect.

D

It also this times a custom protocol header and for everything else. Iii user suggesting HTTP mechanisms- oh so that's! Basically it yeah.

B

So we can take some clarifying questions on Victor's two presentations, quick transport and htv-3 transport, and then we can go into the general Q&A. So any clarifying questions relating to the two presentations Victor just gave I.

P

Look spotty CloudFlare, so I was reading the specification for HTTP 3 transport and, as you got here, you say that you require the extended connect method. Yeah I just wanted to double check my understanding in the h2 that is enabled via a h2 setting, but in.

D

P

This is done by a a quick transport parameter, ah I.

D

Think that's the way I've written the right it was written because I wanted to make sure that around the time you enable it. You also enable server initiated by directional streams, because HTTP by default requires you to set that flow control to zero and disable it. That is, might not have been a good decision. It's a details that we need to sort out. That's one of the it's also we doing it to sort out, but yeah it can be made identical to how it's an able to make gtp to. Let's.

P

Go I just I just wanted to check my understanding, because what what that is is completely allowed, like you, don't need to have only a setting as a way to do modifications to the protocol. It's something that's bitten, you so yeah. Let's definitely discuss that in the future. Yes,.

D

Definitely well something I should I'm, not sure I might have opened an issue about they don't get hep. If not, which would happen. Let them discuss.

F

No tell me Polly Apple, so HD transport makes sense. Can we go back to the quick one yeah so yeah? Let's look the your eye, one! That's the next one, that's fun!

F

So could you clarify a bit like what we're thinking like for the interpretation of like the path? In this case it is the path meaning. What was the.

D

Like what do you imagine it's the passes, whatever semantics application signs to it? It's so the URL is like the Europe. We could define a schema without a path, but we've talked with people who try to use it, and they said it would be like really convenient for them to have some indication on handshake levels that they can use right.

F

It just feels like, like the if re-ride namespaces, we have its quick transport, it's pretty open-ended and it feels I could be good to specify what it means beyond just kind of like a black hole of what I'm gonna get is if I'm connecting to a generic server. I would like to have some kind of an understanding of what this is being well.

D

So the problem I was trying to solve with path in particular. Is so when you establish quick, yes, quick, you could use a LPN to multiplex multiple applications on a single server sure, but since here we use LPN for our security purposes, we need we need it to provide some replacement matter. So.

F

The net really like it could be kind of like the interior application, and that's the thing that you're indicating, but maybe spilling that out, that that is how this is to be used would help, because, looking at this, if you're coming out from another perspective, like is this path at all related to a normal HTTP URI path. Is this the location of a resource that you're trying to access it or the protocol you're trying to use, and those are very different things.

C

Tommy could I ask you to please send that to the list or following Shawna get up just to make sure.

M

C

Up awesome, Thank, You.

M

Rebecca pound.

M

With my pasts, using or being associated with some of the creation of WebSockets I can say that the lack of multiplexing there really sucked and it resulted in a slow deployment landscape, and it also resulted in a bunch of interesting restrictions from the JavaScript and the browser API surface because of security and das restrictions or concerns, especially about you know, killing virgins.

M

So my question is: have we forgotten this pain and do we think we have a solution to it here, so that URI, for instance, makes me very afraid if we're gonna offer that a level of flexibility from the JavaScript surface because of denial of service and similar concerns, the similar API surface from h2 or h3, leaves me much less scared because we're offering a very different threat model via those things. So another way to say all this is like what threat models are we considering with the exposure of the circuits here, Thanks.

B

Yeah, actually, that might be good to file as an issue as well. Thank you.

D

Yes, like, uh if you have any specific threats in minds you want to discuss, please do indicates if I will make sure sending emails for mailing list, because we do need to think so. It's those.

Q

Staff, gentle, just a quick clarifying question, I'm curious what the status of talking to the web folks about adding IP Isis. Oh ok,.

D

So the status to this well folks, there is an API Trav's, as is currently being incubated in EE ICG. We at some point intend to advance its first w3c tracks, but currently we're not ready. It's related to our implementation effort. So far is we have been working on quick transport and we have the protocol code is already implemented. So there is a like simple toy server, which will go streams back.

D

If you ask loans, the API surface there's a little bit more integration, but with hope to have it demo, prototype people can play with eventually we're HTTP free transport we're a little bit less ahead, mostly because I want to get there to try to unify the semantics of H free transport with other h2 based proposals and to understand what actually should happen there, and at that point we would see how we go around to implementing that.

R

Bishop Akamai couple observations particularly around the URL here, since this is going for parody with WebSockets and WebSockets is target of a particular resource and not at the origin as a whole. So if you want to have a similar API, you have to have a resource, but this actually inverts an order that you get in regular HTTP, because the HTTP and the client says I want this resource and I would like to do WebSockets with it, and the server gives it a thumbs up thumbs down on that order of requests.

R

Here you go to the server and say: I would like to do WebSockets with you. Server gives a thumbs-up or thumbs-down, and then the client tells that what resource it wants, which you've now, if nothing else, you're disclosing at the connect time that there is something on the server who accept a WebSocket connection, which might be a probing concern.

R

But I don't know, I, don't know how that impacts the security surface, but it seems like you, really you're losing the ability for the server to look at the whole request at once before it makes a decision and you're separating it into two separate decisions. I mean what do you mean before making a decision so well with HCP the server the server can see both.

D

So decision to disclose this with supports with yes.

S

Bert, yes,.

D

Yeah- and this is large really yes, so when I said it's like WebSockets, there were lots of things which we try to not copy from WebSockets, mostly because we tried to go for minimalism like, for instance, WebSockets, despite not being said in RFC, will automatically send you cookies, and we don't do that just because.

C

Mike same question: please, on issue.

F

Tommy again so kind of bouncing off what Mike was saying here: that inversion of semantics has implications on the fallback. If your fallback is to WebSockets, because now you essentially have different guarantees and you're accessing different things, because WebSocket does allow you to specify something off of a particular HTTP path, and this doesn't let you do that and so they're really not equivalent for fallback. So we should figure out a way to reconcile that ah understood.

R

I'm sure it's in the draft which I have not read I'm sorry, but when the server accepts the origin, can you go and do a little more detail on how it does that ah it.

D

Accepts the origin by accepting the stream, it reads the data from stream until it reads the data and finishes reading the data, it will not process any data and as soon as processes the data it has option to send either connection flows or to hand it off to application.

R

Okay, so acceptance is really not killing it. Oh.

D

B

D

Reason we did not add an explicit okay is because otherwise you would get a round-trip penalty, because you would have to wait for acknowledgement from server. ah So that would add an extra round trip to the entire handshake.

B

um We're now going to move into the general Q&A. No, you can come back in which you can ask any question. You want clarifying questions. Other questions, it's kind of open mic, roughly 15 minutes in.

G

Sweat Google on this particularly sure I think this is an interesting topic. I had one detailed question: is there reason and quick not to put this in as transport params and then you don't have to use stream to and then by the time the handshake completes. You know that it works just seems like it's. A transactional I mean that's a very quick sort of thing to do anyway. He always a reason, but oh.

D

That was actually the original design, but it turns out the main, the problem with Jasper and since the clan transplants are not encrypted and we want privacy for both of those. So.

H

This gets back, I think the question I was asking earlier, which is I, don't quite understand what the rationale is for Transport. Suppose atv-3 should be three transport I understand it's like less clunky, but um having one thing is less clunky than having two things. So can someone likes me at bay? Is there a tactical weight way which is dramatically better or is it me really like I, don't want to absorb all the HTTP machinery.

C

So the feedback we heard by some developers to the W went to the w3c API was that they wanted something very, very lightweight on that, like especially for game developers on that game server, so they could have their web server for the game where you do HTTP and then, when you connect to that, you can go up to the Mike or get in line to answer to comment on that victor okay. Well, we can debate that better.

H

But I stratum is extraordinary, unpersuasive other.

D

Reason is notably when you pull saying so. You now end up in the situation where all of your connections you're an HTTP free connection and each deeper connection is shared between multiple entities which are across security boundary for each other. So, for example, I can't add method like give me the stats for this connection, because that will reveal information. I can't even do things like give me the idea of the stream, because that was reveal information about other traffic, which is privilege boundary separated by this.

D

That's one of the problems we ran into as well or synchronous, Rho. That.

H

Sounds like entirely problem your implementation, not a problem.

H

The like this, we'll.

T

Put wire protocols.

H

So like, if you want, if you want to separate, if you want to separate different different trust domains across their different important different, are questions you can like. We can take that this doesn't popular. Yet, where do this group, but like like the Tweedy.

U

Non Thompson, one of the problems that we've identified here this week into talking about this is how these things are identified, and so one of the one of the kind of core problems with WebSockets was the way that it ultimately ended up integrating with Fitch, because that defines how it integrates with things like CSP and all the other sort of web tech stuffs and while WebSockets ostensibly has its own your ice cream.

U

In practice, we decided to effectively arrays that when it came to talking about things like connect source and all those sorts of other mechanisms, so understanding how this fits into that ecosystem is going to be a critical part of this work. I, don't think it's gonna happen here as much, but we're gonna have to be aware of it and you're gonna have to coordinate color closely on these things. So I just wanted to point that out.

U

I, don't think that stops us from starting work like this, but I did get from a sense from the previous conversation that that's gonna interact with quick transport, in particular. Ok,.

B

Can you file an issue for that martin.

U

I I will do something I've been typing it up as soon as we speak. The other thing that concerns.

C

Me here is that this or can I answer that before just one quick point is that, like you say, I think that they're getting to really to the bottom of this will be a w3c question. What we really need to get right is the interface between what we're building at the ITF and the w3c. The current interface is a URI, maybe that's good enough, maybe not, and so that, if it's not that's clearly what we need to get to the bottom of.

C

But if we say that are you are if we have an intuition that the URL is good enough, but we need to get right what the URI means, then that's a really conversation, but we need to have it at there with VC just to make sure we define the scope of this bar as opposed to what would happen in the in the webbing addition to up at the roof. You see I.

U

Was gonna expand further on that, because I think Roberto's point earlier about multiplexing and quick transport is one that we're going to have to deal with, and that has implications here. Victor's points are valid: we've got to work through that particular chord Meyer, and there are security related decisions that we need to be making and some of those security related decisions will need to be made here when we, when we make them and then like this, is just complicated, unfortunately, and there's no other way around it.

U

We're gonna have to deal with the fact that the w3c is there. We're gonna have to also coordinate with what working group in order to get the fiction pitch integration going. So this is I'm just trying to give people an impression for the scope of the work here so that we understand where all the different pieces have to fit together.

M

Repair toupee on illness lead off with a comment that I don't want anybody to take any of these questions as a lack of enthusiasm.

M

The whole reason I'm asking these questions is because I really want to see this succeed. So here goes.

M

Websockets was really really painful. I said this before WebSockets was really really painful, and a lot of that pain came because the group of people who came together to ask for the requirements didn't understand the requirements they thought they were asking for. Something simple right but simple, to write and simple to operate are completely different things right and if anybody is thinking that they want something simple to write, you need to disabuse them of that notion as nicely as possible, because they really want is simple to operate now.

M

Websockets was not that there are practical considerations that we must all deal with, like server restarts redirecting to other places, etc, etc. That really suggests that we we should consider the protocols that deal with multiplexing today are the ones that have dealt with most of those practical considerations and I strongly suggest that we ignore anything but those protocols, whether it's HTTP or something else, really care. But those practical considerations should dominate thanks, guys, I.

K

Travel Google same questions that I'm going to ask here are indicative enthusiasm, I, think one of the things that, like so I, mean yeah, to reiterate getting the interface right here, is crucial at the beginning of this effort. I am not really sure. I am primarily look at this from the ietf side of things, I'm, not sure.

K

If the state of these interfaces in what WG I'm not sure the state of these interfaces in in w3c I, don't know how fluid they are, or if this is basically the w3c coming to us saying: hey, we have this interface. Please give us an implementation of this one of the things what it has no w3c status at all. Okay, that makes this both easier and harder.

K

It makes it easier because we don't we're not in a situation where we have to provide a service that has been already specified in a way, that's wrong for implementation. It makes it a lot harder in that we're gonna have to have some sort of process in this working group. That is a tighter loop than the process. Then any process that I am aware of. That's ever run between the dye ETF in the w3c and it's crucial. We get that right and I'm not sure how to make sure that happens.

K

Other than just make David go to both.

B

So to talk to that, you know one of the things that's important to understand: it's protocols lasts a lot longer than api's yep, and you know there are. There are problems in both the WebSocket protocol and in the websocket api, but I think we're envisaging that the feedback loop would go primarily from IETF to w3c and a lot of the questions you're asking would be answered here rather than you know, creating this endless loop or or a need for lots of liaisons and stuff like that and.

C

All that that that the I've, recognising several people in the room here who were also at tea, packs the w3c in-person meeting last month, so I'm very optimistic that there's gonna be enough. Cross-Pollination that we can have this type feedback, loop and I see our liaison to the w3c getting up. So that's, if you don't mind letting mark jump in.

V

So yeah mark Nottingham speaking as liaison from the ITF, the w3c.

V

This is being discussed in the w3c, it's being proposed there. It does not have any official status, but I would without putting words in their mouths to say that from what I've seen the w3c is pretty keen about this, so I would not take that lack of statuses as indicative of lack of interest. I think they they probably want to make it happen and they're waiting for us to some degree. So if we want this to happen, we shouldn't get it on that. We can make the liaison work yeah thanks and.

C

In a way, I think we've already started the feedback loop, because we've been at the w3c, it's been presented there and then they're saying okay, their same not putting were soon enough, but from the conversations I had there. People are saying hello: let's do this and then okay, we turned around okay, let's have a Boff I.

K

Would suggest um in any future working group forming working group formation around this work that that liaison relationship? You made an explicit part of the process of the working group, whether that be as simple as hey. You know, at each meeting, we're gonna have a readout of the liaison just to make sure that the health of that is yes and.

C

That is in our.

K

Draft Charter, which we will touch on a little bit: okay,.

C

K

This session um I have one other comment: I look around Bernard's observation, because I think both of these are true protocols lost a lot longer than api's and api's lasts a lot longer than protocols right like so. It kind of depends on the the environment that you're in one of the things that I am seeing is bubbling up into. The API of this is something that looks like a stack specification right like so it's the same thing as a LPN is being used, slash, abuse for and quick.

K

It's like now we're talking about further up the stack. So it's like you have, like you know, h3. You know: web transport, h3, quick web transport, h2 tcp, web transport, quick. This is a recurring pad and it seems like we, as the ietf probably need to get that right once because doing it a whole bunch of different ways and a whole bunch of different places, and then baking bad into the interface into the API seems like a way to make mistakes. That will hurt us for a long time.

K

I, don't know what the answer is: ovens they get a time machine and go to taps. Yesterday. You probably don't want something as heavy wait is that entire architecture, but there's a lot of thinking in the taps, architecture document that might be informative to that discussion.

P

Lukas party, with a observation based on some of the earlier discussion around the TCP fallback stuff that we agreed probably needs some work, but looking at that, some of the other talks around quite broad extension of h2 or h3, and how that interacts with something like HP alt service, in terms of detecting, well claim of being fully authoritative for that service and the alternative failing to provide the extension capabilities and how we might signal that and characterize the fallback behavior and how those things work.

P

I, don't know if anyone has an answer or how we get that. But it's something I think we might want to think about. You.

C

Know my answer to those file an issue piece but yeah thanks for saying that this is a really interesting point that we do need to keep track of.

J

Erik Kinnear from Apple I do want to reiterate that we are excited to work on some of this stuff and I. Think we've already started some of the conversations, but we've seen from the conversations here that there's a lot of overlap in terms of what people's needs are and we've already started, conversing with some of the other presenters about how we could kind of combine those down into something that works for everybody.

E

Cullen I've been involved with another effort that had a high overlap with w3c s. Several other people in this room a serious mistake that I think we made on that in our liaisons and setting up with w3c is. We did not come to agreement of whether the w3c could remove from our specifications things which the IETF felt worse.

E

Critical security features with absolutely no consideration or discussion with the ITF and I would really oppose us moving forward on joint work with the w3c without having that very clear between us at the w3c before it where I started.

B

Just a question: :: are there any particular security things that you're majorly concerned about in this? um No.

E

I, no, not at all I, just want to be clear on how we do that and I suspect that we, it will be clear to everyone. What are the security things we would care about, but I don't see big debate on that. I just need to be clear on.

H

Yeah I mean I think on the topic of 33c ITF, trying work I'm, not sure, either of those two either the two most recent protocol, / API code development efforts like sort of worked out super well like what exactly the kind of a cluster and I think we're kisi. I, guess you know TVD, but it's like 27 years old, so, like probably not like the based winner.

W

H

Push yeah fair enough, so yeah I think maybe some some thought is required. Some way.

H

I have not yet figured out to improve that situation because, like I think, like you know, you end up with pace the seems like 70 percent of personal overlap in the same rooms, but then at least at least um I think with I mean you know, obviously I'm more of an ITF person than advocacy person, but I felt, like you know that, as things got more finished enthusiasm on the ITF side for going to everything, you see an intern, gauging kind of started to wane and all those efforts and and then he's try to go a lot more disjunction between the two between the tissue groups.

H

So I think we should address about it. Didn't have that property.

B

Any any other general QA okay.

B

So the next item is just a pointer to the Charter discussion. This isn't a working group forming buff, so we're not going to get into it in a lot of detail, but.

B

There has been an ongoing discussion on the Charter on the mailing list and there is a draft charter available on github it's in David's repo. So if you have opinions on a potential charter, you can of course post to the web transported ITF mailing list or you can go to the repo and file issues and potential PRS. So I'm just going to show you where we are kind of on the Charter. But since this is in the working group forming bow, if we can't get into it too much, but just trying to whet your appetite.

B

So you can express your opinions I'm on the mailing list or in there the repo.

B

So the basic idea is to focus on client-server protocols or protocol extensions that relate to the development of this w3c web Transport API and to provide support for reliable bi-directional and you directional communications, plus the datagrams that we talked about in in origin checks, and there are three variants that are described here: protocol running over quick, which is the quick transport that Victor talked about the one running over HTTP 3, which is the HTTP 3 transport.

B

And then the fallback protocols, and then we do have some language about security issues from the above scenarios, basically relating back to the design of WebSockets. So we don't introduce some new security issues, and/or new ones, don't don't reintroduce the old ones and they'll create new ones and then there's stuff about the coordination with the w3c and on our side to develop an overview document. That's sort of what what Victor talked about.

B

Although from the comments here, we might want to also talk about operating kind of concerns as well in there and then get feedback to try to have the best possible match and as eckers said, there have been a lot of issues with that. So you want to be a little bit more specific about how it's supposed to work and then there's coordination with other groups in the IDF and then the milestones which are kind of vague and probably not worth talking about here, although you're happy to comment on them.

B

So that's the current state of the Charter proposal and please, if you have guidance for us, go to mailing lists or and/or that github repo and let us know what you think. Okay.

B

Yeah there any little clarifying things go ahead and enjoy.

X

Mia Kulemin so at one point that I'm trying to understand from a be point of view from Transport Eddie point of view is like what's actually implications for quick here, because initially the proposal was like very, very quick focus. You were proposing quick extensions and stuff, and then the proposal changed very very drastically over the last week. Basically and like this looks very much, what was presented to me today looks very much like you're only using quick, but there's actually no implications on quick itself. Yes,.

C

As far as we know, this is a use of the quick Transfer Protocol. This doesn't have any requirements on well, I, guess the only one that I see is. We would need the Datagram extension as part of quick, but we don't we're not levying any requirements on the quick working group as far as we know or on the HTTP working group, though, don't be probably conversations there, but I don't think we're changing those protocols, we're just using.

V

Lourdes Nottingham, what timing? Yes! This is mostly a transport show, but you are using HTTP. So just as I say in many places keep an eye on things. For example, I noticed a new pseudo header go by there and that's a fairly controversial thing, and we need to have a discussion about whether that's a good idea or not, because I see implementations starting to use pseudo headers, and that goes to very nasty places very quickly and.

C

Yeah, absolutely and as stated in the Charter for any standards, action would be discussed on the HTTP mailing list as well, and so especially something like this. We would bring their beak. As you say, that's where they're all the experts are and nor they have opinions.

C

Do we have any clarifying questions on that charter.

W

Any chance I could get you to change the name because it bites.

B

W

It's neither transport, nor does it have anything to do with the web. So.

C

So the the Web API from the w3c pass all to do with the web. No.

W

It doesn't but a browser API sure you could call it. The browser transport protocol and I'd be perfectly fine to find that.

H

This is the first time this week, Rory and I have agreed. This is not a good name. Let's.

C

I wouldn't call a bike shed on the name age charter, clarifying question. So let's not go down this path. More comment than a question.

C

So we're not going to like, because the working group is not forming we're, not gonna, make any binding calls, but we would like to have some so that first two will be Hobbes. The throne will be a show of hands just to gauge interest and to see if we think that this proposal is well-defined enough to warrant chartering soon and or if how much change is required before then, because from where I'm sitting it sounds like they're interested. There is interest from the community, so we're gonna go with these questions.

C

So first one is: is the web transport problem statement clear, well, scoped, solvable and useful to solve. I would like to ask for a hum in first I will ask if yet you think yes and then I will ask you to hum, if you think no does anyone want to argue? Is this hum? Well understood? Yes, okay!

C

So if you think yes to the question number one, please hum now.

C

If you think no.

T

C

C

Didn't hear much.

E

Can you guys call that for the minutes.

B

C

General take was I heard from yes. If someone know, would you please kind of just stay? Why you think know.

C

Which one of these points do, you think, is not necessarily true. I.

M

Say yes, maybe, yes, yes and I'm concerned about the maybe for well scoped in particular, I think we might want to broaden the scope. Ever-So-Slightly can can you, like specifically add details and.

C

Send this to the list, as were absolutely and I, intend to have conversations before the happens as well. Awesome thanks, so I think for the minutes mainly were being at a yes on this one. Also just relaying.

O

C

Yeses on jabber. Thank you, okay. The second question are the web transport deliverables. So there were the over overview so as in the overview document, the quick transport protocol, the HTTP 3 transport protocol and the fallback transport are those deliverables, well-defined and well understood. Yes, Ted.

Y

Ted Hardy, what you want us to do if we think only some of them are well-defined and well understood on both times.

C

So let if you the maybe did, if you think that's the case, how can you say which ones you think and then maybe we can kind of split this hum up.

Y

So once again, ten Hardy speaking just as an individual I think the relationship between web Transport, quick transport and fallback transport needs some fleshing out and and perhaps a substantial amount of it before we can say that it's well defined and well understood because it's expected to go into deployment where there's a relationship among them that may be variable and the suitability of the the fallback transport in particular may be variable and I thought you.

Y

You heard a little bit of that when people were talking about when you would fall back to two standard web sockets and what your security properties were when you were falling back, could be different from the security properties of what you got. If you didn't have to fall back and I think there's some some chance here that we can get to deliverables which are well-defined and well understood, and so I'm, not particularly fast about saying the once.

Y

You write a charter and start doing the work you won't be able to get there I think you probably will but I'm a little bit concerned about saying we're already there at Ed stay there.

C

If we were to instead say, are they well-defined and one understood now we were too safe? Are they well-defined enough to charter a working group to make sure those are well-defined? Would would that be a better question? Would that help or would that make things worse? I think.

Y

I'm gonna defer to the rest of the line to answer that, if.

H

This is definitely a clarifying question. um I understood this a nonworking forming Boff and you were asking before me. We referring questions so I'm. Looking what sense. This is not a working frame buff at this moment, but.

C

In the sense is.

B

What we would have working for and what be different, yeah I, think I think. The question here is to get a sense of the room on what portions of this Charter need a lot more work or what portions of the work items need more work to be to be clarified. So, if you can speak to that, ekor like what portion of this do, you think are less well defined or less well understood. Sure.

H

But then you're like taking hums so like again, am I like to understand where's the a defense we're.

B

H

At the home yet because we're trying to know.

B

But you've got home in the first one.

H

Here it's hit on the second one, so like so once again, I'm like in what ways. What was this different from working for me about so.

C

The are responsible ad berry is coming up to the mic.

T

This is Barry I, don't think we went through charter bashing significantly they I they wanted to show the Charter to give you an idea of what they're looking at. But the question here on number two is not: is the Charter we're proposing to the right thing? It's these things that we talked about in these presentations. Do you understand them? Are they well-defined? Is the technology we're trying to discuss well defined and well understood yeah.

B

And if not, what specifically, what.

H

Portions are no okay, but is like one possible outcome of this that the next thing we see is a draft Charter and a proposal to form the working group with no subsequent boss.

B

Not without some addressing the comments that we're hearing here, exact.

T

That would depend on what the discussion on the mailing list how the discussion on the mailing list goes. It may be that, after a bit of discussion on the mailing list, people decide that we're ready to start chartering a working group- that's not the goal of this buff, but it could be a result of the mailing list. Discussion, I, don't we have this? We have chartered many working groups without having another buff to to do that. Yeah.

H

I grew that, but um we don't this offline, but like like part of the signaling of it's not working before you bought, is the ascent to which people are expected to come and expected at Waverley in in the beating and so like. If what you do, is you run this and you like ask the home questions and you're like this? Is awesome, and then you like work so hard in the list, and you ask for information that isn't working referring buff and it's disingenuous. It's not alright.

C

H

Out of time, so if we can sure.

C

What no I want.

H

To throw other questions as well.

H

I'm I'm on I'm, not I'm, unhappy that it was advertised and I'm working for him, Botha and now he's up and that the operators, but working for him boss on so.

C

Okay, Eric, please let other people in line keep going. You'll spend like three minutes at the line and we have four minutes left and one two, three, four five, six seven people in line, please sorry I, will talk later. Do.

X

Me a cool event, so my question might imply that I'm a note to the second question, but are you talking about if the general you know having these milestones without like taking? What was presented today is starting point or are you thinking about? What was proposed today is clear and well scope. You could what at least what I understood from my clan is that there are a lot of things that need to potentially change or are very unclear, so the proposal itself is not well-defined for me, but this could be yeah.

B

Can you be more specific, please that's what we're trying to get here which portions of this Arden, or did you not understand so.

X

I mean like what you presented today is also a little bit more high-level than what's in the crafts right, so what you presented today, it makes sense to me, but like all the details in the draft like or not all of them, but a lot of the details in the draft needs much more discussion. I think I.

D

Think this is a very big question and I'm kind of surprised that HTTP to transport is not on the list, but, like I have my main question this house, this question is different from the first one.

B

Well, it's I think a question of really trying to elicit what needs more work or what is less defined. You know, given the group feedback, what what they feel you know needs to be worked on a little bit more. Alright.

D

Yeah because it sounds like those questions not really ready for the time, because we're.

C

Getting feedback then the second question is it's not. The question itself is not well defined, so we're not in it takes a second.

F

All right, Tommy, Polly, Apple, so I think that's the right decision and beyond that I mean specifically because we're saying deliverables here, I think that if you were to look at a charter with these deliverables, these are not the I granularity for deliverables. It's a bit putting the cart before the horse of this is one way of solving the problem, but we should state that we should solve these problems. That not say we will create that quick transport and the fallback transport.

F

That is a solution, but, as we've discussed, we need to talk about that, and any charter should give room for a flexible solution to does not preconceived the answer. Thank You.

G

Dominic similarly, I mean deckers point earlier that it's not clear that quick. You know there should be separate, quick transport age to be three transports. I, think that should be a decision made by the working group, not by the Charter, whether those should you have one protocol or two Thanks.

C

All right we're cutting the mic line for anyone. That's not in line right now and keys, be very brief. We're almost out of time are.

O

We proceeding with hums Chris lemon suggests, let's home, about what needs more work instead of humming about the whole list for adoption, so we're not going.

U

To have those hums today, as shown by the previous conversations yeah, not until tonight, I hummed against the first one I. What I learned here may be convinced that there's a bunch of things that we we need to work on, refining, to list those things as I see them right now. What what are the problems were trying to solve?

U

Concretely, we got close to that, but not quite the nature of the relationship between the the two standards organizations is going to be particularly difficult, and that needs to be mapped out very clearly and the way in which these things are going to be identified and managed was was also very unclear. I think some of the drafts that we're presenting on are extraordinarily unclear on those things as well.

U

K

Brian Trammell, basically what Martin said I would say: I would say that you know when this Charter comes back for another Boff or you know, discussion between um it should emphasize a bit more the overview and maybe say hey. There will also be some transport documents, one for binding, because I'm not sure the split here is correct: I'm, not sure that all of these are necessary. I'm not like the relationship among them for security is mmm-hmm and it's like yeah. It's it's it's one proposal. There are alternate things to do in this space.

K

There alternate ways to manage the stack I would focus first on getting something chartered. It gets the overview outs that everybody understand. What's going on, cuz, otherwise they'd the interests do thing is gonna, be tricky.

V

Mark Nottingham, yeah I'd agree with what Brian just said, see: I can't agree with you, it's okay, I think we could. We need to over communicate here. My concern around this is mostly around how complicated it is and how many moving parts there are. We have a history of over designing things and over engineering things, and you think we'd eventually learn from that, but somehow we never do so. Let's define the problem set, let's figure out how this is an evolution for WebSockets, rather than maybe a brand new thing and take it from there. Alright.

C

So quick show of hands, so we're not gonna take names, but just to get a sense in this space and what we've discussed. If you are interested in like reviewing these documents, please raise your hand now.

C

I'm I'd say like two dozen hands I'm seeing for the minutes. Okay, thank you so to wrap up because we're out of time I'm getting a sense that people understand the general problem statement to the general space that we're working in I'm, also getting that there is interest from the community in working on these problems.

C

However, we are not ready, we're going to need to make or put more energy into the Charter, because the current one is too specific and those specific items are not necessarily the right ones, but it really sounds like we have energy to go in this general direction and very if you have any closing comments, I do.

T

X

I was also involved in making this a nonworking, conforming buff I think the discussion right now, just like Kufa, that was maybe the right decision and I would really encourage you to put not only more work in the Charter but put more work in the extra proposal you are making here for sanitization. That.

T

Was part of what I was going to say so I don't have to say that part, so the part I do want to do is quickly. Who raise your hand if you are on the web trans mailing list right now and put your hands down. Raise your hand if you are going to join after this meeting, okay and we got somewhere so yes focus on on refining number one and getting that right on the mailing list before you think about redrafting, charter, awesome,.

C

We will see you all on the list very soon. Thank you for coming. Everyone.

A