[caldav] various question on scheduling draft

[Arnaud Quillaud <[e-mail]>]

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