Re: IMAP4 List Command Extensions
Mark Crispin <mrc <at> cac.washington.edu>
2005-06-02 13:14:03 GMT
On Thu, 2 Jun 2005, Simon Tyler wrote:
> Whether or not a server stores UIDNEXT or calculates it is a server
> implementation decision. It is irrelevant when designing a protocol.
This is completely wrong.
For better or worse, Internet protocols are molded to accomodate existing
implementations. You will receive strong pushback on any proposed
protocol or protocol enhancement whose impact is perceived as harmful to
one or more implementations. Complaints that "it's a poor specification"
if your demands are not fufilled will fall on deaf ears.
In fact, what you want is to have IMAP molded to accomodate *your* client
implementation. Rather than fix your client so it doesn't do something as
ill-conceived as a STATUS on every LISTed mailbox, you want to change the
protocol so the server does the stupid thing for you automatically, all to
save your client some RTTs. It doesn't address the underlying problem.
The entire point of the Internet protocol architecture is a set of
interoperable protocols which can be implemented across a wide variety of
systems, including systems with legacy infrastructure.
The design of protocols for a perfect world, in which you never need to
concern yourself with the other guy's problems, is not the realm of
Internet. It is the realm of proprietary protocols and systems.
In the Internet world, implementors MUST consider the impact of what their
application does; they can not pretend that they are in a vacuum where
only they count. There will be strong pushback against any proposal that
is perceived as allowing one vendor to count coup against another.
In the proprietary world, you don't have to worry about such things. You
control both the client and the server, and any other implementor with the
temerity to implement your protocol must follow your rules. At any time,
you can change the protocol to hurt the other implementor, and you're
motivated to do so because they are your competitor.
In the Internet world, you have to limit the protocol to what all
implementations can do well, so that everybody can play ball on a level
In the proprietary world, you can fine-tune the protocol to optimize your
implementation. It's your ball and your field.
In the Internet world, interoperability is king, and everything else must
submit to the demands of that king.
In the proprietary world, the owner is king, and that king receives
You seem to want the best of both worlds, while paying the price of
neither. It doesn't work that way.
-- Mark --
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.