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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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