Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Binod PG <binod.pg@oracle.com>
In-Reply-To: <4E9D667A.2040703@alvestrand.no>
Date: Wed, 19 Oct 2011 20:37:10 +0530
Content-Transfer-Encoding: quoted-printable
Message-Id: <36F2FFCB-601B-4C2E-9B60-A2EFF503AC5D@oracle.com>
References: <4E9D667A.2040703@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good
 Thing
Precedence: list

>=20
> or even the triangle, where the triangle is formed when the two Web =
severs on top are collapsed into one.
>=20
> 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=92t just =
simplify our options until everything=92s simple.
>=20
> There=92s 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=92s a feature.
>=20
> It used to be that I was a believer in APIs - that we should make the =
API the =93king=94, and describe the way you generate an RTP session as =
=93you turn this knob, and get this effect=94.
> After looking at the problem of Web applications that don=92t have =
domain knowledge for a while, I=92ve concluded that this doesn=92t work. =
There=92s 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=92s communicated has to be treated like a blob =
- something passed out of one browser=92s API and into another browser=92s=
 API, unchanged by the application - because the application must be =
able to ignore the details.
>=20
> OK, now we have the API with blobs. We also have to make some =
assumptions about how those blobs are transported, who=92s 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=92s 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.
>=20
> So we have:
> - a data format
> - a transmission path
> - a set of handling rules, in the form of states, processes and timers
>=20
> This doesn=92t look like an API any more. This looks like a protocol. =
We=92ve got experience in describing protocols - but it becomes much =
easier to apply that experience when we call it a protocol.
>=20
> Let=92s do that.

I think, it is a move in the right direction. Having some sort of =
definition around how the negotiation would look like
is far better than leaving everything to interpretation of the web =
developer. This is especially good for people who
develop gateway libraries, since they will now have something to =
actually translate.

What exactly you mean by defining "transmission path"?

thanks,
Binod.=