Re: [apps-discuss] AJAX is the new NAT

Ted Hardie <> Wed, 23 March 2011 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBBCC3A68DD for <>; Wed, 23 Mar 2011 14:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.538
X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k8t3VAvMrv4P for <>; Wed, 23 Mar 2011 14:32:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3FD113A676A for <>; Wed, 23 Mar 2011 14:32:13 -0700 (PDT)
Received: by qyk29 with SMTP id 29so4448902qyk.10 for <>; Wed, 23 Mar 2011 14:33:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s2tKztZrHmvA8dtDSIuDoJJ0BJR+1la+kZPomlJEZM0=; b=pEx+xwtpFtvIQZ04+55J02kqAn0LvMADv0vKgPzaOlmhfymqYGFdpMPlX9drRtkNWP harqJO5KFPaIOBO0povOo79R/yC6A6oPKfK6/+ZsZALyM5eyDSuE9mmP+pnALmM/GkV1 sM/97scE6w22AH4Ol7xyZ/CUT2/C04+IYnXtc=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tasVNCabIH1Iji20qrM9ZUzJH+xzr7QlGMZWSRZFpwo+QlmgSYFb4mQAXlNy/9HPVI fBR7ow6oa5PLar4/SHfZ4Q2wBdtM/+YTCOBUaPnCEywZ+KJtwwwPwICPReOX78ZA/MFq xLpKkhKZFt5K9UH4b+kz65B7rTENtplwbOuCM=
MIME-Version: 1.0
Received: by with SMTP id hb18mr6198539qcb.176.1300916027058; Wed, 23 Mar 2011 14:33:47 -0700 (PDT)
Received: by with HTTP; Wed, 23 Mar 2011 14:33:46 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 23 Mar 2011 14:33:46 -0700
Message-ID: <>
From: Ted Hardie <>
To: Carsten Bormann <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss <>
Subject: Re: [apps-discuss] AJAX is the new NAT
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Mar 2011 21:32:15 -0000

On Wed, Mar 23, 2011 at 1:22 PM, Carsten Bormann <> wrote:
> So, AJAX appears to be the new NAT.

So, that's a very good sound bite, but not a very accurate analysis.
There are two pieces that have been pointed out it a variety of ways
which you seem to miss:

 Once a node can
> control the code on *both* communicating peers, it can do interesting
> things without having to standardize much, as shown in RFC 3320 and as
> demonstrated nicely in AJAX.

The first is that AJAX is a client-server model which ensure that only
one of the two nodes can control the code on *both* communicating
peers.  That has a set of impacts that has been alluded to already in
this discussion, and it tends to concentrate power and development
effort.  You could say that enables innovation, as it creates a pool
of libraries and methods that can be re-used by others.  You could say
it stifles it, because that concentration ignores other fertile

It's that second point that is really at issue for the web as a
platform for application delivery.  Those issues don't relate as
strongly to the downloadable code issue as the base protocol having
been built for synchronous transfer of relatively small, cachable,
discrete objects; it's changed, of course, but the ability to do
reasonable things on that basis has its limits.

The RTCWeb effort that will be discussed in the upcoming BoF has been
trotted out as an example of the beauty of this approach.  In fact,
it's a great example of the tension.  Some aspects of the real-time
communication it means to enable can be mediated by web servers fairly
easily (the rendezvous and, to some extent, the negotiation).  Other
aspects, like the audio and video streams passed among peers, still
make much more sense delivered as RTP or using RTP-like flows.   (NB:
my personal opinion; the eventual WG will have to draw the lines

In other words, there is a class of client-server protocols for which
downloadable code is a good tool.  There are other protocol
requirements that are, bluntly, ill-met by that.  We want innovation
to proceed in both classes of problem. Which means enabling the first
class *while acknowledging its limits*.

Just my two cents, of course.

Ted Hardie