Re: Towards a new charter for the WebRTC Working Group

On Mon, Jan 1, 2018 at 9:48 PM Martin Thomson <martin.thomson@gmail.com>
wrote:

> On Tue, Jan 2, 2018 at 4:26 PM, Bernard Aboba
> <Bernard.Aboba@microsoft.com> wrote:
> > Martin said:
> >
> > "What are the plans for the protocol pieces for the new items?  I
> > haven't seen any plans - or internet-drafts - for those, and the bulk
> > of the work for some of these items is protocol work.  For instance, I
> > can understand why the group might choose not to rely on SDP for
> > negotiating new features, which leads to some API work, but the bulk
> > of the QUIC datachannels work is in defining protocols, not the API."
> >
> > [BA] The QUIC API presented at TPAC depends only on currently chartered
> work in the IETF QUIC WG (e.g. the QUIC transport document) as well as
> resolution of the QUIC multiplexing problem (by whatever approach the IETF
> decides on).
> >
> > As the QUIC transport document evolves, the QUIC API will presumably
> evolve as well (e.g. the proposed API currently provides a bi-directional
> stream abstraction).
> >
> > As Peter noted, it should be possible to implement the RTCDataChannel
> API on top of the proposed QUIC API once the IETF defines the protocol for
> QUIC datachannels.
>
> That's called a protocol.  You need an ALPN label at a minimum even if
> your intent is to use QUIC more or less directly.
>

Would it be better to let the JS pick one (since it defines the protocol on
top of QUIC) or to just pick one or to leave it blank?

What is it used for that a data channel user would care about it?