Protocols, extensions, compatibility

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.
  
  
Adrien