Re: [QUIC] Where does this effort stand wrt webrtc data channels?

Thanks Ted.

I think I get it, that this is really starting on optimization of 
http(s), and so that dominates the engineering decisions. Any functional 
equivalence to data channels is entirely coincidental.

	Thanks,
	Paul

On 5/7/16 9:24 PM, Ted Hardie wrote:
> Hi Paul,
>
> The BoF request is in TRAC now.  The mailing list request went in first,
> so the BoF request could include the mailing list information. As a
> result, the mailng list got announced before the BoF request was posted;
> sorry for any confusion from the race condition. The URL, for your
> convenience, is:
>
> https://tools.ietf.org/bof/trac/
>
> On Sat, May 7, 2016 at 7:47 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
> <mailto:pkyzivat@alum.mit.edu>> wrote:
>
>     I just found the announcement of this list, and it raised more
>     questions than answers. If this were a wg list then I could look at
>     the charter to get an idea of what it is about, but it seems there
>     is nothing.
>
>     The announcement says:
>
>         QUIC is a UDP-based transport protocol that provides multiplexed
>         streams over an encrypted transport. While QUIC has been described
>         externally in the context of an HTTP-focused deployment, this
>         mailing
>         list will discuss standardizing QUIC’s core transport protocol and
>         separately specify the mapping of the transport protocol to the
>         facilities of TLS. An additional work item of will be to
>         describe how
>         to map specific application semantics onto the transport,
>         starting with
>         the semantics of HTTP/2
>
>
>     ISTM the webrtc data channel mechanism, using SCTP over DTLS over
>     UDP, satisfies the description of what this is looking for.
>
>     I'm sure the organizers here are aware of that, so there must be
>     some reason for discussing something that is presumably different.
>
>
> QUIC is an existing protocol, see
> https://tools.ietf.org/html/draft-tsvwg-quic-protocol-02  for a
> description.  As you'll see from the BoF description, the proposal is to
> split the current omnibus description into multiple pieces, so that the
> core transport protocol can be used in systems that aren't based on
> HTTP/2 semantics.
>
>
>     Can somebody explain the thinking here?
>
> I hope that gave some context,
>
> regards,
>
> Ted
>
>
>             Thanks,
>             Paul
>
>     _______________________________________________
>     QUIC mailing list
>     QUIC@ietf.org <mailto:QUIC@ietf.org>
>     https://www.ietf.org/mailman/listinfo/quic
>
>