Subject: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid)

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 19 Oct 2011 04:42:56 +0530

Harald,

In Fig 2 (Browser RTC Trapezoid), I'm getting the feel that JS/HTML
communicates with webserver directly without the involvement of browser.
Please clarify whether it is intended not to use browser  for JS.

IMO, the browser RTC trapezoid shall be 

                   +-----------+             +-----------+

                   |   RTCWeb  |  Federation |   RTCWeb  |

                   |           |  Signaling  |           |

                   |           |-------------|           |

                   |  Server   |   protocol  |  Server   |

                   |           |             |           |

                   +-----------+             +-----------+

                        /                           \

                       /                             \   RTCWeb

                      /                               \  Signaling

                     /                                 \

                    /  RTCWeb                           \

                   /   Signaling                         \

                  /                                       \

            +-----------+                           +-----------+

            |           |                           |           |

            |           |                           |           |

            |  Browser  | ------------------------- |  Browser  |

            |           |          Media path       |           |

            |           |                           |           |

            +-----------+                           +-----------+

            +-----------+                           +-----------+

            |JS/HTML/CSS|                           |JS/HTML/CSS|

            +-----------+                           +-----------+

I explained the same diagram in Fig 1 of
draft-partha-rtcweb-signaling-00. RTCWeb signaling shall be proprietary
HTTP/websocket. I'm asking this change because I'm seeing folks confuses
API vs. on-wire-protocol. Also, Please note that JS + browser is the
single system with two different modules and it shall have protocol or
API to communicate (without passing any information in the wire). Could
you please let me know in case I'm missing something.

Thanks

Partha

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Oct 2011 07:18:05 +0200

On 10/19/2011 01:12 AM, Ravindran Parthasarathi wrote:
> communicates with webserver directly without the involvement of 
> browser. Please clarify whether it is intended not to use browser  for JS.
>
Sorry, you completely lost me there.

The browser is the execution context for Javascript. The words "it is 
intended not to use browser for JS" look like English to me, but I can't 
find any interpretation that makes any sense.

If you don't have a clear view of the Javascript execution model, I 
recommend spending a few hours with an introductory Javascript text and 
playing with writing some Javascript in your own web pages. It will save 
lots of confused emails to the list.
> IMO, the browser RTC trapezoid shall be

Absolutely not.

1) The term "RTCWeb Signaling" has no clear definition, as this 
discussion has proved again.
2) The conceptual difference between the media path (managed by the 
browser without being mediated through Javascript) and the signalling 
path (mediated through Javascript, transmitted through interfaces that 
this WG has no intention of changing) is lost by the inversion of the 
"browser stack".

The detailed relationships between the browser components are better 
described in Figure 1 of -overview- than in Figure 2 (the one you've 
quoted). I've noted the need to mention that the JS uses browser 
functions to access HTTP and WebSockets too, since it's apparently not 
completely obvious to all.

> draft-partha-rtcweb-signaling-00. RTCWeb signaling shall be 
> proprietary HTTP/websocket. I'm asking this change because I'm seeing 
> folks confuses API vs. on-wire-protocol. Also, Please note that JS + 
> browser is the single system with two different modules and it shall 
> have protocol or API to communicate (without passing any information 
> in the wire). Could you please let me know in case I'm missing something.
>
> Thanks
>
> Partha
>

---

From: José Luis Millán <[email-masked]>
Date: Wed, 19 Oct 2011 08:22:38 +0200

Ravindran,

Whichever your motivation for arguing against or in favor, arguments
need to be rigorous and clear. I guess most people reading and
contributing have a deep knowledge about what is being speaking about
here.

After reading this email, it's very dificult for me understanding how
can there be so many mails from you asking for the adoption of
whichever position in this list.

> In Fig 2 (Browser RTC Trapezoid), I’m getting the feel that JS/HTML

This question (of course, questions are always legitimate) comes after
you exposed a document
(http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00) focused
on standarizing a signaling between browser and RTCWeb server.

"In the above mentioned architecture, this document focus on
   standardizing RTCWeb signaling between browser and RTCWeb server"

This is nothing personal, but this attitude makes the mailing list
hard to follow, at least.

I apologize if this comment is out of context.

2011/10/19 Harald Alvestrand <[email-masked]>:
> In Fig 2 (Browser RTC Trapezoid), I’m getting the feel that JS/HTML
> 1) The term "RTCWeb Signaling" has no clear definition, as this discussion
> has proved again.
> 2) The conceptual difference between the media path (managed by the browser
> without being mediated through Javascript) and the signalling path (mediated
> through Javascript, transmitted through interfaces that this WG has no
> intention of changing) is lost by the inversion of the "browser stack".
>
> quoted). I've noted the need to mention that the JS uses browser functions
> to access HTTP and WebSockets too, since it's apparently not completely
> obvious to all.
>
>
>
> I explained the same diagram in Fig 1 of draft-partha-rtcweb-signaling-00.
> RTCWeb signaling shall be proprietary HTTP/websocket. I’m asking this change
> because I’m seeing folks confuses API vs. on-wire-protocol. Also, Please
> note that JS + browser is the single system with two different modules and
> it shall have protocol or API to communicate (without passing any
> information in the wire). Could you please let me know in case I’m missing
> something.
>
>
>
> Thanks
>
> Partha
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 19 Oct 2011 12:01:55 +0530

Harald,

Please read inline.

Thanks

Partha

From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 10:48 AM
To: Ravindran Parthasarathi
Cc: [email-masked]
Subject: Re: Comment on draft-ietf-rtcweb-overview-02 (Browser RTC
trapezoid)

Harald,

<partha> Sorry, I messed up with the words here but you clarified it in
the below mail thread </partha>

<partha> In fact I tried couple of W3Cschools Javascript before starting
the mail thread in RTCWeb. I'll learn more terminology in Javascript to
clearly present my ideas </partha>

                   |           |  Signaling  |           |

                   |           |-------------|           |

                   |           |             |           |

                        /                           \

                       /                             \   RTCWeb

                      /                               \  Signaling

                     /                                 \

                    /  RTCWeb                           \

                   /   Signaling                         \

                  /                                       \

            |           |                           |           |

            |           |                           |           |

            |           |          Media path       |           |

            |           |                           |           |

Absolutely not.

<partha> May I need to put clear definition by which we will come to
common understanding. </partha>

<partha> Agreed and my intention is not manage media path through
Javascript. My figure has to change JS/HTML position to reflect it
correctly. </partha>

<partha> My intention of the mail is above statement and it is not clear
from the figure 1 & 2.  </partha>

Thanks

Partha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Oct 2011 21:25:07 +0200

> 1) The term "RTCWeb Signaling" has no clear definition, as this discussion

Hi Harald, I've tryed to clarify the term(s) "signaling" in RTCweb:

  http://public.aliax.net/RTCweb_Signaling_Components.html

IMHO there is general confusion about such term because we use it in
different parts of the whole RTCweb picture.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Oct 2011 21:45:00 +0200

2011/10/19 Ravindran Parthasarathi <[email-masked]>:
> <partha> In fact I tried couple of W3Cschools Javascript before starting the
> mail thread in RTCWeb. I’ll learn more terminology in Javascript to clearly
> present my ideas </partha>

Hi Ravindran, please let me understand:

You recognize that you have no knowledge of JavaScript (you started
reading some tutorials of JavaScript *yesterday*) but your draft
clearly states:

------------------------
Abstract

  [...]
  There are lots of issues in Javascript based signaling protocol.
  [...]
------------------------

And in other mail(s) you assert:

------------------------
<partha> I’m not favor Inaki solution of SIP over websocket because it
is overkill for signaling protocol. [...]</partha>
------------------------

So how should I interpret it? how can you make such assertions without
knowledge?. I don't consider that to be very polite, and for me that
means that you want to discredit proposals different than yours.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 20 Oct 2011 03:09:13 +0530

Inaki,

There are fundamentally two aspects in RTCWeb:

1) (on-wire) protocol mechanism - How protocol is designed between RTCWeb client (browser) and RTCWeb server, RTCWeb client and RTCWeb client. The protocol design does not focus on RTCWeb client only but also in RTCWeb server because the protocol has to be implemented in both entities. IOW, it is not 20 lines of JavaScript but impact of RTCWeb server design has to be noted as well. Here IETF has significant role and it has to come up with best protocol design between RTCWeb entities.

2) API design (JavaScript in browser) - Browser provides RTCWeb client framework and exposes its API as JavaScript and JavaScript is the language/script of choice for browsers. The interaction is between browser and JavaScript only. IMO, W3C plays the vital role in coming up with best API set and also, there is no on-wire stuff here. Here, the discussion focus is whether low level API or ROAP API or any other high level API. Of course, I have less experience in JavaScript based API design. Please note that I have designed and worked in protocol framework in other languages like C, TCL. 

My comment on "SIP over websocket is an overkill" is purely based on (on-wire) protocol mechanism and it is nothing do with API design. Irrespective of whether "SIP over websocket" is implemented in browser or in JavaScript or in other language, it is not the best protocol design. Hope this clarifies my stance.

Thanks
Partha

>-----Original Message-----
>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Thursday, October 20, 2011 1:15 AM
>Cc: Harald Alvestrand; [email-masked]
>Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser
>RTC trapezoid)
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 19 Oct 2011 23:54:03 +0200

Hi,

> 2) API design (JavaScript in browser) - Browser provides RTCWeb client framework and exposes its API as JavaScript and JavaScript is the language/script of choice for browsers. The interaction is b…

If point 2, the JS API is flexible enough there is no need for a new protocol design, we can reuse an existing one and use the JS API for the media layer. I've lost count on the number of times this has already been said, lets move on.

> My comment on "SIP over websocket is an overkill" is purely based on (on-wire) protocol mechanism and it is nothing do with API design. Irrespective of whether "SIP over websocket" is implemented i…

Nobody is advocating for SIP over WebSocket nor XMPP over PBTL (pigeon based transport layer), what some of us want is to let it up to the developers.

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 20 Oct 2011 03:34:43 +0530

Saul,

I have already mentioned in the mailing alias that *Please don't delete the existing mail* because we often miss the original intent of the mail and goes in the circular discussion.

My original reply was intended only to answer Inaki query on how I come to the conclusion that "I'm not favor Inaki solution of SIP over websocket because it is overkill for signaling protocol". 

Thanks
Partha

>From: Saúl Ibarra Corretgé [mailto:[email-masked]]
>Sent: Thursday, October 20, 2011 3:24 AM
>Cc: Iñaki Baz Castillo; [email-masked]
>> 1) (on-wire) protocol mechanism - How protocol is designed between
>RTCWeb client (browser) and RTCWeb server, RTCWeb client and RTCWeb
>client. The protocol design does not focus on RTCWeb client only but
>also in RTCWeb server because the protocol has to be implemented in both
>entities. IOW, it is not 20 lines of JavaScript but impact of RTCWeb
>server design has to be noted as well. Here IETF has significant role
>and it has to come up with best protocol design between RTCWeb entities.
>>
>> 2) API design (JavaScript in browser) - Browser provides RTCWeb client
>framework and exposes its API as JavaScript and JavaScript is the
>language/script of choice for browsers. The interaction is between
>browser and JavaScript only. IMO, W3C plays the vital role in coming up
>with best API set and also, there is no on-wire stuff here. Here, the
>discussion focus is whether low level API or ROAP API or any other high
>level API. Of course, I have less experience in JavaScript based API
>design. Please note that I have designed and worked in protocol
>framework in other languages like C, TCL.
>>
>
>If point 2, the JS API is flexible enough there is no need for a new
>protocol design, we can reuse an existing one and use the JS API for the
>media layer. I've lost count on the number of times this has already
>been said, lets move on.
>
>> My comment on "SIP over websocket is an overkill" is purely based on
>(on-wire) protocol mechanism and it is nothing do with API design.
>Irrespective of whether "SIP over websocket" is implemented in browser
>or in JavaScript or in other language, it is not the best protocol
>design. Hope this clarifies my stance.
>>
>
>Nobody is advocating for SIP over WebSocket nor XMPP over PBTL (pigeon
>based transport layer), what some of us want is to let it up to the
>developers.
>
>--
>Saúl Ibarra Corretgé
>AG Projects
>
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 20 Oct 2011 00:13:55 +0200

Hi,

> I have already mentioned in the mailing alias that *Please don't delete the existing mail* because we often miss the original intent of the mail and goes in the circular discussion.

I quoted all your email and *properly* replied inline, instead of top-posting. The fact that your email client is not good enough it's not my fault.

> My original reply was intended only to answer Inaki query on how I come to the conclusion that "I'm not favor Inaki solution of SIP over websocket because it is overkill for signaling protocol". 

I know how to read. I'm just saying that no one wants SIP over WebSocket as a "default protocol". It's up to developers, like Inaki, Jose in this particular case, to decide what to use. They chose SIP over WS, you may use something else.

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 20 Oct 2011 04:03:20 +0530

Saul,

I guess that you didn't get my point. In case you remove the earlier mail thread and reply inline to my last reply, the context of my reply is lost, we start discuss something which is not relevant to the original mail. 

BTW, Please note that it is nothing to do with my e-mail client or its settings.

Thanks
Partha  

>Sent: Thursday, October 20, 2011 3:44 AM
>> I have already mentioned in the mailing alias that *Please don't
>delete the existing mail* because we often miss the original intent of
>the mail and goes in the circular discussion.
>>
>
>I quoted all your email and *properly* replied inline, instead of top-
>posting. The fact that your email client is not good enough it's not my
>fault.
>
>> My original reply was intended only to answer Inaki query on how I
>come to the conclusion that "I'm not favor Inaki solution of SIP over
>websocket because it is overkill for signaling protocol".
>>
>
>I know how to read. I'm just saying that no one wants SIP over WebSocket
>as a "default protocol". It's up to developers, like Inaki, Jose in this
>particular case, to decide what to use. They chose SIP over WS, you may
>use something else.
>
>
>--
>Saúl Ibarra Corretgé
>AG Projects
>
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 20 Oct 2011 01:53:56 +0200

* Ravindran Parthasarathi wrote:
>I guess that you didn't get my point. In case you remove the earlier
>mail thread and reply inline to my last reply, the context of my reply
>is lost, we start discuss something which is not relevant to the
>original mail. 
>

According to the Netiquette Guidelines in RFC 1855 you should quote just
enough of the message to establish context but not the whole message. It
also says that follow-up content should exceed what is quoted, and that
the quoted text should appear at the top, not bottom, of your response, 
and it says lines should not exceed a low number of characters. You are
violating all these guidelines. The solution to your thread problem is
to use a mail client that lets you read the parent of a message easily.
A common solution is to let the client render the whole thread as tree
that you can navigate. I do not recall ever seeing someone who used the
correct posting style for a couple of years to suddenly switch to a very
different posting style; I doubt there is a point in asking anybody to.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 20 Oct 2011 05:53:12 +0530

The reported issue is that "the message is not complete enough to establish context" and also, the reply is irrelevant to the original mail discussion. Please see the following mail thread for details:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg02129.html 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg02130.html
http://www.ietf.org/mail-archive/web/rtcweb/current/msg02131.html

Thanks
Partha

>From: Bjoern Hoehrmann [mailto:[email-masked]]
>Sent: Thursday, October 20, 2011 5:24 AM

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2011 10:20:43 +0200

> If point 2, the JS API is flexible enough there is no need for a new protocol design, we can reuse an existing one and use the JS API for the media layer. I've lost count on the number of times thi…
I've lost count of the number of times you've said it, but I still don't 
agree.

I think we need ROAP as part of our API spec. That, too, has been 
repeated any number of times.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 20 Oct 2011 11:28:45 +0200

Hi Harald,

On Oct 20, 2011, at 10:20 AM, Harald Alvestrand wrote:

> I've lost count of the number of times you've said it, but I still don't agree.
> 
> I think we need ROAP as part of our API spec. That, too, has been repeated any number of times.
> 

Maybe I'm missing something here, but I didn't say we don't need ROAP as part of the API spec. I always spoke about the signaling plane, lets say the call control, not the media control. 

--
Saúl Ibarra Corretgé
AG Projects