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

Mark Nottingham <> Tue, 22 March 2011 09:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50AAA3A67F3 for <>; Tue, 22 Mar 2011 02:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.325
X-Spam-Status: No, score=-105.325 tagged_above=-999 required=5 tests=[AWL=-2.726, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jtlc0VbmDyjb for <>; Tue, 22 Mar 2011 02:44:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DF6203A67F2 for <>; Tue, 22 Mar 2011 02:44:40 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9F60A509EB for <>; Tue, 22 Mar 2011 05:46:07 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 22 Mar 2011 20:46:04 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Apps Discuss <>
X-Mailer: Apple Mail (2.1082)
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 09:44:42 -0000

Since everyone is putting their .02 in...

I'm very glad that we have this plenary topic, precisely because it's getting this kind of response. I've been concerned about the evolution of the browser for some time, for a variety of reasons (some already stated by others):

  - General loss of high-level semantics in favour of low-level functionality (consider: HTTP and WebSockets) because browser vendors want to reduce QA exposure and "get out of the way"

  - Protocols are defined by libraries, not as standards. Thus it's easy to innovate, but hard to build on others' work (e.g., as a middlebox). 

  - Corresponding loss of unintended reuse

  - From what I've seen, most libraries tend to ignore aspects of security, internationalisation, dealing with latency, dealing with disconnectedness, and so forth. This leaves users with awkward choices.

  - Comparative weight of a "full" Web stack including JavaScript, HTML5, CSS and more to implement a functional application (I'd encourage people to read the HTML5 specification if they haven't already). 

  - Lock-in of data

  - Movement from declarative markup to imperative APIs for all Web functionality 

... and so on. What's important for IETF folk to understand is that this *is* happening, and it's going to be very big. The list above is negative, but there are positives too; what I think we should focus on is minimising the negative impacts of this platform, and maximising the positive (to shamelessly borrow from Bill Clinton last week at ICANN).


On 22/03/2011, at 1:31 AM, Dave CROCKER wrote:

> Folks,
> 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.
> 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.
> The summary also neglects to mention rather significant security concerns in all this real-time application downloading...
> d/
>> The Future of Applications
>> Advancements in the design of web browsers have introduced fundamental
>> changes to the architecture of application protocols. The widespread
>> availability and growing sophistication of JavaScript interpreters in
>> browsers enables web servers to push to browsers all of the application
>> logic required to implement a client-server protocol. Consequently, many
>> client-server applications that once required an installed client on a host
>> computer now can rely simply on a modern browser to act as a client for the
>> purposes of a particular application. For example, where once email clients
>> required a custom application to access an inbox, increasingly a web browser
>> can serve this purpose as well as the purpose-built applications of the
>> past. Similarly, HTTP with the assistance of JavaScript can subsume the
>> functions performed by the protocols like POP3 and IMAP. The need for
>> Internet standards beyond HTTP to implement an email inbox application
>> consequently diminishes - why author standards and worry about
>> interoperability of clients and servers when the server can simply push to
>> the client all the code it needs to be interoperable?
>> Many client-server applications on the Internet could potential migrate to
>> this post-standardization environment. In this environment, there is of
>> course still a role for the IETF to play: existing working groups like HyBi
>> and OAuth are examples of areas where standards work is still required to
>> support this application development paradigm. Collectively, we need to
>> identify areas where the standardization is unlikely to be relevant in the
>> future, and focus our efforts on those areas where our application designs
>> will remain impactful. The goals of this session are to explore future areas
>> of IETF work surrounding this evolution.
>> Speakers: Jonathan Rosenberg (Skype) Harald Alvestrand (Google) Henry S.
>> Thompson (W3C)
> -- 
>  Dave Crocker
>  Brandenburg InternetWorking
> _______________________________________________
> apps-discuss mailing list

Mark Nottingham