Subject: Subject: Registration of text/calendar MIME property REQUEST-STATUS

From: George Babics <[email-masked]>
Date: Fri, 18 Aug 2000 16:46:33 -0400

Note: The changes that were made to this iCAL property:
      1) statdesc is now optional
      2) more examples were added
      3) can be specified in any calendar component

      Changes needed by CAP.

-------------------------------------------------------------------
   
   To: [email-masked]

   Subject: Registration of text/calendar MIME property REQUEST-STATUS
   
   Property name: REQUEST-STATUS

   Purpose: This property defines the status code returned for a
   scheduling request.

   Value type: TEXT

   Property parameters: Non-standard and language property parameters
   can be specified on this property.

   Conformance: the property can be specified in any calendar component.

   Description: This property is used to return status code information
   related to the processing of an associated iCalendar object. The data
   type for this property is TEXT.

   The value consists of a short return status component, a longer
   return status description component, and optionally a status-specific
   data component. The components of the value are separated by the
   SEMICOLON character (US-ASCII decimal 59).

   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.

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

   Format Definition: The property is defined by the following notation:

   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)

                   )

   statcode    = 1*DIGIT *("." 1*DIGIT)
                 ;Hierarchical, numeric return status code

   statdesc    = text
                 ;An optional textual status description, content is
                 ;decided by the implementor. May be empty.

   extdata    = text
                ;Textual exception data. For example, the offending property
                ;name and value or complete property line.

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

   REQUEST-STATUS:2.0;Success

   REQUEST-STATUS:2.0;Success despite braindead LDAP implementation

   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]

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

   REQUEST-STATUS:10.4;Help!  That really shouldnt have happened.

---

From: [email-masked]
Date: Tue, 22 Aug 2000 11:54:59 -0400

Doug noted:
>The idea was that when nothing is needed, why add something
>just to fill in the ABNF. The 'NULL' description would
>serve the same purpose.

That is already allowed via the ABNF.

>I think that "REQUEST-STATUS:2.0;" would be acceptable.

If that is the case, then it sounds like this proposal can be withdrawn.

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: [email-masked]
Date: Tue, 22 Aug 2000 12:04:02 -0400

Errp, spoke a bit too quickly that last time.  Im for removing the 
portions of the proposal that do an ABNF change.  I am FOR keeping the 
changes relating to more examples and allowing REQUEST-STATUS to be in 
other components.

Bruce