Subject: [clue] Don't use CLUE data channel terminology

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jan 2014 09:06:42 +0000

Hi,

I am currently working on my material for the "CLUE data channel" presentation.

The first thing I'd like to suggest already at this point: Please let us not use "CLUE data channel" terminology. It makes thing confusing.

My suggestion is to talk about "rtcweb data channel for CLUE", "rtcweb data channel for CLUE usage", or something similar...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jan 2014 09:08:58 +0000

And, just to clarify: my statement below is based on the assumption that we are going to re-use the rtcweb data channel in CLUE.

Lähettäjä: clue [mailto:[email-masked]] Puolesta Christer Holmberg
Lähetetty: 22. tammikuuta 2014 11:07
Vastaanottaja: [email-masked]
Aihe: [clue] Don't use CLUE data channel terminology

Hi,

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Jan 2014 21:19:25 +1100

Hello Christer,

I'm abit confused... Why can't we "CLUE channel"? RTCWEB isn't the only 
application for CLUE.

Regards, Christian

On 22/01/2014 8:08 PM, Christer Holmberg wrote:
>
> And, just to clarify: my statement below is based on the assumption 
> that we are going to re-use the rtcweb data channel in CLUE.
>
> *Lähettäjä:*clue [mailto:[email-masked]] *Puolesta *Christer 
> Holmberg
> *Lähetetty:* 22. tammikuuta 2014 11:07
> *Vastaanottaja:* [email-masked]
> *Aihe:* [clue] Don't use CLUE data channel terminology
>
> Hi,
>
> I am currently working on my material for the “CLUE data channel” 
> presentation.
>
> The first thing I’d like to suggest already at this point: Please let 
> us not use “CLUE data channel” terminology. It makes thing confusing.
>
> My suggestion is to talk about “rtcweb data channel for CLUE”, “rtcweb 
> data channel for CLUE usage”, or something similar…
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Mary Barnes <[email-masked]>
Date: Wed, 22 Jan 2014 09:34:49 -0600

I did not understand that we were reusing the RTCWEB data channel.  I think
we need to think more in terms of the work that Richard Ejzak proposed for
defining a more generic model for setting up an "application" specific
SCTP/DTLS/UDP channel that was dispatched to MMUSIC WG at IETF-88:
http://www.ietf.org/proceedings/88/minutes/minutes-88-dispatch

While the original draft was focused on WebRTC, the work that was agreed to
move forward was the generic SDP procedures, which I think is what CLUE
would want to use.

I'm cc'ing Richard as I don't think he's on the list and it would be good
if we could understand the status of that work.

Mary.

On Wed, Jan 22, 2014 at 3:08 AM, Christer Holmberg <
[email-masked]> wrote:

>  And, just to clarify: my statement below is based on the assumption that
> we are going to re-use the rtcweb data channel in CLUE.
>
>
>
> *Lähettäjä:* clue [mailto:[email-masked]] *Puolesta *Christer
> Holmberg
> The first thing I’d like to suggest already at this point: Please let us
> not use “CLUE data channel” terminology. It makes thing confusing.
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jan 2014 15:39:36 +0000

Hi Christian,

The name of the data channel is “rtcweb data channel”, which in practice is a set of SCTP streams running on top of DTLS. The idea is that we will run the CLUE protocol on top of that rtcweb data channel.

Yes, it IS confusing 😊

Regards,

Christer

Sent from Windows Mail

From: Christian Groves<mailto:[email-masked]>
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎12‎:‎19‎ ‎PM
To: [email-masked]<mailto:[email-masked]>

Hello Christer,

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jan 2014 15:51:46 +0000

Hi,

The rtcweb data channel is not rtcweb application specific - they just call it that rtcweb data channel (well, they do make some assumptions, which are rtcweb:ish, but I have commented on that).

When you use the data channel, you do need to indicate the protocol running on top of it (in our case, the clue protocol). Richard's proposal allows you to do it already in SDP, while they do it inside the data channel (once established). But, I don't think there are any differences in the data channel itself, and how it's used.

Regards,

Christer

Sent from Windows Mail

From: Mary Barnes<mailto:[email-masked]>
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎5‎:‎34‎ ‎PM
To: Hans-Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

I did not understand that we were reusing the RTCWEB data channel.  I think we need to think more in terms of the work that Richard Ejzak proposed for defining a more generic model for setting up an "application" specific SCTP/DTLS/UDP channel that was dispatched to MMUSIC WG at IETF-88:
http://www.ietf.org/proceedings/88/minutes/minutes-88-dispatch

While the original draft was focused on WebRTC, the work that was agreed to move forward was the generic SDP procedures, which I think is what CLUE would want to use.

I'm cc'ing Richard as I don't think he's on the list and it would be good if we could understand the status of that work.

Mary.

On Wed, Jan 22, 2014 at 3:08 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
And, just to clarify: my statement below is based on the assumption that we are going to re-use the rtcweb data channel in CLUE.

Lähettäjä: clue [mailto:[email-masked]<mailto:[email-masked]>] Puolesta Christer Holmberg
Lähetetty: 22. tammikuuta 2014 11:07
Vastaanottaja: [email-masked]<mailto:[email-masked]>
Aihe: [clue] Don't use CLUE data channel terminology

Hi,

I am currently working on my material for the “CLUE data channel” presentation.

The first thing I’d like to suggest already at this point: Please let us not use “CLUE data channel” terminology. It makes thing confusing.

My suggestion is to talk about “rtcweb data channel for CLUE”, “rtcweb data channel for CLUE usage”, or something similar…

Regards,

Christer

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jan 2014 11:35:57 -0500

Christer,

I don't see why we should be referencing rtcweb at all when talking 
about this. We are using a channel that is defined in transport, and 
described in SDP defined in mmusic.

We do happen to be using a mechanism that has a lot in common with the 
rtcweb data channel. That is helpful both because they are doing a lot 
of the definition work for us, and because we hope this will facilitate 
making webrtc clients for clue. But much of the usage will be without 
webrtc.

Note that xxx currently uses a=webrtc-DataChannel and a=wdcsa, but I 
already commented to Richard about that, and he agreed that those names 
should be changed. (To a=DataChannel and a=csa.)

	Thanks,
	Paul

On 1/22/14 10:51 AM, Christer Holmberg wrote:
> Hi,
>
> The rtcweb data channel is not rtcweb application specific - they just
> call it that rtcweb data channel (well, they do make some assumptions,
> which are rtcweb:ish, but I have commented on that).
>
> When you use the data channel, you do need to indicate the protocol
> running on top of it (in our case, the clue protocol). Richard's
> proposal allows you to do it already in SDP, while they do it inside the
> data channel (once established). But, I don't think there are any
> differences in the data channel itself, and how it's used.
>
> Regards,
>
> Christer
>
> Sent from Windows Mail
>
> *From:* Mary Barnes <mailto:[email-masked]>
> *Sent:* ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎5‎:‎34‎ ‎PM
> *To:* Hans-Christer Holmberg <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>,
> [email-masked] <mailto:[email-masked]>
>
> I did not understand that we were reusing the RTCWEB data channel.  I
> think we need to think more in terms of the work that Richard Ejzak
> proposed for defining a more generic model for setting up an
> "application" specific SCTP/DTLS/UDP channel that was dispatched to
> MMUSIC WG at IETF-88:
> While the original draft was focused on WebRTC, the work that was agreed
> to move forward was the generic SDP procedures, which I think is what
> CLUE would want to use.
>
> I'm cc'ing Richard as I don't think he's on the list and it would be
> good if we could understand the status of that work.
>
> Mary.
>
>
> On Wed, Jan 22, 2014 at 3:08 AM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     that we are going to re-use the rtcweb data channel in CLUE.____
>
>     __ __
>
>     *Lähettäjä:*clue [mailto:[email-masked]
>     <mailto:[email-masked]>] *Puolesta *Christer Holmberg
>     *Vastaanottaja:* [email-masked] <mailto:[email-masked]>
>     *Aihe:* [clue] Don't use CLUE data channel terminology____
>
>     __ __
>
>     Hi,____
>
>     __ __
>
>     presentation.____
>     __ __
>     The first thing I’d like to suggest already at this point: Please
>     let us not use “CLUE data channel” terminology. It makes thing
>     confusing.____
>
>     __ __
>
>     My suggestion is to talk about “rtcweb data channel for CLUE”,
>     “rtcweb data channel for CLUE usage”, or something similar…____
>
>     __ __
>
>     Regards,____
>
>     __ __
>
>     Christer____
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2014 03:52:35 +0000

Hi,

> I don't see why we should be referencing rtcweb at all when talking about this. We are using a channel that is defined in transport, and described in SDP defined in mmusic.

I don't think it's not that easy.

Yes, the SCTP connection is negotiated using SDP, and the opening of SCTP streams is also done using generic mechanisms. BUT, there are procedures and semantics associated with the data channel itself that needs to be specified. So, either we re-use (if possible) what RTCWEB has done, or we need to specify it ourselves.

Of course, we can ask RTCWEB to not use "rtcweb data channel terminology", but something more generic, if CLUE also wants to use it. 

But, let's not focus on the name for the moment - let's see if their solution TECHNICALLY fulfills the CLUE needs.

> We do happen to be using a mechanism that has a lot in common with the rtcweb data channel. That is helpful both because they are doing a lot of the definition work for us, and because we hope this will facilitate making webrtc clients for clue. But much of the usage will be without webrtc.

Correct. So, if we don't want to re-use what they have done, there should be a good technical reason for that. 

I HAVE identified some issues, which seems to limit the usage to webrtc (or, even to JavaScript usage of webrtc), but I am having some off-line clarification discussions (if my issues are valid, I'll naturally bring them up on the list) with the authors regarding that. 

>Note that xxx currently uses a=webrtc-DataChannel and a=wdcsa, but I already commented to Richard about that, and he agreed that those names should be changed. (To a=DataChannel and a=csa.)

I think we shall do things step-by-step, which means we shall first determine whether we can use the "base" stuff, or whether Richard's suggested mechanism is needed.

Regards,

Christer

On 1/22/14 10:51 AM, Christer Holmberg wrote:
> proposal allows you to do it already in SDP, while they do it inside 
> the data channel (once established). But, I don't think there are any 
> [email-masked] 
> <mailto:[email-masked]>
>
> While the original draft was focused on WebRTC, the work that was 
> agreed to move forward was the generic SDP procedures, which I think 
> is what CLUE would want to use.
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2014 03:58:17 +0000

I don't think it's that easy, that is :)

-----Alkuperäinen viesti-----
Lähettäjä: clue [mailto:[email-masked]] Puolesta Christer Holmberg
Lähetetty: 24. tammikuuta 2014 5:53
Vastaanottaja: Paul Kyzivat; [email-masked]
Aihe: Re: [clue] Don't use CLUE data channel terminology

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jan 2014 11:13:43 -0500

> Yes, the SCTP connection is negotiated using SDP, and the opening of SCTP streams is also done using generic mechanisms. BUT, there are procedures and semantics associated with the data channel its…

Can you identify them?

I agree there may be such things, but IMO they are problems to be solved.

Are you talking about the abstracting up from unidirectional SCTP 
streams to bidirectional datachannels?

> Of course, we can ask RTCWEB to not use "rtcweb data channel terminology", but something more generic, if CLUE also wants to use it.

Yes - it is a matter of factoring the generic from the RTCWEB specific.
I've already been asking for that where I find the problem, such as with 
the SDP for data channels, and in MSID.

> But, let's not focus on the name for the moment - let's see if their solution TECHNICALLY fulfills the CLUE needs.

Agree.

> I HAVE identified some issues, which seems to limit the usage to webrtc (or, even to JavaScript usage of webrtc), but I am having some off-line clarification discussions (if my issues are valid, I'…

I'd be interested in hearing more about this.

> I think we shall do things step-by-step, which means we shall first determine whether we can use the "base" stuff, or whether Richard's suggested mechanism is needed.

I may be wrong, but I think the "base stuff" you are talking about (for 
creation of data channels without SDP signaling) is embedded in JSEP 
APIs. Those are only for Javascript. I don't see how we can or should be 
dependent on those.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 25 Jan 2014 01:22:26 +0000

Hi,

>> Yes, the SCTP connection is negotiated using SDP, and the opening of SCTP streams is also done using generic mechanisms. BUT, there 
>> are procedures and semantics associated with the data channel itself that needs to be specified. So, either we re-use (if possible) what RTCWEB has done, or we need to specify it ourselves.
>
> Can you identify them?

I will do that in my presentation, but basically it is about SCTP options (including the usage of two bidirectional SCTP streams, as you mention below, and the rtcweb data channel PROTOCOL which is used to open the data channel, and indicate what application (in our case: CLUE) the data channel will be used for.

I have so far found no reason why we couldn't re-use the rtcweb stuff.

> Are you talking about the abstracting up from unidirectional SCTP streams to bidirectional datachannels?

For example, yes.

> Yes - it is a matter of factoring the generic from the RTCWEB specific.

They also talk about "JavaScript strings", but it is important to note that it does NOT mandate the usage of JavaScript (that would not work for rtcweb either). 

I've already been asking for that where I find the problem, such as with the SDP for data channels, and in MSID.

Agree.

> I'd be interested in hearing more about this.

The issue which affects CLUE was regarding the JavaScript string usage. From the draft it was a little unclear to me whether it can be used by non-JS applications. But, as described above, it only refers to a string format. 

There are also other issues (or, missing text), which are not CLUE specific, which I intend to bring up on the list. For example, it is not described how the TLS roles are determined.

>>> already commented to Richard about that, and he agreed that those 
>>> names should be changed. (To a=DataChannel and a=csa.)
>>
> I may be wrong, but I think the "base stuff" you are talking about (for creation of data channels without SDP signaling) is embedded in JSEP APIs. Those are only for Javascript. I don't see how we can or should be dependent on those.

There is no requirement for the usage of the JSEP API in the IETF data channel specs. The SDP parts are generic.

Also, you DO create the data channel using SDP. The USAGE (e.g. CLUE) of the data channel is then negotiated in-band, using the rtcweb data channel protocol. But, nothing prevents us from, in ADDITION, also using Richard's draft if we want to indicate the usage in SDP. 

But, you'll hear more about this on Monday :)

Regards,

Christer

>> The rtcweb data channel is not rtcweb application specific - they 
>> just call it that rtcweb data channel (well, they do make some 
>> assumptions, which are rtcweb:ish, but I have commented on that).
>>