Subject: Re: Heirarchical error codes

From: "Frank Dawson" <[email-masked]>
Date: Tue, 16 Mar 1999 18:24:17 -0500

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?

It would appear that your example will have much other problems because the
there may have been newer "standard" status codes introduced by the newer
version CS that supports a newer version of CAP.

- - Frank

---

From: John Stracke <[email-masked]>
Date: Tue, 16 Mar 1999 23:47:34 +0000

> Isn't this fraught with problems?

Sure, but it's also essential for deployments; an upgraded server has got to be
able to support downlevel clients.

> version" CS. Won't this key the CUA that it may get different REQUEST-STATUS

Actually, in this case, I think it's the server's responsibility to try to
speak the old protocol version.  The heirarchy idea is meant simply to minimize
the amount of work this takes.

> version CS that supports a newer version of CAP.

Yes, of course.  The goal is to minimize the problems.  Defining classes of
error codes enables the client to say, for example, "OK, I don't know exactly
what this error means, but I do know that it indicates some kind of access
control problem".

--
/=============================================================\
|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 |
\=============================================================/