Subject: SKiCal & Roles

From: [email-masked]
Date: Wed, 6 Sep 2000 22:26:16 -0400

Ok, I revisited SKiCal draft for another pass or two.  One quick thing 
that poped out was the addition of "DIPROLE", "DITROLE" and "DITHROLE" to the current "ROLE" property parameter.  Im more than a bit curious 
why these new property parameters are necessary instead of just reusing 
"ROLE" on the new properties and adding new values.  We already have some 
precedence for that in RFC 2445.  In section 4.2.12 Participation Status we defined the allowed values for PARTSTAT for each component type (ie: 
the vEvent list is different from the vToDos, etc). 

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 8 Sep 2000 14:45:08 +0200

Thanks Bruce

Our philosophy has always been not to bend the properties and parameters of
RFC2445 out of their intended uses and end up creating ambiguity.  Nor have
we felt that it was a good idea to try to change 2445 merely to accommodate
SKiCal, though we did make some suggestions to that effect originally.

In this particular case we would have to for starters change
4.2.16 Participation Role, since the properties concerned are not
necessarily
of a CAL-ADDRESS value type.  And we would have to do something about the
default value of the property being "REQ-PARTICIPANT"

see below

 "4.2.16 Participation Role - Description: This parameter can be specified
on properties with a CAL-ADDRESS value type. The parameter specifies the
participation role for the calendar user specified by the property in the
group schedule calendar component. If not specified on a property that
allows this parameter, the default value is REQ-PARTICIPANT."

Though I agree that simplified term "ROLE" would suffice in denoting the
role of a person, thing or theme in an event if it was coupled to the
respective properties of PERSONS, THINGS, and THINKS, it is quite a stretch
on the original intention for "ROLE" in 2445.

This is a reoccurring problem for SKiCal, but the benefits are that SKiCal
does not confuse applications "tuned" for iCal.

Bruce Kahn:

Ok, I revisited SKiCal draft for another pass or two.  One quick thing that
poped out was the addition of "DIPROLE", "DITROLE" and "DITHROLE" to the
current "ROLE" property parameter.  Im more than a bit curious why these new
property parameters are necessary instead of just reusing "ROLE" on the new
properties and adding new values.  We already have some precedence for that
in RFC 2445.  In section 4.2.12 Participation Status we defined the allowed
values for PARTSTAT for each component type (ie: the vEvent list is
different from the vToDos, etc).

Bruce