Subject: CAP-12: Bad changes to REQUEST-STATUS

From: [email-masked]
Date: Mon, 19 Jan 2004 13:03:26 -0500

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-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Mon, 19 Jan 2004 12:55:22 -0700

[email-masked] wrote:

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

Read the archives and you will find that YOU posted the following on the
subject of CAP as part of the the error code debate.
 
  "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.".

  [and we assumed you meant REQUEST-STATUS as there is no 'RESPONSE-STATUS']

There was no unilateral change or addition to CAP even i f the the
text entered was or was not exactly what you posted.

Now you seem to be saying that it can be used. "as is".
That is fine, but please do not say there was no actual WG discussion as
you participated in that actual WG discussion. (that is just one
of several posts you made on the subject)

So what are you now saying?

Also, it is not a compatibility issue as ALL iTIP messages must be first 
processed
by a CUA and in many cases already tweaked for the CS. And yes I agree
it would be a pain, but as no CS objects exist yet, it can not be a 
compatibly
issue.

So as it has been in CAP for a while and the chairs have not called any
consensus to change it, and as it was discussed, and as it is not in
the action item list (bugzilla); I for one can not unilaterally change
it back to be the current RFC 2445 format for Request-Status.

Does anyone else care which format we use?

AND:  I have entered a bugzilla issue to move it FROM the 'new' 
properties section.

-- 

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

              We Do Standards - You Need Standards