Subject: Re: Heirarchical error codes

From: Doug Royer <[email-masked]>
Date: Thu, 18 Mar 1999 17:25:07 -0800 (PST)

> From: "Frank Dawson" <[email-masked]>
> To: "John Stracke" <[email-masked]>, "calsch WG" <[email-masked]>
> Subject: Re: Heirarchical error codes
> Date: Tue, 16 Mar 1999 18:24:17 -0500
> List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
> List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
> 
> On  Tuesday, March 16, 1999 4:51 PM John Stracke wrote, in part:
> 
> 
> >Doug and Frank
> >responded that that wouldn't happen, because all error codes have to be
> >registered; there aren't any X- errors.  The point, however, is that
> >registration doesn't help when you're talking to an old client that
> >doesn't know the new error codes.
> 
> So, you think that we should support "older" CUAs connecting to "newer" CSs?
> Isn't this fraught with problems?
> 
> At the time you connect, a CUA will get the CAP version number of the CS,
> right? So, the CAP CUA will begin by knowing that it is talking to an "up
> version" CS. Won't this key the CUA that it may get different REQUEST-STATUS
> codes?

I think this is a flaw with IMAP and we should not do this.
The only way that most customers would find this is when all of a
sudden - their CUA stopped working?

-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: Rob Earhart <[email-masked]>
Date: Fri, 19 Mar 1999 09:40:59 -0500 (EST)

I think it's better to avoid limiting things to a linear series of
protocol versions; there will be different extensions, and they will be
orthogonal to each other.  It seems more flexible for each side to
announce a list of extensionss they support, and then both sides can
behave appropriately.

  )Rob

---

From: Rob Earhart <[email-masked]>
Date: Fri, 19 Mar 1999 10:46:39 -0500 (EST)

On Fri, 19 Mar 1999, Steve Mansour wrote:
> I'm not sure I follow what you're suggesting here. The message subject
> mentions error codes, but your text refers to capabilities.

  Sorry -- I was responding to a message in which the thread had wandered
into protocol revision numbers; I probably should have quoted it, for
context.

> Are you thinking of some sort of CAPABILITY list that the client sends the
> server, and a similar set of capabilities that the server returns based on
> what it received from the client??

  Almost; I'd rather see both simply send capability lists when the
connection is initialized.  For instance, at session startup, one might
see

  C: * CAPABILITY CAP XMLCAL
  S: * CAPABILITY CAP SASL ("KERBEROS_V4" "GSSAPI" "DIGEST-MD5") TLS

(using * instead of a normal tag because these aren't commands; they're
information which doesn't require a reply.) 

  The server probably shouldn't restrict its list based on what it gets
from the client; it's useful to see everything the server's capable of.
After this exchange, both sides know what the other's capable of dealing
with, and can restrict what they speak to the subset of the capabilities
they know about for which the other side has announced support.

  )Rob

---

From: [email-masked] (Steve Mansour)
Date: Fri, 19 Mar 1999 07:28:20 -0800

Rob,

Could you provide a brief example of what you mean?

-Steve

---

From: [email-masked] (Steve Mansour)
Date: Fri, 19 Mar 1999 10:26:12 -0800

>   S: * CAPABILITY CAP SASL ("KERBEROS_V4" "GSSAPI" "DIGEST-MD5") TLS

sounds good.

> from the client; it's useful to see everything the server's capable of.

agreed.

> they know about for which the other side has announced support.

I'll add this to the strawman draft.

-Steve