Re: SV: SKiCal & Roles

[Bruce_Kahn@xxxxxxxx]

Greg replied:
>Our philosophy has always been not to bend the properties and parameters of
>RFC2445 out of their intended uses and end up creating ambiguity.  

I dont think you are really bending iCalendar by reusing "ROLE".  Check for yourself:

4.2.16 Participation Role

   Parameter Name: ROLE

   Purpose: To specify the participation role for the calendar user
   specified by the property.

Well, isn't that exactly what you are describing in your examples??:

    PERSONS;DIPROLE=REFERENCED:Marilyn Manson 
    PERSONS;DIPROLE=CREATOR:Beethoven, Ludwig van 
...
    THINGS;DITROLE=FOR-HIRE:Golf clubs 
    THINGS;DITROLE=PRESENT:Car models of 2001 
    THINGS;DITROLE=DEMONSTRATED:Electrolux refrigerator door computers 

The only hair to split is that the 'calendar user' is not a cal-addr data type but rather some textual 'tag' associated to that kind of property... However thats a very tiny hair to try and split.

>                                                                   Nor have
>we felt that it was a good idea to try to change 2445 merely to accommodate
>SKiCal

iCalendar was designed to be extensible so that anyone could build upon it.  Hence the use of x-name and iana-token in much of the ABNF.  As long as you dont not change the existing meanings (ie: REQ-PARTICIPANT is not a "required participant" in SKiCal but rather a caterer...) then I do not see any problem w/that.  Anyone else see one??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@xxxxxxxx
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...