Subject: Re: SV: SKiCal & Roles

From: [email-masked]
Date: Tue, 14 Nov 2000 20:14:28 -0500

Greg wrote:
>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.

Adding new values is not necessarily creating ambiguity.  We designed the 
ABNF so that extensions are easily done (as long as they do not directly 
conflict w/prior work).  Hence my original suggestion/question.

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

The former part may be an issue but it is NOT one that affects the reuse 
of ROLE property parameter; its an issue w/the data type of the ATTENDEE 
property.  Its not clear to me _why_ the default value is a real issue since any given value supercedes the 
default one...

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

The original definition was based on the collective views of the roles 
used in "Interpersonal C&S".  SKiCal is a different critter but it still 
needs to convey the same basic intent that the original ROLE was designed 
for.  There is a reason we defined the ABNF with:

     roleparam  = "ROLE" "="
[Snip, snip]
                / x-name                ; Experimental role
                / iana-token)           ; Other IANA role

(so that oversights or additions can easily be done...)

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

Ill go back to the KISS mantra and vote for a reuse.  After all the intent 
is the same, why make parsers / clients do more work than necessary.

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: John Stracke <[email-masked]>
Date: Mon, 20 Nov 2000 10:03:24 -0500

[email-masked] wrote:

> Ill go back to the KISS mantra and vote for a reuse.

And, if it can't be reused, then it probably shouldn't be called
a role at all; too confusing.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"HTTP is what happens in the absence of good |
[email-masked]|design." -- Keith Moore                      |
\==============================================================/

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Tue, 21 Nov 2000 08:37:54 +0100

john wrote :

Any suggestions:-?

"Function" comes to mind.

Greg