Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing

[Dzonatas Sol <[e-mail]>]

On Tue, Oct 18, 2011 at 4:43 AM, Harald Alvestrand <[e-mail]>wrote:

> (Apologies for the length of this note - but I wanted to follow this
> argument a bit deeply)
>
> In the discussions about RTCWEB signalling, I’ve had a change of heart.
> Or perhaps it’s just a change of terminology.
>
> The high bit is this:
> I believe we need to standardize a negotiation protocol as part of RTCWEB.
> This needs to be described as a protocol, and cannot usefully be described
> as an API.
>
> This note is to explain to my fellow WG members what led me to this
> conclusion, and - in some detail - what I think the words in the above
> paragraph mean.
> Those who don't want to read a long message can stop here.
> ------------------------------**------------------------------**
> ----------------
>
> The context of RTCWEB is the well known trapezoid:
>
> +-----------+ +-----------+
> | Web | | Web |
> | | Signalling | |
> | |-------------| |
> | Server | path | Server |
> | | | |
> +-----------+ +-----------+
> / \
> / \ Proprietary over
> / \ HTTP/Websockets
> / \
> / Proprietary over \
> / HTTP/Websockets \
> / \
> +-----------+ +-----------+
> |JS/HTML/CSS| |JS/HTML/CSS|
> +-----------+ +-----------+
> +-----------+ +-----------+
> | | | |
> | | | |
> | Browser | ------------------------- | Browser |
> | | Media path | |
> | | | |
> +-----------+ +-----------+
>
> or even the triangle, where the triangle is formed when the two Web severs
> on top are collapsed into one.
>
> A design criterion for RTCWEB has been that it should be possible to write
> applications on top of RTCWEB simply - that is, without deep knowledge about
> the world of codecs, RTP sessions and the like.
> Another design criterion is that interworking should be possible - which
> means that SOMEWHERE in the system, deep knowledge about the world of
> codecs, RTP sessions and the like must be embedded; we can’t just simplify
> our options until everything’s simple.
>
> There’s one place in the ecosystem where this knowledge HAS to be - and
> that is within the browser, the component that takes care of implementing
> the codecs, the RTP sessions and the related features. If we can avoid
> requiring embedding it twice, that’s a feature.
>
> It used to be that I was a believer in APIs - that we should make the API
> the “king”, and describe the way you generate an RTP session as “you turn
> this knob, and get this effect”.
> After looking at the problem of Web applications that don’t have domain
> knowledge for a while, I’ve concluded that this doesn’t work. There’s the
> need for one browser to communicate with the other browser, and if the
> intermediate components are to have the ability to ignore the details,
> what’s communicated has to be treated like a blob - something passed out of
> one browser’s API and into another browser’s API, unchanged by the
> application - because the application must be able to ignore the details.
>
> OK, now we have the API with blobs. We also have to make some assumptions
> about how those blobs are transported, who’s responsible for acting on them,
> and so on. And we have to make sure different browsers implement the blob
> the same way - that is, it has to be standardized.
> What’s more - we DO want to enable applications that are NOT simple.
> Including gateways, which are not browsers. So applications must be free to
> look inside the blob - break the blob boundary - when they need to. So this
> pulls in the same direction as the need for interoperability - the format,
> semantics and handling rules for these blobs has to be specified. In some
> detail.
>
> So we have:
> - a data format
> - a transmission path
> - a set of handling rules, in the form of states, processes and timers
>
> This doesn’t look like an API any more. This looks like a protocol. We’ve
> got experience in describing protocols - but it becomes much easier to apply
> that experience when we call it a protocol.
>


I like the idea that expands the FILE: protocol such that it would work with
an audio-only codec already available. I guess that would be a blob instead
of an image.





>
> Let’s do that.
>
> But - you did not address my point...
> ------------------------------**----------------
> No, I didn’t. But here are some points that might bear watching.
>
> “We shouldn’t mandate a new protocol on the wire”.
> We’re not. We’re specifying one, and mandating it for a specific point: The
> browser/JS interface.
> We can have applications that parse it locally using a JS library; in that
> case, the protocol runs between the browser and the local JS application.
> We can have applications that pass the blobs to a server for gatewaying
> into something else; in that case, the protocol runs between the browser and
> the server.
> We can have applications that pass the blobs (possibly via a very simple
> server) to another browser, unchanged; in that case, the protocol runs
> between the two browsers.
>
> In no case does the browser need to know where the other end is; all it
> cares about is that the messages flow according to protocol.
>
> “We should build knobs and let JS libraries take care of what’s on top of
> them”.
> Well - we could. But it violates the idea of only having the domain
> knowledge present once.
> If you have to have a browser that implements codec A, and a JS library
> that knows how to control codec A, you are *requiring* knowledge in two
> places. That’s not optimal.
> Things may change in the future - once downloadable codecs actually work,
> downloadable negotiation blobs may be a reasonable counterpart. But we’re
> not there now.
>
> “We should use existing protocol X”
> We could. But then, we’d buy into all the baggage of protocol X - both the
> things it requires us to do and the things that it won’t let us do. Doesn’t
> sound too good to me.
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>