Subject: REQUEST-STATUS errors and issues for CAP

From: Doug Royer <[email-masked]>
Date: Sat, 22 Feb 2003 18:33:16 -0700

I have started adding / checking status code replies for CAP
and found 2 issues (detail below).

  (1) Conflict in iTIP over REQUEST-STATUS - 3.14 and 5.3 codes.
      See my [NOTE]s below for my proposal.

  (2) A note that says that REQUEST-STATUS is optional on success.
      I propose that REQUEST-STATUS not be optional in CAP for
      replies.

--> My comments are marked with [NOTE].

The following REQUEST-STATUS codes are documented in RFC-244[567]:
--------------------------------------------------------------------

			ICAL / 2445

ICAL: 4.8.8.2 Request Status

     ...

      |==============+===============================================|
      | 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.       |
      |==============+===============================================|

--

[NOTE] The rest of the values used in 2445 are examples and need
[NOTE] not be an exact match (by just reading 2445), shown here:

    Example: The following are some possible examples of this property.
    The COMMA and SEMICOLON separator characters in the property value
    are BACKSLASH character escaped because they appear in a  text value.

      REQUEST-STATUS:2.0;Success

      REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01

      REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
       as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2

      REQUEST-STATUS:4.1;Event conflict. Date/time is busy.

      REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
       MAILTO:[email-masked]

-----------------------------------------------------------------------

			ITIP / 2446

[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?
[NOTE]
[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, 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.
[NOTE]
[NOTE] Existing implementations should not be effected as they
[NOTE] do not interact with CAP. 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.

--

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

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

--
ITIP: 3.6 Status Replies

|==============+============================+=========================|
| Short Return | Longer Return Status       | Offending Data          |
| Status Code  | Description                |                         |
|==============+============================+=========================|
| 2.0          | Success.                   | None.                   |
|==============+============================+=========================|
| 2.1          | Success but fallback taken | Property name and value |
|              | on one or more property    | MAY be specified.       |
|              | values.                    |                         |
|==============+============================+=========================|
| 2.2          | Success, invalid property  | Property name MAY be    |
|              | ignored.                   | specified.              |
|==============+============================+=========================|
| 2.3          | Success, invalid property  | Property parameter name |
|              | parameter ignored.         | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 2.4          | Success, unknown non-      | Non-standard property   |
|              | standard property ignored. | name MAY be specified.  |
|==============+============================+=========================|
| 2.5          | Success, unknown non       | Property and non-       |
|              | standard property value    | standard value MAY be   |
|              | ignored.                   | specified.              |
|==============+============================+=========================|
| 2.6          | Success, invalid calendar  | Calendar component      |
|              | component ignored.         | sentinel (e.g., BEGIN:  |
|              |                            | ALARM) MAY be           |
|              |                            | specified.              |
|==============+============================+=========================|
| 2.7          | Success, request forwarded | Original and forwarded  |
|              | to Calendar User.          | caluser addresses MAY   |
|              |                            | be specified.           |
|==============+============================+=========================|
| 2.8          | Success, repeating event   | RRULE or RDATE property |
|              | ignored. Scheduled as a    | name and value MAY be   |
|              | single component.          | specified.              |
|==============+============================+=========================|
| 2.9          | Success, truncated end date| DTEND property value    |
|              | time to date boundary.     | MAY be specified.       |
|==============+============================+=========================|
| 2.10         | Success, repeating VTODO   | RRULE or RDATE property |
|              | ignored. Scheduled as a    | name and value MAY be   |
|              | single VTODO.              | specified.              |
|==============+============================+=========================|
| 2.11         | Success, unbounded RRULE   | RRULE property name and |
|              | clipped at some finite     | value MAY be specified. |
|              | number of instances        | Number of instances MAY |
|              |                            | also be specified.      |
|==============+============================+=========================|
| 3.0          | Invalid property name.     | Property name MAY be    |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.1          | Invalid property value.    | Property name and value |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 3.2          | Invalid property parameter.| Property parameter name |
|              |                            | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.3          | Invalid property parameter | Property parameter name |
|              | value.                     | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.4          | Invalid calendar component | Calendar component      |
|              | sequence.                  | sentinel MAY be         |
|              |                            | specified (e.g., BEGIN: |
|              |                            | VTIMEZONE).             |
|==============+============================+=========================|
| 3.5          | Invalid date or time.      | Date/time value(s) MAY  |
|              |                            | be specified.           |
|==============+============================+=========================|
| 3.6          | Invalid rule.              | Rule value MAY be       |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.7          | Invalid Calendar User.     | Attendee property value |
|              |                            |MAY be specified.        |
|==============+============================+=========================|
| 3.8          | No authority.              | METHOD and Attendee     |
|              |                            | property values MAY be  |
|              |                            | specified.              |
|==============+============================+=========================|

| 3.9          | Unsupported version.       | VERSION property name   |
|              |                            | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.10         | Request entity too large.  | None.                   |
|==============+============================+=========================|
| 3.11         | Required component or      | Component or property   |
|              | property missing.          | name MAY be specified.  |
|==============+============================+=========================|
| 3.12         | Unknown component or       | Component or property   |
|              | property found             | name MAY be specified   |
|==============+============================+=========================|
| 3.13         | Unsupported component or   | Component or property   |
|              | property found             | name MAY be specified   |
|==============+============================+=========================|
| 3.14         | Unsupported capability     | Method or action MAY    |
|              |                            | be specified            |
|==============+============================+=========================|
| 4.0          | Event conflict. Date/time  | DTSTART and DTEND       |
|              | is busy.                   | property name and values|
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.0          | Request MAY supported.     | Method property value   |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.1          | Service unavailable.       | ATTENDEE property value |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.2          | Invalid calendar service.  | ATTENDEE property value |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.3          | No scheduling support for  | ATTENDEE property value |
|              | user.                      | MAY be specified.       |
|==============+============================+=========================|

--

[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!

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.

--
iTIP: 5.1.2 Free/Busy-Related Fallbacks

Method           Fallback
--------------   -----------------------------------------------------
PUBLISH          Implementations MAY ignore the METHOD type. The
                  REQUEST-STATUS "3.14;Unsupported capability" MUST be
                  returned.
REQUEST          Implementations MAY ignore the METHOD type. The
                  REQUEST-STATUS "3.14;Unsupported capability" MUST be
                  returned.
REPLY            Implementations MAY ignore the METHOD type. The
                  REQUEST-STATUS "3.14;Unsupported capability" MUST be
                  returned.

--
5.1.4 Journal-Related Fallbacks

Method           Fallback
--------------   -----------------------------------------------------
PUBLISH          Implementations MAY ignore the METHOD type. The
                  REQUEST-STATUS "3.14;Unsupported capability" MUST be
                  returned.
ADD              Implementations MAY ignore the METHOD type. The
                  REQUEST-STATUS "3.14;Unsupported capability" MUST be
                  returned.
CANCEL           Implementations MAY ignore the METHOD type. The
                  REQUEST-STATUS "3.14;Unsupported capability" MUST be
                  returned.
-----------------------------------------------------------------------

			IMIP / 2447

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

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards