Subject: Re: Attendee clarification

From: [email-masked]
Date: Fri, 11 May 2001 15:51:52 -0400

Alan suggested:
>If Bruce's interpretation of RSVP is correct, there's
>not much difference between a REQ-PARTICIPANT with RSVP=FALSE
>and a NON-PARTICIPANT.

First off, its not "my interpretation".  I was expressly describing our 
original intent when we designed and added RSVP.  Ask Frank or Derik to 
confirm this...

The RSVP property parameter conveys 1 intent: does the Organizer want to 
get a response from the Invitee to this (overall) invitation. 

The ROLE conveys another.  The ROLE=REQ-PARTICIPANT conveys to me that the 
Organizer really would like (or requires) me to attend.  The 
ROLE=OPT-PARTICIPANT tells me that they prefer that I attend but can live 
w/o me being there. 

The METHOD property conveys the overall action that the Organizer is trying to do (ie: Invite me to a meeting, PUBLISH a 
calendar entry, etc). 

All the have distinct, separate and useful semantics.  There are cases for 
when to use each one in different ways.  The claim that 
RSVP=FALSE;ROLE=REQ-PARTICIPANT is akin to a METHOD:PUBLISH could be true 
if you do not see the use of each property/parameter and how they are 
intended to be used. 

Also, do not forget that _each_ REQUEST is a separate and complete snapshot of the event so that we do 
not have to worry about partial updates, "delta management", etc. in our 
workflow process.  However it sounds as if Alan is proposing that we turn 
RSVP into a "1 time only" use parameter.  If that were the case then it is 
possible that I would/could _never_ reply to a REQUEST from him if I only got the 'typo' correction and never 
got the original invitation.  Or if I did get the original invite _after_ 
the update then my CUA would no longer just ignore it like we have agree'd 
on since nearly Day 1 ("That DTSTAMP is older than the one I already got 
for the same UID and SEQUENCE values so I can just toss it").  My CUA must 
try to figure out if I really should reply to the REQUEST or not based on 
info that is 'older' than the last 'snapshot'.  Ugh.

Another inherent part of this argument is that a ROLE=REQ-PARTICIAPNT (and 
possibly OPT-PARTICPANT) have some implicit "respond" actions.  That is, 
if I see that Alan made me a REQ-PARTICIPANT then I must implicitly be 
mandated to send him some kind of reply.  Sorry, Alan cannot make me reply 
if I dont want to nor is my role indicative of my abilty to 
respond/counter/etc.

A simple scenario where a response is not necessary: I talk w/Steve to 
arrange lunch next Thursday.  We both have it free and agree to the time, 
place, etc.  I use my normal CUA to send him an invitation but I do not 
need to know if he is coming or not (we've already planned it) so I just 
fill in the normal request form and post it off to him w/the RSVP=FALSE. I 
could have made him a "Non-particiapnt" but as a CU, I do not view Steve 
as not particpating in lunch; its a lunch date!  However by Alans view I 
would have to expressly make Steve a non-particpant (via a different entry 
line or some other GUI setup) instead of simply saying "Send w/o 
requesting response" (or your favorite GUI action).

A non-particpant is someone like the AA who has to know about the meeting, 
the caterer who has to get an idea of the head count so they can plan the 
meals, etc.  If someone is going to participate, Id say they are not a 
non-participant.

>The whole reason for REQUEST/REPLY/ROLE/RSVP/etc. is to
>allow interactive scheduling between CUAs, something that
>we're all working to achieve.

When the RSVP property was first put on the table, some vendor(s) said 
that they did not have the concept of all these kinds of msgs and would 
not be able to support them all (hence our easing of the MUST/MUST NOT 
text).  How can you expect to mandate a particular behaviour if someone 
does not have an architecture/design that supports your implicit 
assumptions?   You can't. 

>What Bruce is suggesting may be useful, but as far as I
>can see nothing in RFC2445 or RFC2446 implies that RSVP
>can be used to achieve this.

Once again: Its not expressly in the text, thats why I posted the 
clarification as to the original intent. 

If you reread the text for TRUE I originally posted (sounds like some have 
not or just skimmed it) you will see that setting RSVP=TRUE on a 'typo' 
update is NOT mandating that the CU send back a "I got your typo fix" any 
more than it means "Send the Organizer a 'I got your REQUEST and will send 
a REPLY soon'" message.  That sounds like a MIME delivery confirmation 
setting and we are not building that.  The value of TRUE is used to tell 
the invitee that the Organizer wants to know of any PART-STATUS changes 
(ie: you accepted, declined, delegated, etc) or if they want me to be able 
to Counter with a new date/time.

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!

If however, my CUA noticed that you think I have not yet accepted then it 
should either prompt me if I want to re-accept (ie: send a second 
acceptance just in case) or possibly do a DIFF against its snapshot first 
to see if just a typo fix was found (or other minor tidbits) and then do 
it for me as a feature.  That is, "Hmm, Alan did not change the start 
time, end time, location, attendee list, ... but did change 1 word in 
SUMMARY AND he has not indicated that he got my acceptance notice from 
last week so I better re-accept so he knows."

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: Alan Davies <[email-masked]>
Date: Fri, 11 May 2001 17:41:28 -0400

>original intent when we designed and added RSVP.  Ask Frank or Derik to 

Unfortunately I wasn't around at this time, so I am forced to
base my interpretation on the RFCs themselves.

It'd be nice to have some confirmation, especially as to why
such vague language was used ("expectation of the favor of a
response") for a property whose careless use would cause _no_
scheduling to take place between two CUAs.

It'd also be nice also to hear from some other implementors as
to how they interpret RSVP.

>if I dont want to nor is my role indicative of my abilty to 

You can reply as and when you want to. If you never reply, or you
ignore my replies, then we're not doing any Scheduling; but that's
your problem.

>different entry line or some other GUI setup) instead of simply saying 
>"Send w/o requesting response" (or your favorite GUI action).

Maybe (just speculating here...) you could send your REQUEST to Steve, with
him as a REQ-PARTICIPANT, PARTSTAT=ACCEPTED, and RSVP=FALSE. He would
see that as you already have the correct PARTSTAT (and RSVP was FALSE),
he doesn't have to send a REPLY.

Mind you, if he changed his mind in the meantime, he should be able to send
you another REPLY to update his PARTSTAT- that's the idea behind 'my' version
of RSVP=FALSE- he can send a REPLY as and when he wants to.

>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!

To be reduced to quoting from the RFCs instead of my knowledge
of past discussions again:

RFC2446 2.1.4 Component Revisions

     In some circumstances the "Organizer" may not have received responses
     to the final revision sent out. In this situation, the "Organizer"
     may wish to send an update "REQUEST", and set "RSVP=TRUE" for all
     "Attendees", so that current responses can be collected.

You see? The organiser was able to receive responses even though
RSVP was set to FALSE, but he set it to TRUE to ensure Attendees
responded to the "final version".

Either RFC2446 is wrong or you are- one or the other, but we have to
decide which so we can all interpret this property in the same way.

--Alan