Re: [apps-discuss] IETF technical plenary: the end of application protocols

Nico Williams <> Tue, 22 March 2011 22:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 578DB28C16C for <>; Tue, 22 Mar 2011 15:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aLAcMpJli11j for <>; Tue, 22 Mar 2011 15:44:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5119928C16B for <>; Tue, 22 Mar 2011 15:44:31 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id C60962C806D for <>; Tue, 22 Mar 2011 15:46:03 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s=; b=TL2cU5mLJ5mBj9eu6EYuLGLx08B8PFLFLjbS/DGZjdXY JGMFHa6iJk96HNiwNfA1WtoavgIw9tlZChvpD4E2eRfAr77vujezCgm3LVkWik9Z 0OhCc7mgqB3JWWMbwyBOrLqLLONCCNRRB/0m3HcJyZkzTZTIb+ueunlrbhS0neQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s=; bh=2BRBfouLQ+RbFX5kBDt0DWR/PuY=; b=szMKbGCm+J7 Ja7MqM2kBZBgUzay7kse6PT8I8osjzH5qfKhy29VetRTWBCAiE1g3krmNdWGjPtn NH6okRBHeQiy9BdgIXOPc8QbIVyKkoJDgoXUQCnwSbB8QJrYn0pP9Orfc+Cng/Hs mF5Fmcg9mnRsyC0CgkWyyTfPa+iUn5ow=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 90D452C806B for <>; Tue, 22 Mar 2011 15:46:03 -0700 (PDT)
Received: by vxg33 with SMTP id 33so6954592vxg.31 for <>; Tue, 22 Mar 2011 15:46:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id x2mr6013826vdv.264.1300833962768; Tue, 22 Mar 2011 15:46:02 -0700 (PDT)
Received: by with HTTP; Tue, 22 Mar 2011 15:46:02 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 22 Mar 2011 17:46:02 -0500
Message-ID: <>
From: Nico Williams <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Apps Discuss <>
Subject: Re: [apps-discuss] IETF technical plenary: the end of application protocols
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: Tue, 22 Mar 2011 22:44:32 -0000

On Mon, Mar 21, 2011 at 9:31 AM, Dave CROCKER <> wrote:
> I just saw the announcement for the Technical Plenary presentation.
> As described, the session suggests a failure to recognize at least two
> architectural issues.
> One is that it mandates full-time connectivity.  The other is that protocols
> that it says are no longer needed are in fact still needed in some form,
> albeit
> as a layer above HTTP, rather than TCP.
> Replacing TCP with HTTP does not eliminate the requirement for purpose-built
> application protocols, such as specialized mailbox access.

HTTP _and_ JavaScript is what the announcement asserts.  This is
another way of saying that applications are now downloaded as
necessary.  Anything identifiable as an application protocol becomes
an ephemeral incident.

I don't quite buy it.  Even in the age of AJAX people speak of APIs,
where the APIs are all based on HTTP and some document representation
(XML, XHTML, JSON, ...).  APIs are -roughly, if not exactly- another
name for "protocol" in this context.

Perhaps we could speak of a large-scale replacement of many apps with
a mixture of apps that define application protocols/APIs, apps that
define neither, and apps that define protocols/APIs for some parts and
none for others, plus a thin-client model.  That is what I think is
happening.  Whether a protocol or an API are defined will generally
depend on how much developers can rely on browsers and JavaScript.
Browser-based UIs are nice, but not enough, which leads at least some
applications to grow stable protocols or APIs.

No, TCP is not now just a layer with which to slowdown HTTP.  There
will continue to be non-HTTP-based applications for a long time to

> On the other hand, it does tend to encourage an explosion of competing,
> incompatible application protocols, making for rather remarkable burdens on
> servers and clients.

Certainly if all users were happy to live with browser-based apps
only, where the application is always delivered by their corresponding
service providers, then yes, we'd have an explosion of unstable and/or
undocumented (and therefore non-interoperable) protocols.

In practice there's a limit to how browser-bound users can be.  Mobile
devices in particular are probably a big driver of stable HTTP-based
protocols/APIs, since it's oh so much lighter weight to speak HTTP
without having to have a browser, a DOM, and a JavaScript engine.  But
there's also a lot of demand from users for third party apps, and
pressure from 3rd party developers for the same, and it may well be
that this will be enough in many cases for the provider to agree to
provide stable interfaces, even if later on mobile devices were to
gain so much power and functionality that browser-based UIs could
reasonably rule the day.  Besides, even if 90% of the time
browser-based UIs sufficed, there will always be some cases where they
don't (mash-ups, automation, convenience, aesthetics,  ...).

Only by ignoring the needs of users do we get to have a pure
thin-client model of the world filled with unstable/undocumented
protocols.  Moreover, there is some degree to which we should be
concerned that we're being encouraged (not necessarily by those giving
the presentation in question) to accept such a model primarily because
this is in the [apparent] self-interest of service providers.

In other words: we probably need interoperable protocols/APIs now more
than ever.  They may simply take a different form than the non-HTTP
apps' of yesteryear, but that's it.