Subject: Heirarchical error codes

From: John Stracke <[email-masked]>
Date: Tue, 16 Mar 1999 20:42:50 +0000

In the discussion of heirarchical error codes today, I pointed out that,
if the server sends "3.1.5" and the client knows only what "3.1" means,
then the client gets at least some information.  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.

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

---

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

On Tuesday, March 16, 1999 6:50 PM, John Stracke wrote, in part:
>Sure, but it's also essential for deployments; an upgraded server has got
to be
>able to support downlevel clients.
>

In which case your original request is moot. The down-level client won't see
the new request codes. I think that Doug Royer's earlier remarks were
correct. No, non-registered request status codes.

-- Frank

---

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

> Date: Tue, 16 Mar 1999 20:42:50 +0000
> From: John Stracke <[email-masked]>
> 

1) There are no OLD clients - this ain't out yet.

2) I think we had a discussion about being able to SET the
   CAP version that the client knew about. No more conflict?

-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: [email-masked]
Date: Thu, 18 Mar 1999 14:50:09 GMT

(Attempt to re-reply...)

John wrote:
>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".

but I dont want us to reinvent the preverbial wheel here so Ill refer you
all to the iCalendar RFC:

4.8.8.2 Request Status
...
The short return status is a PERIOD character (US-ASCII decimal 46)
separated 3-tuple of integers. For example, "3.1.1". The successive levels
of integers provide for a successive level of status code granularity.

The following are initial classes for the return status code. Individual
iCalendar object methods will define specific return status codes for these
classes. In addition, other classes for the return status code may be
defined using the registration process defined later in this memo.
[/Snippet]

Ill leave it as an exercise to the reader to find the actual text that
tells CUA implementers to do what John is asking for when dealing w/'newer'
reply codes...

Bruce

---

From: "Frank Dawson" <[email-masked]>
Date: Mon, 22 Mar 1999 08:49:44 -0500

On Friday, March 19, 1999 9:53 AM, Rob Earhart wrote, in part:

>  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, how do you see this working? It seems pure chaos if both the CUA and
CAP can do whatever they want in terms of behavior. This CAP protocol will
only work if we nail down the semantics of what a CUA must do and what the
CS must do with regard to "extensions".

We are talking about "standardized" extensions here, right? The discussion
so far did not leave any room for non-standard, experimental extensions.
These beasts smell like real interoperability problems-in-the-making to me.

Can you explain more of what you envisioned here?

- - Frank

---

From: "Frank Dawson" <[email-masked]>
Date: Mon, 22 Mar 1999 08:26:52 -0500

>   CAP version that the client knew about. No more conflict?

Hhmm. I don't remember reading about this discussion in any minutes. Maybe
you can refer me to that discussion?

In any case, it would seem appropriate for the CS to disclose the CAP
version that it understands in a resposne to the CAPABILITY command.
However, the requirement that a CS must adjust and talk in a version that
the CUA specifies, seems odd and not consistent with other protocols that I
have read. Did you have some IETF protocol in mind?

I actually think that it would be much more appropriate for ease/complexity
of CS implementation and CS scalability reasons to make the CUA adjust to
the version of CAP that the CS supports.

Hence, the CUA would read the level of CAP support in the CS with the
CAPABILITY command and react accordiningly in the command syntax and
semantics that it sends to the CS. Certainly is the CS responds to a
CAPABILITY command with "CAP v1.0, CAP v1.x", then the CUA could choose to
use either v1.0 or the later v1.x command set.

- - Frank

---

From: "Frank Dawson" <[email-masked]>
Date: Mon, 22 Mar 1999 08:36:56 -0500

On Thursday, March 18, 1999 8:29 PM, Doug Royer wrote in part:

>> >Doug and Frank
>> 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?
>

By this same logic, an arbitrary CUA should be able to speak LDAP or IMAP.

If a CUA connects to a CS and doesn't find the server-side protocol
environment that it is compatible with, then this is a fatal exception and
the sessions shouldn't continue.

We are taking this discussion of "ol' CUA talkin' to newer CS" too far. I
think that we need to fall back on KISS design philosophy and say no more
than I have propoposed above.

- - Frank

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Mar 1999 13:33:57 -0800 (PST)

> Date: Sun, 21 Mar 1999 22:10:44 -0500 (EST)
> From: Rob Earhart <[email-masked]>
>
> On Sat, 20 Mar 1999, Doug Royer wrote:
> > In general I could agree. In CALSCH, the RFC's already define status
> > codes RFC2445, 2445, and perhaps 2446.
> 
>   Just to outline my problems with them:
> 
>   ) They're unwieldy and difficult to read in a protocol trace.

Too late - they are RFC's and there are implementation already
using them. Wished you would have submitted your suggestions last year.
:-(

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

True - however part of CAP is returning iCalendar objects - with
those status replies. Two forms of reply codes for the same thing?

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

No not at all. Example, look at the documented extensions that CAP
and iRIP have proposed to them.

>   ) 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. 

CUA's would be forced to deal with both kinds. One from CAP, the
other in the iCalendar object.

>   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:

Why? When there are already defined ones that do the same thing?
Again, if this had been done 1 year ago when iCalendar was a draft.
At this time its just going to add confusion and double the
code to parse reply codes, one for each format.

> 	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?) 

Yet above you talk about a parser. The protocol is for the parser.

>   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.
> 
> > Have you seen some of the so called human viewable messages
> > that come back in IMAP servers? What does "internal error" mean?
> 
>   I think that's a quality of implementation issue...
> 
> > 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.
> 
>   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.

How long are they? What is the format of the line that I can ignore?

Optional at runtime - yes.
MUST implement - I could go with yes if they are optional at run time.
If required - a waste of bandwidth.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Mar 1999 14:41:17 -0800 (PST)

> From: "Frank Dawson" <[email-masked]>
> Date: Mon, 22 Mar 1999 08:36:56 -0500
> 

I don't reach the same conclusions.

> the sessions shouldn't continue.

Yep - its busted as I see it. 

In the future a CS server might say only V2. Then V1 <-> v2 is busted.

If however we specify that if a CS wishes to be backward compatible
with V1. There needs to be a way for the CUA to say that. If we
don't define it now, it will have never been in the CUA-v1 protocol
for it to have been said. Then there will be no hope of a V2 CS
being told to operate in V1 mode.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Mar 1999 14:43:17 -0800 (PST)

> Date: Mon, 22 Mar 1999 08:55:39 -0500

> > ...
> >
> >  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.)
> 
> This seems like unnecessary bits-on-the-wire for the CUA. Shouldn't the CUA
> just query the CS and respond accordingly?
> 
> What scenario did you have in mind that necessitated the CUA to also specify
> it's capabilities? Just because I have a capability doesn't mean that in a
> given session instance that I am going to use it. So what good is it to the
> CS for the CUA to provide this input?
> 
> Can you give us an example?

CUA protocol version?

-Doug

---

From: Doug Royer <[email-masked]>
Date: Mon, 29 Mar 1999 14:44:31 -0800 (PST)

> Date: Mon, 29 Mar 1999 19:36:46 +0000
> Doug Royer wrote:
> > If you don't provide the ability for the CUA to set the version,
> > it breaks CUA's when the new servers come out.
> >
> > How would existing CUA's adjust to a new CS?
> >
> > I can imagine that any one vendor would keep their CS and CUA in sync.
> > However it would break interoperability if your ISP upgraded and
> > the only way you found out is your 3rd party product broke.
> 
> Or, to frame it in an enterprise-centric sense, suppose you're running CAP1
> servers with, say, Lotus Organizer on your Windows boxen and Claris Works on
> your Macs.  Lotus Organizer 17.5 comes out with support for CAP2, and you want
> to upgrade; but you can't, because Claris Works isn't there yet.
> 
> Servers always have to be able to support old clients.  Any protocol that
> doesn't have a way to announce that you're a new client is broken and will
> lead to grief.  Consider SMTP, which didn't have any negotiation mechanisms;
> nowadays, we have ESMTP, but the transition is icky: if an ESMTP client
> connection to an SMTP server, the only way it can find out that the server
> doesn't do ESMTP is to give an EHLO command, fail, drop the connection, and
> reconnect.  CAP should do something better.

I agree. However when they extended SMPT into ESMPT they did not
force old MUAs to understand new error codes.

If a new SMTP server gets a new request, then it switches. The
protocol does not just allow any error code.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Mon, 29 Mar 1999 14:49:31 -0800 (PST)

> Date: Mon, 29 Mar 1999 19:44:43 +0000
> Frank Dawson wrote:
> > it's capabilities?
> "I cannot render non-Latin1 text"?

As there were not any Latin1 text messages defined,
I am not sure what your need is. 

iTIP messages are in UTF-8, or the charset as defined in
the MIME message. I don't recall seeing any others.

-Doug