W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Protocols, extensions, compatibility

From: Mike Belshe <mike@belshe.com>
Date: Sat, 31 Mar 2012 02:03:25 +0200
Message-ID: <CABaLYCt+D0B3beCA9V-hR=FJt0QASUyGxuQfGheHsjFyLWC15w@mail.gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Sat, Mar 31, 2012 at 1:10 AM, Adrien W. de Croy <adrien@qbik.com> wrote:

>  Hi all.
> There have been some questions raised about whether the best way forward
> is a new protocol, or patches to existing protocols etc.
> I'm sure many of you are familiar with IMAP, and on the imap-ext mailing
> list recently there has also been discussion about exactly this.
> IMAP like HTTP was conceived a long time ago.  At that time, people hadn't
> thought about all the things we wanted mail or web to do.
> So as time went by, the desires for features left an ever-widening gap
> between what customers wanted developers to create to solve the issues they
> faced, and what protocols would support.
> The classic response to this has been the definition of optional
> extensions to the core protocol, or frankly hacks.
> This has happened in both HTTP and IMAP.
> The situation as it stands with IMAP, is that any IMAP client implementor
> frankly has a number of nightmares on his/her hands.
> Because the extensions were by and large optional, and not independent of
> each other (frequently RFCs for IMAP extensions alter other extension specs
> for the case where both exist), a client has to deal with
> an ever-increasing interdependency issue.  Clients need to be able to do
> the same task in a multitude of different ways to cope with different
> server option support.
> This results in ever-increasing complexity, increased risk of
> implementation errors due to interdependencies, increased time to develop
> features, and generally reduced performance.  Development gridlock.
> The same thankfully cannot be said for HTTP at the moment, although there
> are a few areas where dealing with optional support makes life difficult.
> So, where am I going with this?
> Eventually a requirement may come along which simply doesn't fit with the
> current protocol.  That's when it becomes interesting to consider starting
> afresh.
> We may consider we aren't at this point with HTTP.  Personally, I think
> things like long-polling are an indication that HTTP isn't doing what we
> want, and currently doesn't support the semantics we want.

Patrick McManus did a nice presentation and discusses how 'HTTP has hit a


He makes some similar points, but discussing mostly at the connection mgmt
& protocol level.

Video is here:  https://codebits.eu/intra/s/session/220


> Adrien
Received on Saturday, 31 March 2012 00:03:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC