Subject: Re: Heirarchical error codes

From: Doug Royer <[email-masked]>
Date: Mon, 22 Mar 1999 14:35:42 -0800 (PST)

> From: "Frank Dawson" <[email-masked]>
> Date: Mon, 22 Mar 1999 08:26:52 -0500
> 
> On Thursday, March 18, 1999 8:26 PM, Doug Royer wrote, in part:
> 
> >2) I think we had a discussion about being able to SET the
> >   CAP version that the client knew about. No more conflict?
> 
> Hhmm. I don't remember reading about this discussion in any minutes. Maybe
> you can refer me to that discussion?

It was when we were talking about backward compatibility.

> In any case, it would seem appropriate for the CS to disclose the CAP
> version that it understands in a response to the CAPABILITY command.
> However, the requirement that a CS must adjust and talk in a version that
> the CUA specifies, seems odd and not consistent with other protocols that I
> have read. Did you have some IETF protocol in mind?

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 had mentioned that it was what I saw as a large bug in IMAP.

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

> Hence, the CUA would read the level of CAP support in the CS with the
> CAPABILITY command and react accordiningly in the command syntax and
> semantics that it sends to the CS. Certainly is the CS responds to a
> CAPABILITY command with "CAP v1.0, CAP v1.x", then the CUA could choose to
> use either v1.0 or the later v1.x command set.

And how would the CUA coose to tell the CS that it does not have
a clue what V1.x is? Whithout the CUA sending a V1.0 as the only
version supported in a capability command to the CS?

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

---

From: John Stracke <[email-masked]>
Date: Mon, 29 Mar 1999 19:36:46 +0000

> 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  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/