Subject: Re: Heirarchical error codes

From: Doug Royer <[email-masked]>
Date: Sat, 20 Mar 1999 14:59:48 -0800 (PST)

> Date: Sat, 20 Mar 1999 13:37:22 -0500 (EST)
> From: Rob Earhart <[email-masked]>
> 
> 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

---

From: Rob Earhart <[email-masked]>
Date: Sun, 21 Mar 1999 22:10:44 -0500 (EST)

> codes RFC2445, 2445, and perhaps 2446.

  Just to outline my problems with them:

  ) They're unwieldy and difficult to read in a protocol trace.

  ) They're pretty specific to processing of iCalendar objects -- which
is important in CAP, but not all of CAP.

  ) They impose a strict hierarchy on the response code space, which
limits extensibility.

  ) The protocols are fundamentally different.  CAP will be processed by a
different parser, which can translate as needed.  The operations, while
similar, need not--and probably will not--be identical. 

  On the other hand, they may be useful for a CUA when performing
iTIP-like manipulations.  Maybe a server could encapsulate them in some
responses? So when attempting to schedule a meeting, a client might
recieve the following:

	S: Bad iCal (3.5) "Invalid iCal object"

(I've left the human-readable text deliberately vague here; in a real
server, I'd clarify exactly what was invalid.  So how many people know,
off the tops of their heads, what 3.5 is defined to be by section 3.6 in
rfc2446?) 

  I think I understand your motivation: reusing REQUEST-STATUS property
values somehow would be a good thing.  I just don't think they're the
general solution for CAP. 

  Re: human-readable messages.  I agree with your points (although I don't
think UTF-8 is unreasonable for PDAs).  I still think that adding a
human-readable message doesn't hurt users who can't read it, it's a nice
addition for users who can, and is definitely a good thing from a system
administration standpoint, assuming that the server's halfway intelligent
about how it composes those messages.

> that come back in IMAP servers? What does "internal error" mean?

  I think that's a quality of implementation issue...

> the server to implement and advertised as a capability, then

  Why not just always send them?  They're not that much overhead, and
clients never have to show them to users... I'd much rather require
servers to implement them.

  )Rob

---

From: [email-masked] (Steve Mansour)
Date: Sun, 21 Mar 1999 21:32:10 -0800

>   ) They're unwieldy and difficult to read in a protocol trace.

I don't know about unwieldy, but it can certainly be hard to remember the
meaning of an error given its number.

> is important in CAP, but not all of CAP.

???  I'm not sure what you're driving at here?

>   ) They impose a strict hierarchy on the response code space, which

I don't see how. Could you explain this?

-Steve

---

From: David Madeo <[email-masked]>
Date: Mon, 22 Mar 1999 09:32:42 -0500

> meaning of an error given its number.

Initially this was a concern of mine as well.  We routinely sniff packets to
debug problems with applications.  It's easy enough though to write a perl
wrapper to translate this for the admin based on the particular sniffing tool
you use.  The hardware packet sniffers will probably build it in once it's an
RFC, etc.

As an aside, the ideal CS implementation would provide some way for admins to
see this without snooping, but that shouldn't be a concern here.

dmadeo