RE: Poll for preferred API alternative

I tried to make this point on the IRC channel of the last call, but clearly it must be made again.

There is nothing in my reading of the use cases that makes the "browser-to-browser" use case *any more or less important than the other use cases*.

Just because we can come up with something with an SDP-like API that follows SDP Offer/Answer-like semantics and has ICE-like NAT traversal and DTLS-SRTP-like security does not in fact mean that we will support any of the other (not "browser-to-browser") use cases. In fact, supporting these cases will become particularly difficult if the SDP diverges, the O/A semantics diverge (as they have already), or the ICE implementation does not have the flexibility to interoperate with pre-final ICE implementations and/or lightweight consent-only gateways. This is precisely what the Microsoft document is talking about when we raise concerns about interoperability. Never mind, of course, that it will take several iterations just to get the SDP actually compatible between two vendor's browsers, if history is any guide.

If you can point me to a specific reference that "the main target for this work is the browser-browser case", please do so. Otherwise, I suggest that we work on specifications that make it as easy as possible to implement *all* of the use cases, rather than do what the current specification does which is to make browser-to-browser cases easier *at the expense of* the other use cases.

Matthew Kaufman

-----Original Message-----
From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Thursday, September 06, 2012 11:17 AM
To: public-webrtc@w3.org
Subject: Re: Poll for preferred API alternative

...
I think it is OK if the descriptions must be manipulated for interop (with non-browser end-points) cases; after all, the main target for this work is the browser-browser case.
...

Received on Thursday, 6 September 2012 20:34:04 UTC