[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