Subject: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 6 Oct 2015 07:47:11 +0000

Dear All,

like too remind that there are three first WebRTC data channel applications, 
1) MSRP based instant messaging, 
2) T.140 based text conversation and
3) BFCP based floor control within a WebRTC conference service.

draft-ietf-mmusic-msrp-usage-data-channel was/is the precedent for getting a common understanding about application protocol specific SDP usage (on top of the generic control of a DC).
The discussion and protocol design are fairly mature in the meanwhile, hence it is time to start the work on the two other applications.
We've prepared initial drafts, derived from the "MSRP draft", see:

T.140 Text Conversation over Data Channels
draft-schwarz-mmusic-t140-usage-data-channel-02.txt

BFCP floor control signalling over Data Channels
draft-schwarz-mmusic-bfcp-usage-data-channel-01.txt

We'd like to request MMUSIC for adoption of these drafts.

Regards,
Albrecht

Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

Juergen Stoetzer-Bradler <[email-masked]> Wed, 09 September 2015 14:45 UTCShow header

Hello,

Version 02 of draft-ietf-mmusic-msrp-usage-data-channel addresses Christian's comments to version 01,
http://www.ietf.org/mail-archive/web/mmusic/current/msg14537.html,
except for the "setup" attribute related one.

We'll come back regarding the SDP setup attribute, which can be part of an MSRP over data channel
related SDP media description as media level "a=setup" attribute and/or as MSRP sub-protocol specific
attribute "a=dcsa:x setup".

Thanks,
Juergen

On 09.09.2015 16:33, [email-masked] wrote:
> A new version of I-D, draft-ietf-mmusic-msrp-usage-data-channel-02.txt
> has been successfully submitted by Juergen Stoetzer-Bradler and posted to the
> IETF repository.
>
> Name:		draft-ietf-mmusic-msrp-usage-data-channel
> Revision:	02
> Title:		MSRP over Data Channels
> Document date:	2015-09-09
> Group:		mmusic
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-mmusic-msrp-usage-data-channel-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-02
>
> Abstract:
>     This document specifies how the Message Session Relay Protocol (MSRP)
>     can be instantiated as a data channel sub-protocol, using the SDP
>     offer/answer exchange-based generic data channel negotiation
>     framework.  Two network configurations are documented: a WebRTC end-
>     to-end configuration (connecting two MSRP over data channel
>     endpoints), and a gateway configuration (connecting an MSRP over data
>     channel endpoint with an MSRP over TCP endpoint).
>
>                                                                                    
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 6 Oct 2015 10:25:26 -0400

This motivates me to ask a question:

How do we decide that an existing protocol should be extended to work 
using a data channel as its transport?

Do we just do it for every protocol we can think of that could work that 
way?

Note that many protocols that could run over a data channel could also 
run over a websocket transport. Should we define all of those too?

(One "answer" to why we should define things over data channel is that 
this is a path to make them usable from webrtc clients. But such clients 
can also use websockets.)

	Thanks,
	Paul

On 10/6/15 3:47 AM, Schwarz, Albrecht (Albrecht) wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 6 Oct 2015 15:31:15 +0000

My understanding:
The websocket based transport would lead to separate, self contained TCP connections, hence in opposition to the goal in minimizing the number of L4 connections for a WebRTC call.

There might be many, but not "infinite" IP application protocols as candidates for a WebRTC data service, given the "RTC character" and conversational service category.

That set of IP application protocols might be divided in two classes: a) generic and b) application-specific protocols from SDP perspective. Preferably, the majority would belong to (a). Unfortunately, the first three are of type (b).

Paul, don't got a general view / answer on your question.

Regards,
Albrecht

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Dienstag, 6. Oktober 2015 16:25
To: [email-masked]
Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

How do we decide that an existing protocol should be extended to work using a data channel as its transport?

Do we just do it for every protocol we can think of that could work that way?

Note that many protocols that could run over a data channel could also run over a websocket transport. Should we define all of those too?

(One "answer" to why we should define things over data channel is that this is a path to make them usable from webrtc clients. But such clients can also use websockets.)

	Thanks,
	Paul

On 10/6/15 3:47 AM, Schwarz, Albrecht (Albrecht) wrote:
> Re: [MMUSIC] New Version Notification for 
> draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>
> Juergen Stoetzer-Bradler <[email-masked]> 
> Wed, 09 September 2015 14:45 UTCShow header
>
> Hello,
>
> We'll come back regarding the SDP setup attribute, which can be part 
> of an MSRP over data channel related SDP media description as media 
> level "a=setup" attribute and/or as MSRP sub-protocol specific attribute "a=dcsa:x setup".
>
> Thanks,
> Juergen
>
>> A new version of I-D, 
>> draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>> has been successfully submitted by Juergen Stoetzer-Bradler and 
>> posted to the IETF repository.
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 6 Oct 2015 13:29:42 -0400

> There might be many, but not "infinite" IP application protocols as candidates for a WebRTC data service, given the "RTC character" and conversational service category.

This isn't just about webrtc.

I wanted to see the data channel spec made less webrtc-centric. It is 
certainly suitable for use in cases when webrtc isn't involved. (The 
data channel sdp draft is part of making that so.)

For instance CLUE is using a data channel. Many uses of clue won't 
involve webrtc at all.

An advantage of defining more protocols over data channels is that then 
an application can use several of them over a single connection.

But I find it interesting to see T140 defined this way, since T140 over 
RTP could be bundled with other media streams. That is another reason to 
try to rationalize the criteria for doing this.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 6 Oct 2015 13:58:43 -0400

On Tue, Oct 6, 2015 at 10:25 AM, Paul Kyzivat <[email-masked]> wrote:

> Note that many protocols that could run over a data channel could also run
> over a websocket transport. Should we define all of those too?
>

One criteria would be that this protocol would benefit from peer-to-peer
support. Websockets protocol is client to server only, while data channel
supports both peer-to-peer and client to server. Another criteria would be
if the protocol can be negatively affected by front of the line blocking or
only requires unreliable messaging. T140 seems like the perfect example
where the protocol would benefit if it is transmitted over data channel vs
websocket.
_____________
Roman Shpount

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Oct 2015 18:24:03 -0400

Hi Albrecht

In order for the WG to take on additional work and specific drafts, we 
generally require an expressed interest and support from the WG. We 
haven't seen a lot of that so far on these two drafts, so you may want 
to try and garner some additional interest and demonstrate that on the 
list and/or in the upcoming meeting (let us know if you would like 
agenda time to discuss these).

Thanks

-- Flemming (as MMUSIC chair)

On 10/6/15 3:47 AM, Schwarz, Albrecht (Albrecht) wrote:
> .

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Oct 2015 07:26:25 +0000

Hi,

Does a new data channel usage require an RFC???

If someone wants to specify a data channel protocol X, they should be able to do so without having to gather interest in IETF.

Now, in THIS specific case we are talking about MSRP, so maybe it makes sense to publish an RFC.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Flemming Andreasen<mailto:[email-masked]>
Sent: ‎16/‎10/‎2015 01:23
To: Schwarz, Albrecht (Albrecht)<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

Hi Albrecht

Thanks

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Fri, 16 Oct 2015 09:43:49 +0000

> Now, in THIS specific case we are talking about MSRP, so maybe it makes sense to publish an RFC.

This email thread is about T.140 and BFCP, not MSRP! The MSRP draft is already adopted by the WG.

From: Christer Holmberg [mailto:[email-masked]]
Sent: Freitag, 16. Oktober 2015 09:26
To: Flemming Andreasen; Schwarz, Albrecht (Albrecht); [email-masked]
Subject: RE: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

Hi,

Regards,

Christer

Thanks

On 10/6/15 3:47 AM, Schwarz, Albrecht (Albrecht) wrote:
> Juergen Stoetzer-Bradler <[email-masked]<mailto:[email-masked]>> Wed, 09 September 2015 14:45 UTCShow header
>
> Hello,
>
> On 09.09.2015 16:33, [email-masked]<mailto:[email-masked]> wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Oct 2015 09:50:51 +0000

Sorry - my mistake. But, my comment applies to BFCP too.

I see no reason why IETF should work on a T.140 draft however - unless there are lots of people who want to do it (which I doubt).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Schwarz, Albrecht (Albrecht)<mailto:[email-masked]>
Sent: ‎16/‎10/‎2015 12:43
To: Christer Holmberg<mailto:[email-masked]>; Flemming Andreasen<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

Hi,

Regards,

Christer

Thanks

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 14:11:37 -0400

On 10/16/15 5:50 AM, Christer Holmberg wrote:
> I see no reason why IETF should work on a T.140 draft however - unless
> there are lots of people who want to do it (which I doubt).

IIUC, WebRTC doesn't support T.140 (because it is not audio or video). 
But it could support T.140 over data channel. So that is a motivation 
for doing the work.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> From: Schwarz, Albrecht (Albrecht)
> <mailto:[email-masked]>
> To: Christer Holmberg <mailto:[email-masked]>; Flemming
> Andreasen <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> Subject: RE: [MMUSIC] WG adoption of other WebRTC data channel usage
> drafts?; Re: New Version Notification for
> *From:*Christer Holmberg [mailto:[email-masked]]
> *Sent:* Freitag, 16. Oktober 2015 09:26
> *To:* Flemming Andreasen; Schwarz, Albrecht (Albrecht); [email-masked]
> *Subject:* RE: [MMUSIC] WG adoption of other WebRTC data channel usage
> drafts?; Re: New Version Notification for
> If someone wants to specify a data channel protocol X, they should be
> able to do so without having to gather interest in IETF.
>
> ------------------------------------------------------------------------
>
> *From: *Flemming Andreasen <mailto:[email-masked]>
> *Sent: *‎16/‎10/‎2015 01:23
> *To: *Schwarz, Albrecht (Albrecht)
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Subject: *Re: [MMUSIC] WG adoption of other WebRTC data channel usage
> drafts?; Re: New Version Notification for
>> Juergen Stoetzer-Bradler <[email-masked]
> <mailto:[email-masked]>> Wed, 09 September
> 2015 14:45 UTCShow header
>>
>> Hello,
>>
>> On 09.09.2015 16:33,[email-masked] <mailto:[email-masked]> wrote:
>>> URL:https://www.ietf.org/internet-drafts/draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>>> Status:https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/
>>> Htmlized:https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-02
>>> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-02
>>>
>>> Abstract:
>>[email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Oct 2015 19:10:43 +0000

Hi Paul,

I do agree that the data channel could be used for t.140, and I support the work to be done.

My point was the the work doesn't necessarily have to be done in IETF, does it? Or, is an RFC required for data channel usages?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎16/‎10/‎2015 21:11
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 16:09:16 -0400

On 10/16/15 3:10 PM, Christer Holmberg wrote:
> My point was the the work doesn't necessarily have to be done in IETF,
> does it?

I suppose not, if there is another place. But IIUC T.140 over RTP is 
defined in the IETF, and the protocol work for WebRTC is done in the 
ietf, so it seems logical to me that T.140 over data channel also be 
done in ietf.

> Or, is an RFC required for data channel usages?

I don't know. Probably not.

	Thanks,
	Paul

> From: Paul Kyzivat <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 16 Oct 2015 22:31:34 +0200

In my view:

The subprotocol specifications are equally needed as the traditional RTP 
payload specifications.

There is a need to register subprotocol identifiers with IANA, and that 
is usually done through an RFC.

SDP parameters, SCTP channel characteristics, error handling, and even 
mapping to RTP transport for use in traditional SIP, all these are 
natural parts of a data channel subprotocol spec. I cannot see any more 
natural place to do this than in IETF as a RFC.  Then we have it in a 
recognized international place that can be referenced from IETF and 
other organizations such as 3GPP, W3C etc.

This is valid for the T.140 in data channel and at least its mapping to 
RFC 4103. It is probably valid for most other subchannel specifications 
that will follow.

/Gunnar

Den 2015-10-16 kl. 22:09, skrev Paul Kyzivat:
>>>> draft-ietf-mmusic-msrp-usage-data-channel was/is the precedent for 
>>>> getting a common understanding about application protocol specific 
>>>> SDP usage (on top of the generic control of a DC).
>>>> The discussion and protocol design are fairly mature in the 
>>>> meanwhile, hence it is time to start the work on the two other 
>>>> applications.
>>>>> submission

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Oct 2015 13:48:02 -0700

On Fri, Oct 16, 2015 at 1:31 PM, Gunnar Hellström <
[email-masked]> wrote:

> There is a need to register subprotocol identifiers with IANA, and that is
> usually done through an RFC.
>
>
​Just so we're clear, you mean the sctp payload protocol identifiers?  If
that's the case the registry is here:

http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-25

and registration is listed as first come, first served. While it is
possible that a specific item be registered, RFC 4960 says:

   The upper layer, i.e., the SCTP user, SHOULD standardize any specific
   protocol identifier with IANA if it is so desired.  The use of any
   specific payload protocol identifier is out of the scope of SCTP.

​So there will no doubt be cases where it is not registered.

regards,

Ted

> mapping to RTP transport for use in traditional SIP, all these are natural
> parts of a data channel subprotocol spec. I cannot see any more natural
> place to do this than in IETF as a RFC.  Then we have it in a recognized
> international place that can be referenced from IETF and other
> organizations such as 3GPP, W3C etc.
>
>> defined in the IETF, and the protocol work for WebRTC is done in the ietf,
>> so it seems logical to me that T.140 over data channel also be done in ietf.
>>
>>>>  Now, in THIS specific case we are talking about MSRP, so maybe it
>>>>>
>>>> makes sense to publish an RFC.
>>>>
>>>>> getting a common understanding about application protocol specific SDP
>>>>> usage (on top of the generic control of a DC).
>>>>> The discussion and protocol design are fairly mature in the meanwhile,
>>>>> hence it is time to start the work on the two other applications.
>>>>> of an MSRP over data channel
>>>>>> URL:
>>>>>> https://www.ietf.org/internet-drafts/draft-ietf-mmusic-msrp-usage-data-channel-02.txt
>>>>>> Status:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/
>>>>>> Htmlized:
>>>>>> https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-02
>>>>>> Diff:
>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-02
>>>>>>
>>>>>> Abstract:

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 17 Oct 2015 00:21:44 +0200

Den 2015-10-16 kl. 22:48, skrev Ted Hardie:
> On Fri, Oct 16, 2015 at 1:31 PM, Gunnar Hellström 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     In my view:
>
>     The subprotocol specifications are equally needed as the
>     traditional RTP payload specifications.
>
>     There is a need to register subprotocol identifiers with IANA, and
>     that is usually done through an RFC.
>
>
> ​ Just so we're clear, you mean the sctp payload protocol 
> identifiers?  If that's the case the registry is here:
>
Yes, but it is useful to use sdpneg to tell the other party what 
protocol you want to use.

It seems to me that the subprotocol is not the same as the STCP payload 
protocol identifier.
This is the logic I have traced:

In draft-schwarz-mmusic-t140-usage-data-channel,   a subprotocol = 
"t140"  parameter of dcmap is specified to be declared in
draft-ietf-mmusic-data-channel-sdpneg

The IANA considerations are as yet empty.

In draft-ietf-mmusic-data-channel-sdpneg  5.1.1.5, it is said about the 
subprotocol parameter of dcmap

This parameter maps to the
    'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol].
    Section 8.1 specifies how new subprotocol parameter values are
    registered.

Section 8.1 of sdpneg says:

  Registration of new subprotocol identifiers is performed using the
    existing IANA table "WebSocket Subprotocol Name Registry".

    The following text should be added following the title of the table.
    "This table also includes subprotocol identifiers specified for usage
    within a WebRTC data channel."

In ietf-rtcweb-data-protocol, it is said:

Protocol: Variable Length (sequence of characters)
       If this is an empty string the protocol is unspecified.  If it is
       a non-empty string, it specifies a protocol registered in the

       'WebSocket Subprotocol Name Registry' created in [RFC6455 <https://tools.ietf.org/html/rfc6455>].

So, that matches the information in sdpneg.

But I can not really see that it also would map to the SCTP Payload 
Protocol Identifier.

rtcweb-data-protocol mentions its own use of a SCTP Payload Protocol 
Identifier "WebRTC DCEP" for opening the channel, but not that it would 
then be the same as the subprotocol when data is transferred.

And ietf-data-channel    says in 6.6 that when data is transferred, then 
the 4 defined STCP Payload Protocol Identifiers ( named WebRTC string 
etc. ) MUST be used.

Conclusion, subprotocol is not the same as STCP Payload Protocol 
Identifier.

/Gunnar

>
> regards,
>
> Ted
>
>
>     SDP parameters, SCTP channel characteristics, error handling, and
>     even mapping to RTP transport for use in traditional SIP, all
>     these are natural parts of a data channel subprotocol spec. I
>     cannot see any more natural place to do this than in IETF as a
>     RFC.  Then we have it in a recognized international place that can
>     be referenced from IETF and other organizations such as 3GPP, W3C etc.
>
>     This is valid for the T.140 in data channel and at least its
>     mapping to RFC 4103. It is probably valid for most other
>     subchannel specifications that will follow.
>
>     /Gunnar
>
>
>             I do agree that the data channel could be used for t.140,
>             and I support
>             the work to be done.
>
>         I suppose not, if there is another place. But IIUC T.140 over
>         RTP is defined in the IETF, and the protocol work for WebRTC
>         is done in the ietf, so it seems logical to me that T.140 over
>         data channel also be done in ietf.
>
>             From: Paul Kyzivat <mailto:[email-masked]
>             <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>
>                 To: Christer Holmberg
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>; Flemming
>                 Andreasen <mailto:[email-masked]
>                 <mailto:[email-masked]>>; [email-masked]
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                 This email thread is about T.140 and BFCP, not MSRP!
>                 The MSRP draft is
>                 already adopted by the WG.
>
>                 *From:*Christer Holmberg
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                 *To:* Flemming Andreasen; Schwarz, Albrecht
>                 (Albrecht); [email-masked] <mailto:[email-masked]>
>                 Now, in THIS specific case we are talking about MSRP,
>                 so maybe it makes
>                 sense to publish an RFC.
>
>                 Regards,
>
>                 Christer
>
>                 *From: *Flemming Andreasen <mailto:[email-masked]
>                 <mailto:[email-masked]>>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>;
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                     draft-ietf-mmusic-msrp-usage-data-channel was/is
>                     the precedent for getting a common understanding
>                     about application protocol specific SDP usage (on
>                     top of the generic control of a DC).
>                     The discussion and protocol design are fairly
>                     mature in the meanwhile, hence it is time to start
>                     the work on the two other applications.
>                     Juergen Stoetzer-Bradler
>                     <[email-masked]
>                     <mailto:[email-masked]>
>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>>
>                 Wed, 09 September
>                     Version 02 of
>                     draft-ietf-mmusic-msrp-usage-data-channel
>                     addresses Christian's comments to version 01,
>                     We'll come back regarding the SDP setup attribute,
>                     which can be part of an MSRP over data channel
>                     related SDP media description as media level
>                     "a=setup" attribute and/or as MSRP sub-protocol
>                     specific
>                     On 09.09.2015 16:33,[email-masked]
>                     <mailto:[email-masked]>
>                     <mailto:[email-masked]
>                     <mailto:[email-masked]>> wrote:
>
>                         A new version of I-D,
>                         until the htmlized version and diff are
>                         available at tools.ietf.org
>                         <http://tools.ietf.org>.
>
>                         The IETF Secretariat
>
>                     <mailto:[email-masked] <mailto:[email-masked]>>
>                 <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Oct 2015 15:39:37 -0700

On Fri, Oct 16, 2015 at 3:21 PM, Gunnar Hellström <
[email-masked]> wrote:

>
> Yes, but it is useful to use sdpneg to tell the other party what protocol
> you want to use.
>
>
​I think this is where the confusion lies.  My understanding from Paul's
message was that he felt that WebRTC endpoints could exchange real time
text over a data channel, using T.140​.  In 4103 terms, I thought that
meant sending text/t140 in RTP payload format (that is, one "T140block" per
payload). I believe you could do this just using SCTP payload protocol
identifiers.  Any webrtc endpoint that received that would then send it off
to whatever is listed in its media types handler registry as owning T.140
(if there is one).

Presuming that this data channel is being negotiated between two clients
both of which share the same javascript application, you could also assume
that they negotiated it because they could handle the media type
themselves.  That case isn't very different from the subprotocol case it's
simply that it's a default rather than a named subprotocol.

I note that if you go the sub-protocol route, your T.140 data channel will
only get used if exactly the same sub-protocol is used (chat.example.com
won't be able to talk to chat.example.org), even if both could handle the
T.140 media type in RTP payload format.

regards,

Ted

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Oct 2015 11:27:30 -0400

On 10/16/15 4:48 PM, Ted Hardie wrote:
>     The subprotocol specifications are equally needed as the traditional
>     RTP payload specifications.
>
> ​Just so we're clear, you mean the sctp payload protocol identifiers?
> If that's the case the registry is here:
>

No. Data channels are restricted to using 3 PPIDs, to distinguish DCEP 
messages from UTF8 data from binary data. They aren't exposed at all in 
some APIs.

Ratherm this is about the channel protocol name. It is best described in 
the dcep spec (draft-ietf-rtcweb-data-protocol). This reuses the 
websocket protocol names registry 
(http://www.iana.org/assignments/websocket/websocket.xhtml). And that 
registry is FCFS. So an RFC is not needed.

	Thanks,
	Paul

>     even mapping to RTP transport for use in traditional SIP, all these
>     are natural parts of a data channel subprotocol spec. I cannot see
>     any more natural place to do this than in IETF as a RFC.  Then we
>     have it in a recognized international place that can be referenced
>     from IETF and other organizations such as 3GPP, W3C etc.
>
>     This is valid for the T.140 in data channel and at least its mapping
>     to RFC 4103. It is probably valid for most other subchannel
>     specifications that will follow.
>
>     /Gunnar
>
>
>         RTP is defined in the IETF, and the protocol work for WebRTC is
>         done in the ietf, so it seems logical to me that T.140 over data
>         channel also be done in ietf.
>
>                 This email thread is about T.140 and BFCP, not MSRP! The
>                 MSRP draft is
>                 *To:* Flemming Andreasen; Schwarz, Albrecht (Albrecht);
>                 Now, in THIS specific case we are talking about MSRP, so
>                 maybe it makes
>                 sense to publish an RFC.
>
>                 Regards,
>
>                 Christer
>
>                     draft-ietf-mmusic-msrp-usage-data-channel was/is the
>                     precedent for getting a common understanding about
>                     application protocol specific SDP usage (on top of
>                     the generic control of a DC).
>                     The discussion and protocol design are fairly mature
>                     in the meanwhile, hence it is time to start the work
>                     on the two other applications.
>                     draft-ietf-mmusic-msrp-usage-data-channel addresses
>                     Christian's comments to version 01,
>                     "a=setup" attribute and/or as MSRP sub-protocol specific
>                         available at tools.ietf.org <http://tools.ietf.org>.
>
>                         The IETF Secretariat
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 17 Oct 2015 11:35:20 -0400

On 10/16/15 6:39 PM, Ted Hardie wrote:
> On Fri, Oct 16, 2015 at 3:21 PM, Gunnar Hellström
> text over a data channel, using T.140​.

Yes, that was my thought. More or less. I haven't thought through the 
details.

> In 4103 terms, I thought that
> meant sending text/t140 in RTP payload format (that is, one "T140block"
> per payload). I believe you could do this just using SCTP payload
> protocol identifiers.

If you were using SCTP natively then you could do that.
If you are using *data channels* then you can't use PPIDs for that. 
Instead, you need to negotiate the protocol when you open the channel, 
using the protocol name.

For webrtc browser apps this appears to be the only option.

> Any webrtc endpoint that received that would then
> send it off to whatever is listed in its media types handler registry as
> owning T.140 (if there is one).

Again, IIUC, webrtc should upset by any PPID other than the three 
defined for use with data channels.

So I think what is needed is to register a protocol name for T.140 (or 
for RTT). While no spec is required to register the name, one is needed 
to specify the semantics of the messages sent in that protocol. If it 
follows T.140 then it might be a very simple document.

	Thanks,
	Paul

> both of which share the same javascript application, you could also
> assume that they negotiated it because they could handle the media type
> themselves.  That case isn't very different from the subprotocol case
> it's simply that it's a default rather than a named subprotocol.
>
> I note that if you go the sub-protocol route, your T.140 data channel
> will only get used if exactly the same sub-protocol is used
> (chat.example.com <http://chat.example.com> won't be able to talk to
> chat.example.org <http://chat.example.org>), even if both could handle
> the T.140 media type in RTP payload format.
>
> regards,
>
> Ted
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 18 Oct 2015 12:44:33 +0000

Hi,

...

> So I think what is needed is to register a protocol name for T.140 (or for RTT). While no spec is required to register the 
> name, one is needed to specify the semantics of the messages sent in that protocol. If it follows T.140 then it might 
> be a very simple document.

For T.140 a specification makes sense, in order to ensure interoperability.

But, what if company wants to use the data channel for a protocol related to a game? In order to avoid name collisions it would be good for them to register the name, but I don't think they would want to reveal the details of the game protocol.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 18 Oct 2015 16:02:43 +0200

> For T.140 a specification makes sense, in order to ensure interoperability.
Agreed, e.g. one provider creates a gateway to SIP and another a WebRTC 
communication app, then it is good to indicate the protocol, and also 
have the common standard for how the transmission is done, e.g. media 
coding, error handling etc, even if it is straightforward.
> But, what if company wants to use the data channel for a protocol related to a game? In order to avoid name collisions it would be good for them to register the name, but I don't think they would w…
It seems that you can leave the subprotocol field empty and use a label 
instead as an internal indication within the private system about what 
the channel is intended for.  ( or any out-of-band agreement )

/Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 18 Oct 2015 12:54:31 -0400

> But, what if company wants to use the data channel for a protocol related to a game? In order to avoid name collisions it would be good for them to register the name, but I don't think they would w…

Well, the registry exists, and is FCFS. Each registry entry contains a 
reference to a document. So there needs to be *something* to reference. 
I haven't investigated if there is any requirement on what it contains. 
And I don't think there are any police that check up on whether the 
referenced document continues to exist.

So, if you want to register a secret protocol you can probably do so.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 20 Oct 2015 14:17:53 +0000

There are several things one may want to do.

1)	Register the protocol name. We had a previous discussion on this where I think we agreed that we would use the same registry as the websocket. That registry is first come first served, and as such, formally does not even need a reference specification, only a contact. By the reuse, we are also not defining whether the appropriate usage is for websocket, datachannel, or both - one would need to communication with the contact or use any referenced specification to identify that.

2)	Give guidance on how this data channel is used to support this protocol. This does not have to be an RFC, but we have plenty of cases in the IETF where we have a non-IETF protocol with the supporting infrastructure defined by IETF. Take numerous payload documents for example. Part of that would also state that a data channel usage is appropriate, see 1) above.

3)	Give guidance or even normative statements on how various SDP attributes are placed within the dcsa attribute, or even whether they are required or not.

Whether these are done in a RFC, or in a specification from another group, or even proprietary documentation, depends on what interest there is in creating documentation and where. Essentially the basic IETF rule should apply; if there is a group of people interested in working on a specification to become an RFC, and it is in the general spirit of the IETF to do so, then work should proceed.

Regards

Keith

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 18 October 2015 17:55
To: Christer Holmberg; [email-masked]
Subject: Re: [MMUSIC] WG adoption of other WebRTC data channel usage drafts?; Re: New Version Notification for draft-ietf-mmusic-msrp-usage-data-channel-02.txt

On 10/18/15 8:44 AM, Christer Holmberg wrote:
> Hi,
>
> ...
>
>> So I think what is needed is to register a protocol name for T.140 
>> (or for RTT). While no spec is required to register the name, one is 
>> needed to specify the semantics of the messages sent in that protocol. If it follows T.140 then it might be a very simple document.
>

Well, the registry exists, and is FCFS. Each registry entry contains a reference to a document. So there needs to be *something* to reference. 
I haven't investigated if there is any requirement on what it contains. 
And I don't think there are any police that check up on whether the referenced document continues to exist.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 21 Oct 2015 18:13:29 +0200

Also BFCP is an IETF protocol so it would make sense to do it here.

Regards, Christian

On 16/10/2015 10:09 PM, Paul Kyzivat wrote:
>>>> <mailto:[email-masked]> wrote:
>>>>> A new version of I-D,