CAP-12: Bad changes to REQUEST-STATUS

I see in the published CAP-12 draft that there is still a section for 
changes to REQUEST-STATUS.  Besides being incorrectly listed under Section 
8  New Properties (REQUEST-STATUS is _not_ a new property) the proposed 
change has no technical need for CAP or any actual WG discussion. 

The biggest problem I see with Section 8.28 REQUEST-STATUS property is a 
change to the base iCalendar REQUEST-STATUS defintion that is NOT 
backwards compatible effectively making the current iCalendar/iTIP/iMIP 
implementations unable to send/receive a CAP iCalendar stream (and would 
make a CAP parser treat a valid 2445 REQUEST-STATUS as incomplete).

The current 2445 ABNF for REQUEST-STATUS is:

     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
     ;Textual status description

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

     text       = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
     ; Folded according to description above

(text added for reference).  The proposed new ABNF for REQUEST-STATUS is:

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

Essentially the change is to _require_ the addition of an extra semicolon 
on REQUEST-STATUS.  This has never been identified as a problem nor has 
there been any justification for this non-backwards compatible change even 
though the issue has been pointed out at least 2 times before now.  Since 
statdesc is text and that can be 0 or more characters there is no actual 
need to change the ABNF to make statdesc optional; it can be derived 
already using the 2445 ABNF.

Even the examples shown immediately below the text are incorrect given the 
changed ABNF:

   REQUEST-STATUS:2.0;Success

violates the proposed ABNF.  It MUST have a trialing semicolon after 
"Success".  The same goes for ALL the other examples.

I have no problems with the clear need for adding new classes of 
REQUEST-STATUS values (under statcode) but I do have a BIG problem with 
making an unnecessary change like this thats not backwards compatible AND 
fixes NO problem.

I propose that we simply remove Section 8.28 entirely since it does 
nothing to describe the new changes it mentiones on page 17:

   REQUEST-STATUS -  The [iCAL] "REQUEST-STATUS" property is extended to
      include new error numbers. (Section 8.28)

or at a minimum we restore the RFC 2445 ABNF and just use Section 8.28 to 
provide a description of the new statclasses (as promised last Feb) 
instead.  At least RFC 2445 had a desription of the classes that we need 
for CAP.  Here is a snippet from 2445 that we need in CAP:

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

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