Subject: Re: Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT

From: "greg fitzpatrick" <[email-masked]>
Date: Fri, 15 Oct 1999 21:38:01 +0100

Doug writes:
One of the mechanisms in iCalendar and the ATTENDEE is that it is a
>list of who is to be notified of changes to the event (Date/Time, place,
...).
>
>Would they be notified of changes? If the answer is NO, then I see
>your point. If however it is YES, then they also need to be an ATTENDEE
>or they will not be notified of changes.

Then we are in agreement.  These people are completely out of the calendar
chain.

And when it comes to ATTENDEE - I think it was Paul Hill, who had the
brilliant idea of using that property for event info subscription.  In a way
where prospective event goers could subscribe to updates.  What a field day
for promoters:-) 

----------
>From: Doug Royer <[email-masked]>
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: Subject: Comments: Draft-many-ical-ski DIPROLE vs PARTSTAT
>Date: fre 15 okt 1999 17.40
>

>
>
>greg fitzpatrick wrote:
>
>> A DIT is a "by Description Identifiable Thing" and a DIP is a "by
Description
>> Identifiable Person". A DIPROLE is the role of a person or person present
at
>> an event, e.g. actor, award respondent, MC, Parade Marshall, ... hostess,
>> salesperson etc.
>> 
>> A DITROLE is the role of a thing at an event and should among other
things
>> convey whether the DIT is actually present at the event, e.g. "'99 model
cars"
>> or referred to in its absence, e.g. the "Holy Grail", "the works of
Picasso".
>> DITROLE tells us if the DIT is being played on or x-rayed, blown-up,
being
>> sold, on-display, unveiled, launched etc.
>> 
>> Now Doug suggests partstat which is defined as:
>>
>> Perhaps Doug meant ROLE, but there is still a problem with the definition
of
>> ROLE;
>
>Yes I did - thanks.
>
>> (from RFC 2445) ROLE - Purpose: To specify the participation role for the
>> calendar user specified by the property.
>> 
>> We see these parameters as part of the calendar mechanism, which should
be
>> reserved for the purposes of reservations, bookings and confirmations and
not
>> for describing the "cast" or the "orchestra" or "the football team"
>> 
>> Neither do we feel that ATTENDEE should be stretched to cover what we
intend
>> DIP to cover.
>
>One of the mechanisms in iCalendar and the ATTENDEE is that it is a
>list of who is to be notified of changes to the event (Date/Time, place,
...).
>
>Would they be notified of changes? If the answer is NO, then I see
>your point. If however it is YES, then they also need to be an ATTENDEE
>or they will not be notified of changes.