[Ietf-caldav] Scheduling section 3.1.1 (again)

Bernard Desruisseaux bernard.desruisseaux at oracle.com
Mon Sep 29 12:55:38 PDT 2008


Hi Mike,

While the PROPPATCH request you have in mind looks pretty simple at 
first you have to realize that it could actually trigger a lot of 
operations on the server.

When converting a basic calendar collection into a scheduling 
collection, the server would need to make sure there are no UID conflict 
amongst all your scheduling calendar collections, and the server would 
also end up sending a lot of meeting invitations on your behalf.

When converting a scheduling calendar collection into a basic calendar 
collection, the server would end up sending METHOD:REPLY with 
PARTSTAT=DECLINED for all the invitations you had in your calendar.

And... the server wouldn't have any way of telling you exactly what went 
wrong in the response to your PROPPATCH request in case of errors.

I'm guessing you would like your users to be able to convert their basic 
calendar collections into scheduling calendar collections themselves 
after their server will have been upgraded to a version of your server 
that provides support for scheduling calendar collections... and thus 
would like to see this operation possible through the protocol.

Given that our intent is not to allow users to change this themselves, 
would it be acceptable if we were to require (MUST) the DAV:resourcetype 
to simply be protected (i.e., can't be changed from client over CalDAV) 
instead of immutable. This way a compliant server would still be allowed 
to change the DAV:resourcetype itself and perhaps provide a mean to the 
end users to change it (not over CalDAV, or else don't tell me).

Thanks,
Bernard

Mike Douglass wrote:
> You have the text:
> 
>    The DAV:resourcetype property on a calendar collection MUST be
>    immutable.  Once a calendar collection has been created, servers MUST
>    NOT change it from a scheduling calendar collection to a basic
>    calendar collection, or vice versa.
> 
> 
> Why and from a client perspective how is this enforced?
> 
> User has non-scheduling calendar X
> Moves the contents to Y
> Deletes X
> Recreates X as scheduling calendar
> Moves Y/* back into X
> 
> or alternatively just does a PROPPATCH
> 
> 
> 



More information about the Ietf-caldav mailing list