Subject: Re: Attendee clarification

From: [email-masked]
Date: Wed, 2 May 2001 14:40:42 -0400

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: [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] (Steve Mansour)
Date: Wed, 02 May 2001 15:24:11 -0700

[email-masked] wrote:

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

actually, this was exactly the issue I was going to bring up.  But I
wanted to see everyone's response.

If you invite me to a meeting, my ATTENDEE line for that request looks
like this:

     ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:[email-masked]

Then you send out a fix to a typo and you don't want me to reply, my
Attendee line looks something like this:

     ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=FALSE:mailto:[email-masked]

But if I want to decline the invitation at some point after I receive
the typo fix, I should be able to do so.
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.  So,
when an attendee stores this info in their calendar, do they change RSVP
to TRUE?  Or leave it at FALSE?

Does anyone see a good way to deal with this?  Is there another
parameter that helps?

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

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

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

agreed.  Initially I was thinking that ROLE might play a part in
clarifying things. I don't believe it does.

-Steve

---

From: Alan Davies <[email-masked]>
Date: Fri, 04 May 2001 10:15:58 -0400

If Bruce's interpretation of RSVP is correct, there's
not much difference between a REQ-PARTICIPANT with RSVP=FALSE
and 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. We already have ways of
scheduling without interaction (PUBLISH, NON-PARTICIPANT,
etc.) RSVP should be able to strengthen the flow of
information between Organiser and ATTENDEE, not weaken it.

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. Maybe RSVP should have 3
possible values- YES, NO, and DONT-CARE (DONT-CARE would leave
the decision up to the ATTENDEE- the equivalent of Bruce's
TRUE and Steve's FALSE.)

--Alan

At 15:24 2001-05-02 -0700, Steve Mansour wrote:
>>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.
>ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE:<mailto:[email-masked]>mailto:[email-masked] 
>
>
>ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=FALSE:<mailto:[email-masked]>mailto:[email-masked] 
>
>
>But if I want to decline the invitation at some point after I receive the 
>typo fix, I should be able to do so.
>must not send a reply. Yet that was not the Organizer's intent.  So, when 
>an attendee stores this info in their calendar, do they change RSVP to 
>TRUE?  Or leave it at FALSE?
>
>Does anyone see a good way to deal with this?  Is there another parameter 
>that helps?

---

From: John Stracke <[email-masked]>
Date: Mon, 07 May 2001 12:44:24 -0400

[email-masked] wrote:

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

Those are not C&S systems; they're just C systems.  If the
invitee can't RSVP, you're not doing scheduling; you're just
publishing an event.

In my view, systems that can't do scheduling are out of scope for
iTIP (or, at least, for the REQUEST method).

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Rope is rope, and string is string, and never|
[email-masked]|the twine shall meet.                        |
\==============================================================/