Re: Attendee clarification

[Bruce_Kahn@xxxxxxxx]

sman wrote on 05/02/2001 10:23:13 AM:
> 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. 

The intent of RSVP is to convey the Organizers desire for a response to the Invitees.  Since not all C&S systems support a mechanism of selectively asking for RSVPs (or do not support 'em at all) we could not say "If RSVP=TRUE then the ATTTENDEE MUST send back a reply of some kind.  If RSVP=FALSE then the ATTENDEE MUST NOT send back a reply of some kind."  This lack of a feature was also why FALSE was selected as the default (so that less robust systems did not have to add it for every msg).

So, the way that TRUE and FALSE should be interpreted is this:

TRUE: The Organizer wants some kind of a response back (eventually) so the ATTENDEE SHOULD send back a reply when their PART-STAT changes (or they want to COUNTER) or if their ATTENDEE info/settings are not the same as the ones the Organzier sent; assuming they support the workflow model of REPLY, etc.  Obviously this cannot be a MUST since those recipients w/non RSVP supporting systems cannot.  Perhaps we need to make it a MUST feature for those that support the concept and a SHOULD for those that do not but Im not sure if that is Kosher to do in an RFC...

FALSE: The Organizer does not want any kind of response back in response to the message so the ATTENDEE SHOULD NOT send back any kind of reply.  

WRT to Steves examples I think they are close but not quite correct.  It is not possible to distinguish between "I never want to hear a response back from you" and "I do not want a response from you _for this message only_".  That is, the Organizer does not care to really hear from you on a minor update (ie: a typo fix somewhere) but they DO want to hear back if you plan to attend or not.  Since the Organizer sent an RSVP=FALSE on the typo change, the ATTENDEE has no way to know if that is a permanent change or not to their RSVP setting.  As such, the ATTENDEE would (MUST) not send back any further replys.  This means that if the ATTENDEE later decides to ACCEPT or DECLINE, they MUST not send a REPLY back to the Organizer.  I do not think that this was Steves intent.

This is also why the interpretation of TRUE includes the bit about differing ATTENDEE info/parameters.  It could be that the Organizer never got my REPLY where I accepted so this provides me a hint that I may need to resend my acceptance notice.  It may be that the Organizer did not (yet) get the delegation notice I sent 3 days ago so I need to resend it.  I think you see the motivation why.

Guess we need some better wordsmithing to codify this intent in the next update.  Anyone have concerns/questions about this clarifcation?

Oh yes, one extra tidbit we can include here.  For ROLE=NON-PARTICIPANT the RSVP setting SHOULD be ignored (or really should be set to FALSE always) since by definition they are not part of the scheduling process.  Its a logical thing but I wanted to express it outright to make sure we agree on that too...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@xxxxxxxx
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...