[RTW] Including or excluding an establishment protocol (Re: [dispatch] The charter formerly know as RTC-WEB take 3)

[Harald Alvestrand]

On 01/28/11 10:29, Ted Hardie wrote:
> Howdy,
>
> A question in-line.
>
> On Fri, Jan 28, 2011 at 7:38 AM, Harald Alvestrand<harald at alvestrand.no>  wrote:
>> Changing the subject as is my habit.... forgive the introductory
>> philosophical distraction.
>>
>> I tend to look at success criteria, and if we need to achieve something to
>> achieve success.
>>
>> If we fail unless we do this work, it MUST be done.
>> If we can succeed without doing this work, it does not have to be done.
>> If we can succeed only if someone else does this work, we need to make sure
>> that other thing also gets done (the classical example here is Javascript
>> APIs for the functions we make available).
>>
>> In this case, I define success (for myself - YMMV) as "browsers ship with
>> well defined, usable functionality that allows audio and video communication
>> between applications running as web pages in those browsers". More
>> functionality (including legacy device interoperability with gateways only
>> in the signalling path) is nice to have, but not essential for me to decide
>> that we have succeeded.
>>
>> The charter is a description of what work is to be done in this WG of the
>> IETF.
>>
>> If the IETF includes a signalling stack in the specification, it helps
>> achieve the goal. But it's not essential, because those bits go across a
>> wire that (likely) points in the direction of webservers that the pages load
>> from, and those webservers can do signalling intermediation as needed.
>>
> I have described this in the past as a case in which the webserver is the
> signal path, but your description of "signaling intermediation" sounds
> more ambitious.  In particular, do you mean that it might use different
> syntax with different clients, using this shared semantics?
That's one possibility. It might also do a similar function to what I 
think the SIP SBC does, and do address rewriting, stop stuff it doesn't 
like, or generally do like gateways do (that is, whatever it wants to). 
But as long as that behaviour doesn't have to be described in the spec 
to make things work, I think it should be outside of the scope of the 
working group.
>> What IS essential is that the semantics (not the syntax) of the information
>> needed to establish the connections between the browsers is known and
>> documented - because otherwise, the goal can't be achieved.
>>
> Huh.  If we have an API at the client side and known semantics for establishing
> the connections, isn't the easiest way to connect those two a standard protocol
> syntax for taking the API-expressed desired and signaling it to the
> intermediating
> web server?
Yep. But just over the last 2 days, I've heard people shuddering at the 
idea of SIP/SDP, sneering at the idea of an XML-based format, and 
contemplating over the idea of a JSON-based format. There will be a long 
discussion on what to choose, if we have to choose.
>> I'd be happy if the charter defined somewhat weaselly words like "Describe
>> the information that must be exchanged between the endpoints in order to
>> establish connectivity, and optionally describe how this information can be
>> represented using existing signalling protocols".
>>
> So, I may just be confused here.  Are you saying that we do define RTW syntax
> as well as semantics used here, and optionally describe a mapping
> to SIP/XMPP?  Or are you saying that we describe only the semantics
> and optionally define the mapping to signaling protocols.  To my ears,
> it sounds like you mean the second, but the first makes much more
> sense, as it is difficult to see how we get full interoperability with
> only a semantics description as a deliverable.
I'm saying that I think we have to describe the semantics, and I'd like 
to not prejudge the question of syntax.
>> But I wouldn't be happy with a charter that said "put SIP or XMPP in the
>> browser". It's not necessary for success, so I don't want to be bound to
>> doing it.
> Each also does many other things, so I agree.  But if someone wants to implement
> as:
>
> [RTW API]
> [Inbound mapping to signaling protocol]
> [Sip/XMPP]
> [Outbound mapping to RTW-syntax]
>
> then the way they got to the RTW-syntax is no one's affair but their own, right?
Agreed.