Subject: Re: Attendee clarification

From: [email-masked]
Date: Thu, 3 May 2001 15:53:23 -0400

Steve wrote on 05/02/2001 06:24:11 PM:
> But if I want to decline the invitation at some point after I 
> receive the typo fix, I should be able to do so. 

Hang on.  How do you know that the Organizer still wants any kind of reply 
from you since they told you RSVP=FALSE? 

You assuming that the FALSE only applied to the 'update'??  Can't do that 
since every REQUEST is a full snapshot of the event so any settings in the 
'older' copies are no longer applicable; only the settings in the 'newest' 
copy should be used.  (Sure, any CUA can violate the concept of the most 
recent copy is the only one to act on but A) thats not good form and B) 
its not what the CUs would expect of a CUA.)

> So, how can I do it?  If RSVP is FALSE, it seems to me that the 
> attendee must not send a reply. Yet that was not the Organizer's 
> intent. 

Again, are you psychic?  Can you truely devine the Organizers intent from 
a simple "Yes/No" setting that was changed?  The Organzier may have 
decided that they really do not want to hear back from you...

>      So, when an attendee stores this info in their calendar, do
> they change RSVP to TRUE?  Or leave it at FALSE? 

Since the latest REQUEST is a full snapshot of the invitation, the setting 
gets saved w/the latest value: FALSE.

> Does anyone see a good way to deal with this? 

See my codifying text as to when a reply should be sent from the ATTENDEE 
in my original reply.  In a nutshell: It is not automagically sent upon 
receipt of the REQUEST, it is sent on change of status (ie: accepting, 
declining, etc) or upon delegation (or if the REQUEST has ATTENDEE 
specific values/properties that differ from the ATTENDEEs copy as in they 
passed in the mail or the Organizer never got it).

>                            Is there another 
> parameter that helps? 

Nope.

> I'm not sure I saw a clarification.  Did you clarify a solution to 
> this issue? 

Reread my posting beginning at "So, the way that TRUE and FALSE should be interpreted is this: "

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: [email-masked]
Date: Fri, 11 May 2001 16:55:55 -0400

Graham astutely noted on 05/11/2001 04:17:32 PM:
>     So, sifting through the clarifications & whatnot, it would seem that
> a correction to Steve's examples would look like this:

Your changes are all accurate.  There is no (or yet to be postulated) 
reason for the Organizer to set RSVP=FALSE for a typo change (unless you 
view it as a Delivery Notification type flag)! 

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

Assuming that their PARTSTAT value was not already NEEDS-ACTION then this 
is correct.  Otherwise there is nothing really to 'reset' but essentilly yes.

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

And the crowd goes wild with excitement!!  Its sinking in to some folks it 
seems.  A hush settles over the crowd in eager anticiaption that the rest 
will soon follow...

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

And the excitement builds again...

>     Does this make sense to everyone?

They hold their breath and wait...

Bruce

---

From: [email-masked]
Date: Mon, 14 May 2001 10:44:19 -0500

<snip/>

> RFC2446 seems to have the funny notion
> that we are creating a scheduling protocol here, but that's 
> may be just
> "stale text" as well.

The RFC2446/iTIP is in fact a scheduling protocol specification.

-- Frank

---

From: [email-masked]
Date: Mon, 14 May 2001 12:48:51 -0400

Alan fired back on 05/14/2001 10:55:13 AM:
> 3.2.2.3 Delegating an Event to another CU
>     [...] In response to the request, the "Delegate" MUST send a 
> "REPLY" method
>     to the "Organizer" and optionally, to the "Delegator".[...]
> 
> that was a 'MUST' in capital letters, implying that non-scheduling
> CUAs are not being considered. RFC2446 seems to have the funny notion
> that we are creating a scheduling protocol here, but that's may be just
> "stale text" as well.

There is a difference between a REPLY and a reply.  The former is an iTIP 
response of some kind.  The latter is a delivery confirmation (in this 
context). 

So, from your text do I infer that you expect me, as the Delegated arrow 
taker for Frank, to automagically send a REPLY in response to the 
delegation notice EVEN IF NOTHING CHANGED (ie: I didnt 
accept/decline/redelegate)???  Id hope not but if so (to save time), WHY!? 
 What is gained by this?? 

If you implicitly assume that I _must_ take action immediately upon receipt then that too is something Id 
question.  I would never use a product that made me do something I did not 
want to do (ie: "You MUST reply to Franks delegated REQUEST now!")

If you are assuming that at some point in the future I will want to reply 
and that the "MUST" you cited is my imperative for this then you are 
treating it differently than you are describing it.  I would expect that 
any delegate (or original invitee) would actually send a REPLY if their 
participation status (or other settings) change but only then, not before. 

Im going to abide by Patricks admonishment and no longer persue this 
thread until we reach some closure on the iptel issues.  Plus I like 
Steve's latest clarification; I think its right on.

Bruce
PS: With only 1 editor in common between 2445 and 2446 it is no wonder 
that some changes were not equally applied or concepts are not necessarily 
100% in agreement between the two RFCs.  This is not a reflection on the 
editors skills but more a reflection on our WG's ability to 
intercommunicate clearly.
===========================================================================
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: [email-masked]
Date: Mon, 14 May 2001 21:22:13 -0400

John asked on 05/14/2001 02:03:38 PM:
> Then why does it define RSVP at all? RSVP is clearly for use in
> scheduling.

Ill get back to this after ipTel if need be...

Bruce