Subject: [caldav] various question on scheduling draft

From: Arnaud Quillaud <[email-masked]>
Date: Tue, 29 Sep 2009 19:02:53 +0200

Hello,

Some questions and comments on the latest scheduling draft:

* SCHEDULE-AGENT parameter
In the case of a recurring event where a particular attendee might 
appear in multiple instances,  is it worth mentioning that given a 
particular attendee, the value of this parameter should remain constant 
between instances ?

* About 5.2.1.2. Modify (by the organizer)
Without defining what is a modification in this context, it seems like 
any modification by a client will trigger a REQUEST to all attendees 
with (old=SERVER,new=SERVER) when it is not really the case (e.g VALARM 
change).
If the change is significant enough but the client has not reset the 
PARTSTAT of the attendee, should a REQUEST still be sent ?

* About 5.2.2.1. Allowed Attendee Changes

Why allow changes to the CREATED property ?

* About 5.2.2.3. Modify (by an attendee)

There is no mention of the EXDATE case (that should trigger a REPLY with 
PARTSTAT=DECLINED). EXDATE is actually mentioned as an allowed change 
right before and the example section contains this scenario but it might 
still belongs here.

PERCENT-COMPLETE is also listed as an allowed change for attendees. 
Looking at iTIP (http://tools.ietf.org/html/rfc2446#section-4.5.4), 
REPLY can be used by ATTENDEEs to convey the progress on the delegated 
task. As a consequence, should a change in PERCENT-COMPLETE by an 
attendee also trigger a REPLY ?

* About 6.1. Processing Attendee Replies

It says:

<<

The server SHOULD send scheduling messages to all the other Attendees
    indicating the change in participation status of the Attendee replying, subject to the recurrence requirements of Section 5.2.6

This might indeed trigger quite a few messages. What about attendees who 
have declined ? Are they really interested in those messages ? I guess, 
their CUA could just filter those messages out but...

About 6.2. Processing Organizer Requests, Additions, and Cancellations

There is no guideline as far as processing a CANCEL (should the server 
just set the STATUS of the meeting to CANCELLED or might it choose to 
simply delete the calendar resource from the attendees copy).

* implementation question:
This is a rather philosophical one: the server is now altering calendar 
resources as much as the client (even on a simple create, just to update 
the SCHEDULE-STATUS). Should we preserve the PRODID of the client 
although the server altered the content, possibly in some drastic way ?

Thanks,

Arnaud Q