Re: Heirarchical error codes

[Doug Royer <Doug.Royer@xxxxxxx>]

> Date: Sat, 20 Mar 1999 13:37:22 -0500 (EST)
> From: Rob Earhart <rob@andrew.cmu.edu>
> 
> On Fri, 19 Mar 1999, Doug Royer wrote:
> > > > If I issue an ABORT and get back a 2.0.99 - what does that mean
> > > > to the CUA?
> > > 
> > >   Even if v2 of CAP were to define that code, v1 clients wouldn't be able
> > > to grok it; they'd just have to deal.
> > 
> > Yes but in Minneapolis we talked about requiring a V2 server to
> > have a command like "go to v1 mode". Then its a non-issue.
> 
>   It would have to be in v1, so that the first thing a client does is
> issue the command "go to v1 mode".

The server would not have to have been in v1 mode.
A v1 client could not be in v2 mode as its does not understand v2.

So if we were to send capabilities both directions (and I do like
that idea) the server would know at initial connection time.

> > I would prefer if error codes were assigned in sequence. (1, 2, ...)
> > and have NO relational value. I think the argument of human readable
> > result codes is silly. As 99.999% or more of all of the calendaring traffic
> > of the future CAP will be between CS's and CUA's, not people looking
> > at them.
> 
>   The same argument holds for all protocol elements, actually.  Why have a
> textual protocol at all, instead of going straight binary?

In general I could agree. In CALSCH, the RFC's already define status
codes RFC2445, 2445, and perhaps 2446.

CALSCH is a MIME object - which is text. If it were binary
data (ftp for example), then the protocol should be binary.

> > 1) I think that the current CAP proposal is that tags be NUMERIC only.
> >    (I know that's not your point - just FYI in case some missed that)
> 
>   (Incidentally, where could I get a copy of the current CAP proposal?)

I had thought the 1st cut proposal had been sent out - its
still getting some editorial fixes prior to it being sent out.
It is a document from some of us that have been meeting almost
monthly for the last few months. I think that proposal is being
updated as these debates go on, and may be submitted as soon
after the ietf gate opens.

> > 3) Human readable messages in server / client protocols makes
> >    implementing multi-simultaneous-locale servers difficult.
> 
>   I disagree; I've personally written the code to do it, and aside from
> the effort in translating, it was trivial.  (Admittedly, things do get
> interesting if you want to use an external message catalog.)

1) You have just dictated that the server know all of the languages
   and perhaps charset's that any client may be using the server.
   
2) And the server would then have to have a database of all of the 
   translated messages.
   
3) Also this would require that the clients send down at connection
   time:
 
   (A) language and:
   
   	(B) The charset the client was running in. Forcing
   	    the server to know all charsets of all clients
   	    and be able to charset convert assuming they
   	    have that message already in a translation database.
   Or
   
   	(C) Would add the requirement that all clients be able
   	    to charset convert from the servers local. Forcing
   	    all charsets and charset conversion into all clients.
   	    
   If (C) then:
   
   	(D) We would have pre-define the server charset (UTF-8 ?)
	    Not in itself bad. But I don't see charset conversion
	    in PDA's.
   Or

   	(E) The server would have to sent its charset up to
   	    the client. If the client did not know how to
   	    charset convert, then another status message
   	    that says I can't convert your status message,
   	    so lets default to just result codes :-)
   	    
If there is reply status text intended for a human to read. Then
it is only an implementation pain and gains nothing for a client.

Have you seen some of the so called human viewable messages
that come back in IMAP servers? What does "internal error" mean?
What does the user do about it? What does the user agent do
about it? Client implementations tend to just look at the
error code and ignore the gratuitous text.

I could see a debug option that turned them on. Then they
would be OPTIONAL and the server would not have to translate
the message for every locale. And if they were OPTIONAL for
the server to implement and advertised as a capability, then
I could go for them.

> > A well defined and well thought out protocol should be able
> > to define all CS and CUA states and response codes.
> 
>   This turns out to be nigh-impossible.
>
>   There are simply too many special cases to create a response code for
> each of them; ask Ned Freed sometime about X.400 error codes, ...

CALSCH is not x.400 and is not anyway near that complex.

>   Incidentally, one of the arguments that I was trying to make which you
> didn't address was that response codes shouldn't be strictly hierarchical;
> there's a need for orthogonality.  Did this make sense?  (I just want to
> check; I think it's pretty important.)

Yes I agree - I participated in DRUMS and listened to the issues
with SMTP implementations.

BTW - I don't mean:

	"STATUS-OK"

as a text message. I mean something like:

	"STATUS-OK gratuitous text message humans expected to read".

I am in favor of using the already RFC defined error messages
for CALSCH. And I am in favor of NO gratuitous text message humans
expected to read (except in an optional debug mode).

In APPLCORE we should I think use non-numeric, non-heirarchical
status codes.

In CALSCH we should use the already defined methods.

My 2¢

-Doug