Subject: Re: Attendee clarification

From: [email-masked]
Date: Fri, 11 May 2001 16:45:48 -0400

John wrote on 05/11/2001 04:17:15 PM:
> No.  My objection is this: if you want to do scheduling, you need
> feedback from the recipients, to find out whether or not they're
> going to attend the meeting. 

Since an RSVP is not something that can coerce the CU to do anything, you 
wont get feedback from me anyway unless I want you to.  However, for my 
lunch case where I do not need it, I do no like the thought of having to 
make my co-eater a NON-PARTICIPANT just because someone cannot answer my 
questions.  So I will ask a 4th time (or is it 5th yet): 

So _PLEASE_ explain to me why my CUA would automagically send a REPLY to your 'typo' 
fix when my ATTENDEE value and property parameters (ie: 
PART-STAT=Accepted) are the same?  There is _NO_ need for it to so it shouldn't.  So why would the Organizer need/want to 
set RSVP=FALSE for just that iTIP message??  They have none!  

Or perhaps another way to ask is: Why should the Organizer put RSVP=FALSE 
on the typo update at all unless they had no need/desire to hear back at 
all?

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: Fri, 11 May 2001 17:02:05 -0400

[email-masked] wrote:

> Since an RSVP is not something that can coerce the CU to do
> anything, you wont get feedback from me anyway unless I want
> you to.

Sure--and then I can't believe that the meeting is scheduled.
But that wasn't the topic; we were discussing calendar systems
which don't *allow* you to send that feedback.

> So _PLEASE_ explain to me why my CUA would automagically send a
> REPLY to your 'typo' fix when my ATTENDEE value and property
> parameters (ie: PART-STAT=Accepted) are the same?

You're changing the subject.  You stated that the reasoning
behind the design of RSVP included a desire to support systems
that can't implement RSVP; I pointed out that such systems were
not doing scheduling.  The typo-fix is another thread.

In addition, I'm not convinced that a typo fix shouldn't require
new responses from the attendees.  How is the protocol supposed
to distinguish between typo fixes and other changes? You can
leave it up to the ORGANIZER; but maybe the ORGANIZER didn't
realize that the original typo changed the meaning of the message
so much that the recipients' original decision to attend is
invalid.  (For example, suppose I accept an invitation saying
"SUMMARY:Birthday Party for Joanie", and the typo is that it
should have been "Janie"; I like Joanie but can't stand Janie.
It's not up to the ORGANIZER to decide whether I still want to
come.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Collect call from reality, will you accept  |
[email-masked]|the--" *click*                               |
\==============================================================/