Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

[Matthew Kaufman <[e-mail]>]

On 10/4/2011 5:06 PM, Ted Hardie wrote:
> On Tue, Oct 4, 2011 at 3:32 PM, Iñaki Baz Castillo <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     2011/10/4 Ted Hardie <[e-mail] <mailto:[e-mail]>>:
>     > At today's Chairs call, Cullen, Magnus and I had a discussion of
>     how to make
>     > progress on the signaling discussion.  We feel the mailing list
>     discussion
>     > needs to have more concrete proposals in order to make progress,
>     and so
>     > we're putting forward the following:
>     >
>     > 1) If you plan to put forward a draft proposing a concrete
>     solution in this
>     > space, please send your name to the mailing list with that
>     intent by October
>     > 7th *THIS FRIDAY*
>
>     Hi Ted, could you please explain what exactly are you looking for? a
>     concrete signaling mechanism within rtcweb? something native in
>     browsers? something carried by HTTP/WebSocket?
>
>
> Hi Iñaki,
>
> The chairs don't currently detect consensus on how signaling will be 
> handled for RTCWeb sessions.  We don't want to circumscribe the 
> solution space, but we do feel that there is a need to have concrete 
> proposals, rather than broad statements like, "it shouldn't be in the 
> component X".  Concrete proposals for how it will be handled are the 
> best way we see to make sure folks are coming to consensus on 
> something they understand, rather than on rhetoric.

See my earlier email. Concrete proposal is: This Working Group does not 
produce *any* standard for what travels on the wire (as signaling) 
between an RTC Web Browser and its associated Web Server. This Working 
Group also does not at this time produce *any* standard for what travels 
on the wire (as signaling) between two web servers that wish to have 
interoperating communities of RTC Web Browsers, though the working group 
*may* address this at a future time, noting that several existing 
protocols are usable in the interim.

>
>
>     If so, I think that this should not be covered by rtcweb, which
>     instead should define a good API for dealing with SDP bodies (plain or
>     XML), create some kind of JavaScript object for mantaining each
>     session status and information (negotiated streams, codecs,
>     local/remote address...).
>
>
> If you would like to make a concrete proposal for how that JavaScript 
> object is constructed, what it contains, and how it is shipped around, 
> that would be great.   Without a statement of what those details are, 
> however, the chairs worry that people will argue (for and against) 
> proposals that have not been made.
>

I believe that a concrete proposal for the JavaScript API and the 
associated objects is out of scope for the IETF WG. Thus the details, 
for the purpose of this working group, would be "this is out of scope".

Matthew Kaufman