Subject: Re: Attendee clarification

From: [email-masked]
Date: Fri, 11 May 2001 17:34:37 -0400

John replied on 05/11/2001 05:02:05 PM:
> > 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.

<TRYING TO HOLD FRUSTRATION AT BAY>
No I didnt.  Doesnt anyone actually read the text that gets posted??  I 
said that the reason the terms MUST/MUST NOT etc were not in the text was 
that it would have been impossible for some vendors to implement and if it 
were mandated then a CUA that could support it would expect the 
non-supporting CUA to senda  reply that it could NEVER generate.

Im not changing the subject either.  It was stipulated that the Organizer 
needed to set RSVP=FALSE on a typo update to avoid triggering the 
invitee's CUA from sending a reply (that smells a lot like...)  Given my 
clarification text about TRUE vs FALSE (that some have yet to at least 
read it seems) then the question I ask is _DIRECTLY_ on the subject.  Your argument was that a system that does not have the 
RSVP concept is not a C&S system, its a C system.  Thats orthogonal to the 
intended meaning of RSVP...
</TRYING>

> In addition, I'm not convinced that a typo fix shouldn't require
> new responses from the attendees.

If nothing about the event has signficantly changed (ie: If the Organizer 
thinks Im going or not) but rather the change was simply trivail (ie: 
"SUMMARY: Confarence call" -> "SUMMARY:Confence call") then I dont need to 
respond.  Even if the change was to fix the dial in information; my 
participation status has not changed and Im not going to counter w/a new 
time for that either.  So, riddle me this Batman: Why would I need to 
response w/a new REPLY for this case? 

>                   How is the protocol supposed
> to distinguish between typo fixes and other changes? 

I wont do an iCalendar 101/102 for you but I will use sarcasm since thats 
all I have left at 5PM on a Friday.  The CUA has a full snapshot copy of 
the REQUEST from when it was first sent (or later updated).  It also has 
the new REQUEST that is also a full snapshot.  Presumably the CUA is going 
to be able to parse the REQUEST and will be able to detect changes, 
deletions and additions.  Thats how we've talked about doing it for over 3 
years now...

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

I have no clue where you pulled that last thought from.  Id ask for 
enlightenment on it but I doubt it would help. 

Your CUA will have to process the "Janie" REQUEST and present it to you. 
Presumably it would be nice enough to show you the differences only (ie: 
"Updated values: SUMMARY changed to be 'Birthday Party for Janie'") and then it would let you do whatever you please w/it.  If not, you 
see the new REQUEST and have to actually read it for a change to notice 
the change in SUMMARY.

Since your particular ATTENDEE info has not changed (nor has the entry 
been rescheduled, etc) then your CUA has no reason to suggest that you 
resend a REPLY.  If you noticed the change you could tell the CUA to 
Decline and send back a comment like "COMMENT:I can't stand Janie so cross 
me off the list".  If you didn't notice it then whose to blame?  The 
Organzier for not knowing you hate Janie??  Your CUA for not being psychic 
software(TM)? 

This all gets back to my question of WHY that you so nicely tried to avoid answering...

Time to go home and discharge my sarcasm capacitors and cool off the 
frustration heatsinks in a nice cool bath of youthful optimism...

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 18:00:43 -0400

> <TRYING TO HOLD FRUSTRATION AT BAY>

Sorry.

> No I didnt.  Doesnt anyone actually read the text that gets
> posted??  I said that the reason the terms MUST/MUST NOT etc
> were not in the text was that it would have been impossible for
> some vendors to implement

I think that's what I meant.  My position is just that those
vendors are not doing scheduling, and a scheduling protocol does
not need to accommodate them.

> Im not changing the subject either.  It was stipulated that the
> Organizer needed to set RSVP=FALSE on a typo update to avoid
> triggering the invitee's CUA from sending a reply (that smells
> a lot like...)

My point below was that there is no real difference between a
typo update and any other update.  The Organizer may guess that
something is a trivial change, but they have no way of knowing
whether I agree--and, if I don't, then sending RSVP=FALSE is a
mistake, because it means I SHOULD NOT respond, even though my
response is different now.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |All your problems can be solved by not caring!|
[email-masked]|                                              |
\===============================================================/