Re: Heirarchical error codes

[Doug Royer <Doug.Royer@xxxxxxx>]

> Date: Mon, 29 Mar 1999 19:36:46 +0000
> From: John Stracke <francis@ecal.com>
> 
> 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.

I agree. However when they extended SMPT into ESMPT they did not
force old MUAs to understand new error codes.

If a new SMTP server gets a new request, then it switches. The
protocol does not just allow any error code.

-Doug
-------------------------------------------------------------------
Doug.Royer@Sun.COM		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL