Subject: Re: Attendee clarification

From: [email-masked]
Date: Fri, 11 May 2001 18:13:22 -0400

Alan replied on 05/11/2001 05:41:28 PM:
> 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.

Hey Frank!  Wake up and confirm/deny my clarification for these folks.  Or 
you can use the archives and search for "RSVP".  It should all be there 
somewhere.  I dont think OOB emails were used for the entire thought 
process.

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

Ok this is probably the meat of the replys Im seeing.  Clarification was 
asked for and I simply provided the original intent.  Folks are still 
using their interpretation to argue over the clarification I provided... 
%^| 

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

You are not hearing what Im saying.  You as the Organizer cannot make me 
REPLY.  You can only tell me if you want to hear back or not and I oblige. 
 One thing you have ignored (or just forgot) is that each REQUEST is a full and complete snapshot of the current REQUEST.  You however are treating the RSVP as a "one time 
use" setting.  We do not have nor have we ever had a concept like that. It 
is simply not feasible to even try and do.

Case in point: If I never get your 1st REQUEST then my CUA would be under 
the mistaken impression that you did not want me to send back ANY kind of 
Accept/Decline/Counter/etc.  I could then NEVER have any workflow that you 
crave so strongly.  If I receive your initial REQUEST afterwards then your 
CUA should ignore it by the simple rationale we put in Section 2.1.5 Message Sequencing of RFC 2446.  So, the if the initial REQUEST arrives later then by your 
interpretation my CUA would have to use come criteria (voodoo?) to know if 
the RSVP=TRUE should be kept/set or not.  (Or are you suggesting that for 
all ROLE=REQ-PARTICIPANTs that a REPLY must happen by virtue of the value 
I set???)  All this still boils down to making RSVP a 'single shot' 
parameter and thats not wise!

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

Ok, this again argues your view of RSVP against my clarification of 
intent.  Its not exactly apples to apples but WHY would I want/need to set RSVP=FALSE for this invite?? 

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

Ok, let me get this straight: The Organzier says "I do not want any 
responses back from any Attendee" and the Attendees just say "I dont care, 
Im going to send you a REPLY when I feel like it"?  Why then would you 
even need/want the RSVP setting then in this view of things??

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

What I expressed and continue to try and express so that it can be 
understood is that my reply was a clarification of the original intent of 
RSVP and why the text in 2445 seems a bit vague or wishy-washy.  So its 
not a case of Im right or Im wrong.  Im simply stating what was not 
accurately conveyd in the final 2445 descriptive text.  As such, I suspect 
that 2446 has stale text in it.  Oh my gosh!  Say it isn't so!!  The RFC 
could actually contain inconsistancies or inacuracies!!  That can't be! Im 
crushed...  Sob, sob...

Damn it Frank, where are you!!!???  I dont like taking other peoples 
arrows!

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: Mon, 14 May 2001 10:44:36 -0400

At 06:13 PM 11/05/2001 -0400, [email-masked] wrote:
>As such, I suspect that 2446 has stale text in it.  Oh my gosh!  Say it 
>isn't so!!  The RFC could actually contain inconsistancies or 
>inacuracies!!  That can't be!  Im crushed...  Sob, sob...

I'm not crushed either, but we should at least log it as an issue for
2446; it seems that most of the text it contains related to RSVP is
utterly wrong (the rest of the text refers to RSVP being subverted in
a different way to allow a Delegator to continue to receive updates
to an event, but that's another issue...).

It's a shame that your "clarification" wasn't around when 2446 was
submitted. If it was then the following sections would have stood
out as being completely wrong:

"2.1.4 Component Revisions"
     [...] 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.

"3.2.2.7 Updating Attendee Status"
     The "Organizer" sends a "REQUEST" method "Attendee" and sets the
     "ATTENDEE;RSVP=TRUE" [...] The recipient SHOULD respond with a "REPLY"
     method indicating their current status with respect to the "REQUEST".

"3.4.2.5 REQUEST Updated Attendee Status"
     The "Organizer" sends a "REQUEST" method to the "Attendee" with
     the "ATTENDEE;RSVP=TRUE" [...] The recipient SHOULD respond with
     a "REPLY" method indicating their current status with respect to
     the "REQUEST".

"3.4.7 COUNTER"
    [...] the "Organizer" SHOULD reset the individual "RSVP" property
    parameter values to TRUE on each "ATTENDEE" property; in order to
    force a response by the "Attendees".

--Alan

---

From: Alan Davies <[email-masked]>
Date: Mon, 14 May 2001 10:55:13 -0400

>REPLY.  You can only tell me if you want to hear back or not and I oblige.

None of the RFCs state this, and in some situations 2446 states
the opposite:

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.

--Alan