Subject: [ietf-calsify] Group Event

From: Calvin So <[email-masked]>
Date: Wed, 13 Jan 2010 10:01:40 -0800

Hi folks,

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.

I have read the "4.2. Group Event Examples" in
http://ri-cal.rubyforge.org/rdoc/docs/draft-ietf-calsify-2446bis-08_t...<http://www.google.com/url?sa=D&q=http://ri-cal.rubyforge.org/rdoc/docs/draft-ietf-calsify-2446bis-08_txt.html&usg=AFQjCNFWpeP5B-MY1RN1dfc_zgckME45Pg>

but it doesn't mention much about what message content should be
constructed for message sending to "A"

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?

Thanks!
_______________________________________________
ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 13 Jan 2010 10:34:33 -0800

Hi Calvin,

--On January 13, 2010 10:01:40 AM -0800 Calvin So <[email-masked]> 
wrote:

> http://ri-cal.rubyforge.org/rdoc/docs/draft-ietf-calsify-2446bis-08_t... 

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

-- 
Cyrus Daboo

---

From: Reinhold Kainhofer <[email-masked]>
Date: Wed, 13 Jan 2010 22:08:55 +0100

> > make "A" as the organizer/chair of a group event and the others as the 

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:[email-masked]

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:[email-masked]

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

> 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

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, [email-masked], 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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify