Subject: Re: REQUEST-STATUS errors and issues for CAP

From: [email-masked]
Date: Fri, 14 Mar 2003 11:44:55 -0500

On 02/22/2003 06:33:16 PM MST Doug wrote (but noone responsed to):
>   (2) A note that says that REQUEST-STATUS is optional on success.
>       I propose that REQUEST-STATUS not be optional in CAP for
>       replies.

I like this idea.  No need for waffling.  If it failed we let them know. 
If it worked we should also let them know.  After all its only about 18-20 
octets more in the overall data stream. 

However you MUST be careful in how you mandate it so that you do not 
preclude CAP->iTIP fallback in the future (ie: CAP 3.x) since iTIP does 
not mandate REQUEST-STATUS always.

> [NOTE] Sections 3.2.3 and 3.4.4 seem to conflict with each other
> [NOTE] and section 3.6 "Status Replies" with respect to error
> [NOTE] code "5.3".
> [NOTE]
> [NOTE] I think that the "5.3" error code in section 3.4.4 of iTIP
> [NOTE] should say "3.14". Agree?

First off, as was noted many many moon ago there is NO 5.x class 
definition in RFC 2445 so:

1: There should be no 5.x error codes in 2446 OR
2: We need to clearly define what the 5.x error codes are used for in 2445 
in the same way that the other codes are defined:

      | Short Return | Longer Return Status Description              |
      | Status Code  |                                               |
      |==============+===============================================|
      |    1.xx      | Preliminary success. This class of status     |
      |              | of status code indicates that the request has |
      |              | request has been initially processed but that |
      |              | completion is pending.                        |
      |==============+===============================================|
      |    2.xx      | Successful. This class of status code         |
      |              | indicates that the request was completed      |
      |              | successfully. However, the exact status code   |
      |              | can indicate that a fallback has been taken.  |
      |==============+===============================================|
      |    3.xx      | Client Error. This class of status code       |
      |              | indicates that the request was not successful.|
      |              | The error is the result of either a syntax or |
      |              | a semantic error in the client formatted      |
      |              | request. Request should not be retried until  |
      |              | the condition in the request is corrected.    |
      |==============+===============================================|
      |    4.xx      | Scheduling Error. This class of status code   |
      |              | indicates that the request was not successful.|
      |              | Some sort of error occurred within the        |
      |              | calendaring and scheduling service, not       |
      |              | directly related to the request itself.       |

I expect there to be a class 5 error defintion for something like "Server 
Error" or "Service Error" to convey things like "Server internal error" or 
"Server shutting down.  No further commands allowed", etc.  This is 
something we need for CAP but did not need for iTIP when we only focused 
on iMIP usages.  However I have yet to see any kind of prose to this 
effect in CAP (see other threads of late).

Secondly 3.14 is defined in 2446 as:

| 3.14         | Unsupported capability     | Method or action MAY    |
|              |                            | be specified            |

and 5.3 is defined as:

| 5.3          | No scheduling support for  | ATTENDEE property value |
|              | user.                      | MAY be specified.       |

The former means that the METHOD used is unsupported entirely.  The latter 
means that a particular ATTENDEE cannot perform workflow (aka Scheduling). 
 It does not mean they cannot perform Calendaring.  The rest of the 
ATTENDEEs have no problem performing workflow.  The former is scoped to 
the iTIP message entirely.  The latter is scoped to a particular ATTENDEE. 
 Given this I would say that merging 5.3 and 3.14 is NOT the propery 
action.

Im not sure we should collapse them down given the strict definition of a 
class 3 error code.  It is clearly defined as "The error is the result of 
either a syntax or a semantic error in the client formatted request.". The 
inability of an ATTENDEE to perform workflow is NOT this kind of error. In 
looking at the 2445 definitions I think that merging it into 4.x is more 
accurate.  Heres why:

1: The 4.x error code is defined as "Some sort of error occurred within 
the calendaring and scheduling service, not directly related to the 
request itself."  This would easily match the analysis of the intent of 
5.14; a particular user cannot perform "scheduling".
2:The problem described by 5.3 is "No scheduling support for user" and 
error class 4 is defined generally as "Scheduling Error".

Perhaps 5.3 should become 4.1 since we only seem to have defined 4.0 in 
iTIP.

> [NOTE] So I propose that in CAP we specify that code '3.14' means
> [NOTE] that the "Attendee" calendar does not support the ADD method
> [NOTE] for any component type,

Why redefine 3.14 for just the ADD method??  It is equally valueable for 
those that do not support COUNTERs or other METHODs (even those TBD by CAP 
or some new effort).  I see no benefit in narrowing 3.14 down to just 
"ADD".  Also, I think this change would redefine the semantics of a clas 3 
error code from being "a semantic error" to being "ADD not supported" and 
thats clearly NOT how 3.x is defined.

Do not touch 3.14 for CAP, its use and meaning is already relatively clear 
and usable.  Its 5.3 we need to focus on instead.

>                                 and that code "5.3" means that the
> [NOTE] calendar does not support ANY scheduling - that is NO METHOD
> [NOTE] values may be deposited in to the calendar. If it is attempted
> [NOTE] then CS replies with 5.3, and they are not deposited.

See above first about reclassifying 5.3 as 4.x.

Next, 5.3 says that "scheduling" is not supported by the user".  It does 
NOT say that Calendaring is not supported.  That is, the user can still do 
PIM stuff, just no workflow.  I dont think we should include Calendaring 
as part of the error code semantics.  After all, if the user cannot do 
Calendar OR Scheduling then why the hell would they even use CAP (or would 
they even have a CAP server login)????

> [NOTE] Existing implementations should not be effected as they
> [NOTE] do not interact with CAP. 

Error codes of 3.x and 4.0 are NOT CAP specific and should be supported 
and used by any existing implementation.  As such we cannot just 
arbitrarily redefine the definition of 3.14 (without need!). 

>                                    I further think we need to
> [NOTE] specify that CUA's only use 5.3 when the CS does not
> [NOTE] support ANY scheduling and 3.14 when the CS does not
> [NOTE] support the ADD method.

Again, if the CUA cannot perform any Calendaring or Scheduling then they 
surely do not use CAP since they essentially could do NOTHING!

> ITIP: 3.2.4 ADD
> 
> 
>     The "UID" must be that of the existing event. If the "UID" property
>     value in the "ADD" is not found on the recipient's calendar, then 
the
>     recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
>     updated with the latest version of the "VEVENT".  If an "Attendee"
>     implementation does not support the "ADD" method it should respond
>     with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".

This is correct.  The same applys for COUNTERs and DECLINE-COUNTERs 
(although not supporting a DECLINE-COUNTER but supporting COUNTER is kinda 
odd!).  It equally applys to any as yet undefined METHODs that a CUA could 
generate and send.

> ITIP: 3.4.4 ADD
> 
>     If the "UID" property value in the "ADD" is not found on the
>     recipient's calendar, then the recipient SHOULD send a "REFRESH" to
>     the "Organizer" in order to be updated with the latest version of 
the
>     "VTODO". If an "Attendee" implementation does not support the "ADD"
>     method it should respond with a "REQUEST-STATUS" value of 5.3 and 
ask
>     for a "REFRESH".

This is incorrect.  (Imagine that, a mistake in the RFC?!?!)  The VTODO 
prose should mirror that of the VEVENT.  It could be that the change from 
5.3 to 3.14 did not get fully applyed to iTIP prose and that left 5.3 
around (along w/the rest of the 5.x error codes).  After 255+ pages I 
guess noone was coherent enough to notice during Last Call.

> [NOTE] An interesting note in iTIP about REQUEST-STATUS being optional
> [NOTE] on success. I propose that in CAP that REQUEST-STATUS be
> [NOTE] mandatory!

In looking at Section 3.6 of iTIP I cannot see ANY prose that indicates 
this.  The restriction tables for each METHOD determine this and I think 
all but PUBLISH have "REQUEST-STATUS 0+".  I cannot recall any 
justification for not having 1+ on at least the REPLY message but perhaps 
that was another oversight.

One thing to consider, if you are going to PUBLISH your calendar then 
REQUEST-STATUS has NO meaning as there is NOT workflow involved.  As such 
mandating it in CAP for PUBLISHes is non-sensical.

> iTIP: 4.2.2 Reply To A Group Event Request
> 
>     "B" could have declined the meeting or indicated tentative 
acceptance
>     by setting the "ATTENDEE" "partstat" parameter to "declined" or
>     "tentative", respectively. Also, "REQUEST-STATUS" is not required in
>     successful transactions.

Again, either noone saw it or we just thought leaving it out was ok.  Do 
you recall why we took this approach??

>          IMIP / 2447
> 
> [NOTE] NO 'REQUEST-STATUS' is defined in 2447.

Thats because iMIP is just a binding of iTIP and iTIP does the acutal 
content definition.  iMIP just says how to bundle and send an iTIP message 
over email.

BTW: In case we didnt cover this before, in 2446 we have:

| 5.0          | Request MAY supported.     | Method property value   |
|              |                            | MAY be specified.       |

but its gramatically incorrect AND its use is totally vague/indeterminate. 
 Unless we can figure out what 5.0 is intended for and better describe it 
we should probably remove it from iTIP (or reuse it and redefine it in 
CAP)

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...