Re: [ietf-calsify] Group Event

Am Mittwoch, 13. Januar 2010 19:34:33 schrieb Cyrus Daboo:
> Hi Calvin,
> 
> --On January 13, 2010 10:01:40 AM -0800 Calvin So <sochihong@gmail.com>
> 
> wrote:
> > I am not sure if my case is feasible but I am trying to write a 
> > backend program that send out message to "A", "B", "C" and "D" and 
> > make "A" as the organizer/chair of a group event and the others as the 
> > attendees. 

Okay, so basically your programm (who is operating it???) is the organizer. 
There should be some human contact organizing (i.e. fixing the date, 
organizing the room, informing the participants about changes, etc.) the event 
with A,B,C and D. That human contact (email address) should be the ORGANIZER 
of the event.

The fact that A is the CHAIR of the meeting can be indicated by the ROLE 
parameter of the ATTENDEE:

       ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com

See section 3.2.16 of RFC 5545

All other attendees will either have no ROLE parameter (implicitly, REQ-
PARTICIPANT is assumed in that case) or an explicit ROLE parameter:

       ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry
        Cabot:mailto:hcabot@example.com

> > I have read the "4.2. Group Event Examples" in 
> > http://ri-cal.rubyforge.org/rdoc/docs/draft-ietf-calsify-2446bis-08_t... 
> > but it doesn't mention much about what message content should be 
> > constructed for message sending to "A" 

You should definitely also read RFC 5545 (the successor to RFC 2445) about 
ATTENDEE, ORGANIZER and all its parameters. RFC 2446bis builds on RFC5545.

> > Can somebody shed some light on this? In particular, which parameter 
> > (s) should I pay special attention to? Or there is no feasible 
> > solution for my case? 
> 
> Strictly speaking in the iTIP model messages are assumed to be originated
> by the Organizer. In your case it looks like you want some third party to
> originate the message and make sure it also gets put on the Organizer's
> calendar. 

You are using "organizer" for two different tasks: 1) really organizing the 
event and 2) chairing the event.

> Does the third party have any direct access to the Organizer's
> calendar? Are you expecting the Attendee's to reply to the organizer with
> their participation status updates?

Exactly, this is the issue. if your application simply acts on behalf of the 
chair/organizer (i.e. can fix dates for him/her, has access to the calendar, 
etc. like a secretary), the chair or the secretary should also be the 
ORGANIZER and will receive all replies by the attendees. 

Otherwise, the chair is simply a "normal" attendee with a special role at the 
meeting. In that case the ORGANIZER is someone else and the chair is an 
ATTENDEE with ROLE=CHAIR.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, reinhold@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org
_______________________________________________
ietf-calsify mailing list
ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify