Re: CAP-12-e: Changing REQUEST-STATUS

Doug replied on 11/10/2003 07:36:41 PM:
> I think it is supposed to be:
> 
>     statcode ";" [ statdesc ] ";" [extdata]

The change was originally proposed by George back on 08/18/2000 04:46:33 
PM AST with the justification label of:

Changes needed by CAP.

When I asked about this need there was no response and thats where it was 
left on 22-Aug-2000. 

Doug had referred to a concern about the language of the contents of 
statdesc but thats secondary to the proposed change (and would affect ALL 
properties in iCal, not just stadesc on REQUEST-STATUS)

As originally noted in 
http://www.imc.org/ietf-calendar/mail-archive/msg00680.html there is no 
need to revise the ABNF from its current state in order to make statdesc 
optional if you properly follow the ABNF in 2445:

Read the ABNF for statdesc and you will see "Textual status description". 
So while the actual contents of that are not mandated (nor are they for 
LOCATION, CLASS, etc) the _kind_ of data is described.  Its up to 
implementations to put in something useful.  See thoughts above on the 
_intent_ of statdesc if still necessary... 

Also, if you really read the ABNF you will see that NULL is also valid! 
The ABNF for statdesc is: 

    statdesc   = text
    ;Textual status description 

and we defined text as: 

     text       = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) 

Note the *() format so NULL is already an option.  The only difference 
between this proposal and the one we already have in RFC 2445 is 
effectively to remove the mandated semicolon after the statcode.  Thats 
it!   

This proposed change to REQUEST-STATUS essentialy boils down to CAP 
wanting to always have the trailing semicolon to delimit the end of the 
optional statdesc.  That is instead of the current:

REQUEST-STATUS:2.0;

a CAP implementation would have to use:

REQUEST-STATUS:2.0;;

This change would be a non-backwards compatible one too.  If CAP cannot 
demonstrate a need for the ABNF to change in iCalendar, it should not be 
done.  Especially if it will break interop with no particular benefit or 
need.

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