Subject: SV: SKiCal & Roles

From: "Greg FitzPatrick" <[email-masked]>
Date: Sun, 12 Nov 2000 20:39:20 +0100

At a recent SKiCal meeting we went through the comments that were brought
forth by our last call to this list.  We were in agreement that the only
reason for adding three additional property parameters was to avoid conflict
with 2445.  Bruce who brought this to our attention had  written:

Bruce Kahn:

Ok, I revisited SKiCal draft for another pass or two.  One quick thing that
popped out was the addition of "DIPROLE", "DITROLE" and "DITHROLE" to the
current "ROLE" property parameter.  I'm 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).

To which we 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.  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.

...

shortly afterwards a typo was discovered by Marin Neimeier in 2445
Chapter 5 iCalendar Object Examples (on Page 136)

ORGANIZER;ROLE=CHAIR:MAILTO:[email-masked]

Which sort of highlights the fact that ROLE is quite constrained as to its
intended use.

So for one last time I would like to hear everyone's opinion - should we
create these three new property parameters or reuse ROLE as it was not
intended to be used?