Re: Heirarchical error codes

[John Stracke <francis@xxxxxxxx>]

Doug Royer wrote:

> If you don't provide the ability for the CUA to set the version,
> it breaks CUA's when the new servers come out.
>
> > I actually think that it would be much more appropriate for ease/complexity
> > of CS implementation and CS scalability reasons to make the CUA adjust to
> > the version of CAP that the CS supports.
>
> How would existing CUA's adjust to a new CS?
>
> I can imagine that any one vendor would keep their CS and CUA in sync.
> However it would break interoperability if your ISP upgraded and
> the only way you found out is your 3rd party product broke.

Or, to frame it in an enterprise-centric sense, suppose you're running CAP1
servers with, say, Lotus Organizer on your Windows boxen and Claris Works on
your Macs.  Lotus Organizer 17.5 comes out with support for CAP2, and you want
to upgrade; but you can't, because Claris Works isn't there yet.

Servers always have to be able to support old clients.  Any protocol that
doesn't have a way to announce that you're a new client is broken and will lead
to grief.  Consider SMTP, which didn't have any negotiation mechanisms;
nowadays, we have ESMTP, but the transition is icky: if an ESMTP client
connection to an SMTP server, the only way it can find out that the server
doesn't do ESMTP is to give an EHLO command, fail, drop the connection, and
reconnect.  CAP should do something better.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|francis@ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/