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

From: [email-masked]
Date: Wed, 7 Jul 1999 14:37:36 -0400

(My mail file got toasted so Im waaaay behind on responding to threads. 
Sorry for the lag but it will give you something to talk about in Oslo if 
nothing else...)

Doug responded:
>There are two kinds of errors:
>
>                CAP protocol errors - yet to be defined.
> 
>                iCalendar (RFC 2445) errors - already defined.
> 
>
>An iCalender object is a MIME object. And the charset can
>determined by looking at the MIME header. The language
>can be determined by looking into the iCalendar object (but
>only after you know the charset).
>
>However CAP protocol errors are NOT MIME objects.
>So what charset / language will the text part of any
>CAP protocol error be in? I think we want the CAP
>protocol to be in the UTF-8 charset. 

From what Ive seen of the drafts so far, CAP commands are being 
encapsulated in MIME objects and formatted 'like' iCalendar.  Hence, the 
can also share the same response/error code format, IMHO. 

Even if the CAP editors use their infinite wisdom to un-encapsulate the 
CAP commands (VERY BAD) the format of the CAP commands appears to be 
designed so that they can easily be parsed out by any standard iCalendar 
parser.  As such, it should aready be hip to the 2445 format.  So Ill ask 
again: Why reinvent this?!?!?  (Conversely, what is wrong w/the 2445 
format that wont suffice for CAP??)

WRT the 2 paragraphs, they are apples and oranges.  You cannot compare "An 
iCalender object" to "CAP protocol errors".  To be more accurate you could 
compare "An iCalendar _error_" to "CAP protocol errors".  In any case, an 
iCalendar error is _NOT_ a MIME object, it is inside one.  There is a distinct difference; you 
wouldnt say an MHTML <EMBED> is a MIME object (its inside one).

WRT Dougs choices, Id opt for #1 and I think that Patrick would agree 
since he already weighted in on this subject.  Besides, if you standardize 
what 4.5.6 means then the "<username>;DENIED" is only really useful for 
either logging or your favorite file.  (You can always use the format from 
2445 to put that in the status description or the last optional component 
and achieve the exact same effect, yes?!)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Wed, 7 Jul 1999 16:03:46 -0700 (PDT)

> From: [email-masked]
> To: Doug Royer <[email-masked]>
> 
> Doug responded:

Not quite true. The protocol commands get a status reply and
there may be a MIME object that follows it.

> format that wont suffice for CAP??)

Have you read the draft?

> and achieve the exact same effect, yes?!)

For the most part I agree with you. I still think you
are confusing protocol and iCalendar status replies.
There are cases when they are NOT the same.

The protocol status reply might include:

	I got the request
	I can not process the request
	I don't have a clue what you said 
	.
	.
	.

These are not iCalendar status replies.

If you send down a command of:

	I-will-send-junk

You would not get an iCalendar object back.

---

From: [email-masked]
Date: Thu, 8 Jul 1999 11:06:11 -0400

>there may be a MIME object that follows it.

So you are using the IMAP/POP3 argument of a response code followed by 
optional MIME data to justify a new format??  Still, even though the CAP 
commands are in MIME objects and formatted like iCalendar this "before the 
optional MIME data" claim does not justify yet another format that 
essentially duplicates what we have now.

>>So Ill ask

Yes, twice actually: drafts E and F (or was that F and H??).  They are few 
and far between and Im not on the day to day distribution list so I dont 
get the more frequent updates.  Your point??  (And I dont see a direct 
answer to my question in the drafts I have so please point it out to me so 
I can go and mope in a corner...

BTW: I just repeeked at Draft G (Yes, its not current but I dont have the 
latest handy) and the first example shown in Section 8.1.5 shows:

        C: 200 SENDDATA:10
        C: Content-Type:text/calendar; method=READ; component=VEVENT
        C:
        C: BEGIN:VCALENDAR
        #  etc
        C: END:VCALENDAR
[Snip]
        S: 200 2.0.2
        C: CONTINUE:10
        S: 200 2.0.11 cap://cal.example.com/relcal2
[Snip]
so this tells me:

A: the CAP READ is encapsulated in a text/calendar MIME type object and 
B: that the reply/response codes used are partially formatted identically 
to those in 2445.  (The codes are hierarchical and contain optional but 
useful information after the numeric values).  Heck, the numeric codes 
appear to be those in 2445/6/7 even...

(Im assuming that the tagged 200 codes were just stale edits left in by 
accident)

> I still think you

No, Im not.  They are from different 'layers' if you like (ie: the "CAP 
protocol" layer and the "Application" layer).

>There are cases when they are NOT the same.

Finally, some agreement.  :^)

Still, just because they are not the same _CONTENT_ does not mean they 
cannot share the same _FORMAT_.  I have yet to see any compelling reason 
to invent a new _FORMAT_!

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 8 Jul 1999 12:46:28 -0700 (PDT)

> optional MIME data to justify a new format??

No

>  Still, even though the CAP 

The protocol commands are not formatted like MIME objects.

The iCalendar CS commands are formatted like MIME objects.

---

From: [email-masked]
Date: Thu, 8 Jul 1999 17:53:18 -0400

>The iCalendar CS commands are formatted like MIME objects.

Hmm, let me recheck what was previously scribed as an example:

4.5.6;<username>;DENIED

looks like the format Im proposing with statcode = 4.5.6, statdesc = <username>, and extdata = DENIED.  Looks like 
you are proposing the same format as me (w/a minor preference of requiring 
the extdata component)...

(At some folks urging Ive retrieved and partially rescanned the 'official' 
CAP draft)  From the draft on Pats site, I see the first C/S example is:

   C: AUTHENTICATE KERBEROS_V4
   [Snip]
   S: .
   S: 2.0 [email-masked]

To me, that last line could just as easily be:

   S: 2.0;[email-masked]

or possibly even:

   S: 2.0;Success;[email-masked]

In fact, Section 4.3  Response Format starts with:

Server responses consist of a response code and any parameters:

<response code> [<response data>]

The optional response data varies depending on the response code.

This format looks almost identical to that of Section 4.8.8.2 of 2445 
w/the difference being a 'missing' <statdesc> field.  Also, that 
description of the [<response data>] sounds an awful lot like the 
description in 2445.  These two formats are practically identical 
including the description of the <response code> meanings later in the 
text (2.0 = Success, etc).  Apart from new codes, I still have a tough 
time buying any argument to create a new format...  (And new codes can 
easily added so I dont swallow that argument entirely.)

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 8 Jul 1999 16:14:12 -0700 (PDT)

>  ...

I think I had misunderstood your point. Restart :-)

Here is an RFC-2445 status:

     rstatus    = "REQUEST-STATUS" rstatparam ":"
                  statcode ";" statdesc [";" extdata]

     rstatparam = *(

                ; the following is optional,
                ; but MUST NOT occur more than once
                (";" languageparm) /

                ; the following is optional,
                ; and MAY occur more than once

                (";" xparam)

                )

If you are arguing that TEXT be mandatory in the PROTOCOL (as
it is in RFC2445) reply codes - then we go back to the LANG and
CHARSET debate.

Do you want xparam and languageparam in the PROTOCOL status reply?
I want LANG, others do not.

Also, the 'statdesc' and 'extdata' portions of RFC2445 are NOT defined
as specific text or format.  For PROTOCOL status codes they really
need to be formatted.  (Like the example you gave where the reply
gives the UPN of the user).  So I guess we could say that it's like an
RFC2445 REQUEST-STATUS, but not the same as some of the replies have
formatted statdesc.

I really do not care if the parts are separated by a ';' or not.

I do care if they are of a know computer parsable format:

   S: 2.0;[email-masked]

Where as a valid RFC2445 REQUEST-STATUS might be:

   S: 2.0;your UPN is [email-masked];extra text
   
Is not useful if you need to know the users UPN.

So, I think we could use a similar format. But I don't think
we can say it is the same as RFC2445 REQUEST-STATUS.

-Doug

---

From: [email-masked]
Date: Fri, 9 Jul 1999 10:42:49 -0400

>I think I had misunderstood your point. Restart :-)

I think a epiphanys are happening all around on this one...  Read on.

>I want LANG, others do not.

Reset here folks.  The response/reply codes in CAP do _NOT_, repeat NOT, have the format of parameter:value, they are strictly the _value_ part of the format.  (You do not see "S: Response-Status: 4.5.6;<username>;DENIED", the example is "S: 4.5.6;<username>;DENIED"). 
So, the entire discussion about do we use the rstatparam on the CAP response is moot.  I probably should have been more 
precise when I resuggested reusing the format; I meant to suggest the 
format of the Response-Status parameters _VALUE_, not the entire property 
itself!

So, the revised suggestion I put on the table is that the CAP 
response/reply code format be simply:

     requeststatus    = statcode ";" statdesc [";" extdata]

(Yes, this means that "S: 2.0" would become "S: 2.0; Success", etc.  It 
also could become "S: 2.0;" and have a NULL statdesc...).

>gives the UPN of the user).

The contents are orthogonal to the issue of the format of the response 
code.  Since the CAP server/client is going to look at the statdesc and 
extdata (maybe) as well as the statcode, you can specify in CAP what the 
CAP values should be.  This will have no effect on the (reused!) parser 
since it will just parse out the parts of the reply and then the CAP 
engine can deal w/them.

>I do care if they are of a know computer parsable format:

statcode = 2.0
statdesc = [email-masked]
extdata  = <NULL DATA>

>Is not useful if you need to know the users UPN.

Actually the extra verbose text of "your UPN is" is not necessary and 
neither is the extra text... 

statcode = 2.0
statdesc = [email-masked] (or "your UPN is [email-masked]" if you want 
to use the original text)
extdata  = extra text (OPTIONAL so it is not necessary here either and 
could be <NULL DATA>.)

Since the CAP server is formatting the response code for a CAP client, it 
would simply create the first example and not put in the extra stuff in 
the second one.  Even if it did add "extra text", so what?  It is optional 
and only of use in some statcode cases.  The CAP client could (and 
probably should) ignore it in the examples above since it was not an error 
or failure case...

>So, I think we could use a similar format. 

My original toughts!

>But I don't think

Imprecise statement on my part and assumptions on the part of others.  My 
most recent suggestion to Lisa was "... the current RFC 2445 format for Response-Status cannot be used.".  I should have been clearer there.  However, in attempt to sanity check 
my postings I revisited my _original_ reply to Andre (05/17/99 06:46:06 PM GMT) and it clearly states:

(For those out there who are not sure; Im not advocating the ENTIRE reuse
of this property and it params, etc, just the format of the 'value' part;
statcode ';"...)

so now I feel partly vindicated and less humbled.  We seem to have 
achieved rough concensus Id say...  On to Oslo!  (At least for some of you 
lucky folks!)

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 8 Jul 1999 12:46:28 -0700 (PDT)

No