Subject: Re: REQUEST sent to non-ATTENDEE

From: [email-masked]
Date: Tue, 24 Apr 2001 11:44:41 -0400

Alan wrote:
>        User B would be visible to all other ATTENDEEs though,
>        which might not be the required effect.

Id like to make sure that folks realize something thats implicit in the 
RFCs.  _Nowhere_ in the RFCs does it state each ATTENDEE gets the exact same copy of the 
iCalendar stream that the other ATTENDEEs do.  Most (all?) of our examples 
show A, B and C all getting the same invitation, etc but it is perfectly 
legal to NOT send the same stream to each ATTENDEE.  That is, Users A, B 
and C all get iCalendar invites that just look as if they are the sole 
invitee.  Or just User C could get one with all the ATTENDEEs and the 
other two see just themselves...

Examples for this include being able to build your Bcc style functionality 
or just plain adding an ATTENDEE after the fact (dont tell me that 
everyone always gets the invitee list perfect on the first attempt 100% of 
the time).  Another example is inviting a 'local group' (local to my 
computer) and having the SMTP system explode it into separate iMIP 
recipients so that I can digitally sign and encrypt each message.

Sure, most CUAs will create the iCalendar w/all the ATTENDEEs in it and 
send out 1 copy since that is the easiest approach.  Perhaps 2+ may be 
sent if the CUA wants to 'roll' alternate copies for each BCC invitee and 
a single all inclusive one to the room reservation system so that it can 
properly decide if the room can handle all the invitees.  However it is 
dangerous to code a CUA to expect that all invitees are listed in your REQUEST since the sender may not 
have put them all in it for whatever reason.

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: Tue, 24 Apr 2001 12:46:31 -0400

[email-masked] wrote:

>RFCs.  _Nowhere_ in the RFCs does it state each ATTENDEE gets the exact 
>same copy of the iCalendar stream that the other ATTENDEEs do.  Most 
>(all?) of our examples show A, B and C all getting the same invitation, 
>etc but it is perfectly legal to NOT send the same stream to each ATTENDEE.

That's a good point- so The Bcc'd user would see themselves
as a NON-PARTICIPANT, but the other ATTENDEEs would get
an object that didn't include them. This way the receiving CU
would always see themselves as an attendee.

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"?

--Alan