[RTW] Draft new: draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements)
Rosenberg, Jonathan
jonathan.rosenberg at skype.net
Sun Mar 13 15:20:24 CET 2011
Just the media plane protocols. See figure 2 of
http://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-framework/.
-Jonathan R.
Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen
Skype Chief Technology Strategist
jdrosen at skype.net http://www.skype.com
jdrosen at jdrosen.net http://www.jdrosen.net
-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
Sent: Sunday, March 13, 2011 4:18 AM
To: Jonathan Rosenberg; Harald Alvestrand
Cc: Ted Hardie; rtc-web at alvestrand.no
Subject: RE: [RTW] Draft new: draft-holmberg-rtcweb-ucreqs-00 (Web
Real-Time Communication Use-cases and Requirements)
Hi Jonathan,
Just to clarify, in your picture, where it says "Real-Time Protocols",
does that also cover session control and codec negotiation (e.g. SIP/SDP,
for using familiar terms), or only media plane protocols (e.g RTP, STUN)?
Regards,
Christer
________________________________________
From: Jonathan Rosenberg [jonathan.rosenberg at skype.net]
Sent: Saturday, March 12, 2011 7:47 PM
To: Harald Alvestrand; Christer Holmberg
Cc: Ted Hardie; rtc-web at alvestrand.no
Subject: Re: [RTW] Draft new: draft-holmberg-rtcweb-ucreqs-00 (Web
Real-Time Communication Use-cases and Requirements)
I believe the browser model is fundamentally different than the downloaded
application case, and it has everything to do with the trust model. The
problem we are solving for, is how to enable real-time communications when
the raw communications capability is provided by one component (the
browser), and that component is controlled by another, separate, untrusted
component (the web application). Pictorially, we're trying to solve the
following system problem:
Please view in a fixed-width font such as Monaco or Courier.
+------------+ +------------+
| | | |
| | | |
| App | | Browser |
| | ------------> | |
| | Control | |
| | "Protocol" | |
+------------+ +------------+
|
| Real-Time
| Protocols
|
|
|
V
What is the design of the "protocol" (which is really the API within the
browser itself) and what is the design of the real-time protocols emitted
by the browser, so that the untrusted application (from the perspective of
the browser) can create real-time comms features for users. I find it
illustrative to think of the browser API as a protocol since it helps
clarify the lack of trust and clearly shows that these two components are
owned and controlled by different entities.
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen
Skype Chief Technology Strategist
jdrosen at skype.net http://www.skype.com
jdrosen at jdrosen.net http://www.jdrosen.net
On 3/8/11 3:34 PM, "Harald Alvestrand" <harald at alvestrand.no> wrote:
>On 03/08/11 14:08, Christer Holmberg wrote:
>> Hi Ted,
>>
>> Our understanding, based on the discussions regarding the charter, is
>>that the working group will focus on the browser, with the purpose being
>>to ensure alignment with the work in W3C.
>>
>> Therefore our focus has been on browser based applications, and we
>>haven't really considered native applications.
>>
>> If that is unclear in the draft, we can clarify it in the next version.
>One nice feature of the doc is that it has a few different use cases
>that don't strictly use web browsers - in particular, the talent scout
>of section 4.6.1 uses an app on a smartphone while his manager uses a
>desktop PC (presumably with a browser-based app).
>
>In the total RTCWEB effort (IETF and W3C), we need to consider the fact
>that the user will likely have more trust in the non-maliciouisness of
>the browser than in the non-maliciousness of Javascript downloaded from
>a Web page.
>
>In the strict IETF effort, the Javascript API boundary is out-of-scope -
>but at the moment, this is the mailing list that contains the people
>interested in both efforts; we haven't started splitting up yet.
>
>What I draw from that is that the IETF needs to specify security in
>terms of acceptable and unacceptable behaviour of end systems, whether
>they are browsers or not (video slamming, congestion-causing behaviour
>and making eavesdroppers' lives easy are all failures that can be
>observed on the network interface), while the W3C effort will have to
>address means of making it easy to prevent those problems by controlling
>the API presented to the less trusted parts of the overall system (the
>downloaded Javascripts).
>
> Harald
>
>> Regards,
>>
>> Christer
>>
>>
>>
>>> -----Original Message-----
>>> From: Ted Hardie [mailto:ted.ietf at gmail.com]
>>> Sent: 8. maaliskuuta 2011 6:23
>>> To: Christer Holmberg
>>> Cc: rtc-web at alvestrand.no
>>> Subject: Re: [RTW] Draft new: draft-holmberg-rtcweb-ucreqs-00
>>> (Web Real-Time Communication Use-cases and Requirements)
>>>
>>> Hi Christer,
>>>
>>> Thanks for putting together the document. One thing that
>>> struck me in reading it is that it has both some use cases in
>>> which the downloadable web application is paramount, but
>>> others (notably 4.4 and
>>> 4.6) in which the description could equally apply to
>>> standalone applications. In side conversations, Harald and I
>>> have discussed whether the threat model in standalone
>>> applications, even those using the same underlying protocol
>>> mechanics for rendezvous and media streaming, is really the
>>> same. Would you see a MMORG application using this method as
>>> having different threats than a downloaded casual game?
>>>
>>> regards,
>>>
>>> Ted
>>>
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>
>
>_______________________________________________
>RTC-Web mailing list
>RTC-Web at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/rtc-web
More information about the RTC-Web
mailing list