Subject: Re: REQUEST sent to non-ATTENDEE

From: [email-masked]
Date: Tue, 24 Apr 2001 15:52:50 -0400

Alan replied on 04/24/2001 12:46:31 PM:
> John suggested that RFC2446 3.2.2.6 "Forwarding to An Uninvited CU"
> showed that a REQUEST could be forwarded to a CU without them
> being an ATTENDEE:
> 
>     An "Attendee" invited to an event may invite another uninvited CU to
>     the event. The invited "Attendee" accomplishes this by forwarding 
the
>     original "REQUEST" method to the uninvited CU. The "Organizer"
>     decides whether or not the uninvited CU is added to the attendee 
list.
> 
> This section didn't tell us how the "Organizer" gets the information
> about the uninvited CU though, does the invited "Attendee" send
> a COUNTER to the "Organizer"?

The RFCs fail to address this.  I recall seeing 2 different assumptions 
about this in our sordid WG history.  One assumption is that the REQUEST 
is forwarded as an Content-Type: message/rfc822 (that contains the 
Content-Type: text/calendar) to indicate that it was forwarded.  Another 
assumption is that if the uninvited CU cannot 'find' themselves in the 
ATTENDEE list then they are a 'party crasher' (or possibly a group 
member!!).

In general I thought (need to scan the archives to confirm) that 'party 
crashers' (aka uninvited CUs) do NOT participate in the workflow process 
so they do not ACCEPT, DECLINE, DELEGATE, etc to other CUs or otherwise 
respond back to the Organizer.   I did see that in Section 3.2.3 Reply of 
2446 we claimed:

   The "Organizer" of an event may receive the "REPLY" method from a CU
   not in the original "REQUEST". [Snip] In addition, the "REPLY" method 
may be
   received from an unknown CU (a "Party Crasher"). This uninvited
   "Attendee" may be accepted, or the "Organizer" may cancel the event
   for the uninvited "Attendee" by sending a "CANCEL" method to the
   uninvited "Attendee".

This somewhat contradicts one of the assumptions above but it could have 
been left in by accident.  Frank would have to codify this for us. 

I suspect that the proper behaviour for adding a new invitee would be to 
have the forwarding CU COUNTER with the previously uninvited CU added as a 
new ATTENDEE rather than just forwarding the invitation and causing the 
Organizer grief. 

I also hope that a CUA would be somewhat lenient in that a reply could be 
from a delegatee or from a member of a group and as such may not be in the 
original/current invitation.  "Unknown" CUs should not just be rejected 
outright or automagically...

I think that the text in Section 4.2.8 Forwarding an Event Request of 2446 could probably use some tightening up:

                    Implementations are not required to add the "Party
   Crasher" to the "Attendee" list and hence there is no guarantee that
   a "Party Crasher" will receive additional updates to the Event. The
   forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the
   attendee list. The "Organizer" MAY add the forwarded "Calendar User"
   to the attendee list.

I think that the SHOULD NOT for the forwarding CU really should be a MAY 
NOT or MUST NOT since they are NOT delegating it to the crasher nor are 
they COUNTERing to the Organizer to have the new CU added.  Only the 
Organizer should be adding non-delegatee ATTENDEEs.  Anyone else 
agree/disagree??  (As if I need to ask for disagreement on this list... 
;^} )

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: Tue, 24 Apr 2001 15:24:43 -0500

Bruce:
 
Intended "Attendee" (AKA, party crasher) sends a REPLY to the Organizer, of
course. This is stated in the section you quote from RFC2446.
 
I agree with your restatement of the RFCs that only the Organizer should be
adding/deleting CUs.
 
-- Frank