Subject: Re: PROPOSAL: CAP Error codes definition and handling

From: Frank Dawson/CAM/Lotus <[email-masked]>
Date: Wed, 19 May 1999 17:50:00 GMT

John Stracke wrote:

>I think we need to be able to provide more than a prose equivalent; we
need to
>be able to use nonstandard text so that the message can convey
>implementation-specific detail.  Since the protocol ignores the text, this
>doesn't impose any great burden on the parser.
>
>The reason we need implementation-specific detail is so that an
application
>developer who's getting unexpected errors from the other end can get as
much
>information as possible as to why.  (Consulting the logs at the other end
is
>not always good enough; sometimes you're not allowed, and sometimes it's
hard
>to figure out which log entries correspond to your connection.)

It sounds like you are talking about a scenario of where you are debugging
an implementation. This sounds like it can be non-conformant to the base
CAP spec without any big deal. For example, you go into your server and
turn-on the "super duper text feature" and kickout the debugging text, even
though its not conformant. Then when you have fixed the machine, you go
back to the standard text, if you emit any of the optional text, and voila!

For testing conformance to CAP, the implementation would have to emit only
the standard text strings specified in the spec, if it emits any optional
strings at all. That is the text string should be that specified for the
given status code.

---

From: David Madeo <[email-masked]>
Date: Wed, 19 May 1999 14:30:17 -0400

Frank Dawson/CAM/Lotus wrote:

> though its not conformant. Then when you have fixed the machine, you go back
> to the standard text, if you emit any of the optional text, and voila!

> strings at all. That is the text string should be that specified for the

While I'm perfectly happy not having any text there, if you are going to
require it (even as an option), you should expect to be able to see it on both
sides.  Perhaps if one side starts emitting the optional text, the other party
should start as well?  Or make it a command "debug=off", "debug=normal",
"debug=give me whatever you've got"

dmadeo

---

From: John Stracke <[email-masked]>
Date: Wed, 19 May 1999 19:10:20 +0000

> back to the standard text, if you emit any of the optional text, and voila!

But this assumes that you control the server--if you do, then logfiles could
be enough.  Sometimes you have to debug a client against a server you don't
control.  For example, suppose you get a report that a user at Company A
running Lotus CAP Client 1.0 is having trouble using CAP to invite someone who
works at Company B, where they use Sun CAP Server 1.5.  You can't get Company
B to cooperate, but you can give the user a debugging client (or a way to turn
on debugging mode) which logs the protocol traffic, and get him to send you
the results.  If Sun CAP Server 1.5 emits detailed error text, you can use it
to figure out what's going on.  Of course, the detailed error text will be
idiosyncratic, but you've got a human brain to interpret it--and, at a
minimum, it won't make things worse.

As I understand it, this sort of thing goes on all the time in debugging mail
problems, which is why sendmail's SMTP server has more detailed error messages
than the spec requires.

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