Subject: Attendee clarification

From: [email-masked] (Steve Mansour)
Date: Wed, 02 May 2001 07:23:13 -0700

Hey All,

One point of confusion that came up at Calconnect 2 had to do with some
parameters on ATTENDEE. In particular. Because it was an interop issue,
I want to add something to iTIP to clarify how a reconfirmation is
formatted under several circumstances.

When an Organizer sends out an updated event and wants the Attendees to
reconfirm, the ATTENDEE property looks like this (I'm only listing the
relevant parameters, in general there will be more):

     ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:[email-masked]

When the Organizer sends out an updated version of the event and does
not require the Attendees to confirm, it looks like this:

     ATTENDEE;RSVP=FALSE;ROLE=REQ-PARTICIPANT:mailto:[email-masked]

When sending an event to a non-participant (like the 'cc' recipients of
an email message), it looks like this:

     ATTENDEE;RSVP=FALSE;ROLE=NON-PARTICIPANT:mailto:[email-masked]

Does this look correct?

-Steve

---

From: Alan Davies <[email-masked]>
Date: Wed, 02 May 2001 15:12:55 -0400

Looks correct to me. This seems to me to be the correct use
of RSVP and ROLE. There was some discussion though about the
intention of RSVP=FALSE, RFC2445 4.2.17 defines the purpose
of RSVP as

    Purpose: To specify whether there is an expectation of a favor of a
    reply from the calendar user specified by the property value.

I take this to mean that RSVP=TRUE implies that a REPLY should
be sent by the ATTENDEE straight away, whereas RSVP=FALSE
leaves the decision up to the ATTENDEE- they are still allowed
to REPLY (e.g. if they change their attendance status), but are
not required to. Does anyone disagree with this?

--Alan

At 07:23 2001-05-02 -0700, Steve Mansour wrote:
>parameters on ATTENDEE. In particular. Because it was an interop issue, I 
>want to add something to iTIP to clarify how a reconfirmation is formatted 
>under several circumstances.
>
>ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:<mailto:[email-masked]>mailto:[email-masked]
>
>When the Organizer sends out an updated version of the event and does not 
>require the Attendees to confirm, it looks like this:
>ATTENDEE;RSVP=FALSE;ROLE=REQ-PARTICIPANT:<mailto:[email-masked]>mailto:[email-masked]
>
>When sending an event to a non-participant (like the 'cc' recipients of an 
>email message), it looks like this:
>ATTENDEE;RSVP=FALSE;ROLE=NON-PARTICIPANT:<mailto:[email-masked]>mailto:[email-masked]
>
>Does this look correct?
>
>-Steve

---

From: "Graham Gilmore" <[email-masked]>
Date: Fri, 11 May 2001 16:17:32 -0400

So, sifting through the clarifications & whatnot, it would seem that

>      ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:[email-masked]

ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:b@e
xample.com

    The PARTSTAT is "reset" to NEEDS-ACTION if the Organizer really
wants attendees to re-confirm their statuses based on the new
information.

>      ATTENDEE;RSVP=FALSE;ROLE=REQ-PARTICIPANT:mailto:[email-masked]

    ATTENDEE;PARTSTAT=<whatever status the organizer currently has for
this attendee>;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:[email-masked]

    The PARTSTAT is left as-is, reflecting any replies (RSVP's) that the
Organizer has received to date.  So, Attendees who receive the update
and agree with their currently listed PARTSTAT need not send a reply,
whereas those who wish to change their PARTSTAT should send a reply.

>      ATTENDEE;RSVP=FALSE;ROLE=NON-PARTICIPANT:mailto:[email-masked]

    ATTENDEE;ROLE=NON-PARTICIPANT:mailto:[email-masked]

    As Bruce mentioned, as the Attendee is not participating in the
event, the Attendee has no meaningful PARTSTAT and thus there is no need
to include the RSVP parameter.

    Does this make sense to everyone?

    Graham