[Ietf-caldav] Comments on 3.2.3. Handling Scheduling Object Resources

[Arnaud Quillaud]

** Default value for SCHEDULE-AGENT **

Having the default value being SERVER still sounds wrong to me. If I'm 
using a calendar-access only client and my server is suddenly migrated 
to a schedule enabled server, I will suddenly start sending invitations 
without even knowing it.

** Reloading **

<<

As a result clients SHOULD reload the calendar data from
   the server as soon as it is stored in order to update to the new
   server generated state information.

 >>

Why SHOULD and not just MAY ? This is just a hint, no ?


** Restrictions for create and modify**

<<

The server MUST reject any attempt to set the "PARTSTAT"
       iCalendar property parameter value of the "ATTENDEE" iCalendar
       property of other users in the calendar object resource to a
       value other than "NEEDS-ACTION" if the "SCHEDULE-AGENT" property
       parameter value is not present or set to the value "SERVER".

 >>

We already discussed this but just for the records:
The server may end up generating an iMIP message for a particular 
attendee, hence the response from that attendee (and hence his PARTSTAT) 
may come via iMIP. In that case, the client must be able to update the 
attendee PARTSTAT to a value other than NEEDS-ACTION.
If I understood correctly, a solution would be to have a new 
"server-request" value for the SCHEDULE-AGENT. This value could be set 
only by the server (as the result of sending the invitation via iMIP). 
Any attendee with such a value could have its PARSTAT changed by the client.

** Restriction for modify **

<<

The client MUST NOT change the "UID" iCalendar property parameter
       value in the scheduling object resource.

 >>

but this is true already from calendar-access so is there any particular 
reason why this was re stated ?

** Attendee removing an event **

<<

 If
       the server is unable to deliver the scheduling message, the
       remove action MUST fail, and an appropriate "SCHEDULE-STATUS"
       iCalendar property parameter set on the "ORGANIZER" property in
       the scheduling object resource stored by the server.

 >>

For the remove action failing, you imply that the whole operation is 
synchronous which is not the case in reality.

Arnaud Q