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

Binod PG <> Wed, 19 October 2011 15:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1ED8221F8C7A for <>; Wed, 19 Oct 2011 08:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gZcMktkqUKDJ for <>; Wed, 19 Oct 2011 08:07:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7CFF821F8C69 for <>; Wed, 19 Oct 2011 08:07:27 -0700 (PDT)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9JF7MF5004731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Oct 2011 15:07:24 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id p9JF7LbZ011301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 15:07:22 GMT
Received: from ( []) by ( with ESMTP id p9JF7GEa003303; Wed, 19 Oct 2011 10:07:16 -0500
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Oct 2011 08:07:16 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: Binod PG <>
In-Reply-To: <>
Date: Wed, 19 Oct 2011 20:37:10 +0530
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Harald Alvestrand <>
X-Mailer: Apple Mail (2.1084)
X-Source-IP: []
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4E9EE7AC.0256:SCFMA922111,ss=1,re=-4.000,fgs=0
Cc: "" <>
Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Oct 2011 15:07:28 -0000

> 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.
> Let’s 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"?