[Ietf-caldav] Scheduling section 3.1.1 (again)

[Mike Douglass]

Would it not have been better to flag events as being an
active-scheduling-event?

An event becomes active when it is sent to the attendees by the
organizer or received by an attendee.

uid must be unique among all active events

When an event is copied it becomes inactive.

Simple search of the db finds all active scheduling events.

Can be highlighted in the ui, listed when not all attendees have
confirmed etc.



Bernard Desruisseaux wrote:
> 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
>>
>>
>>
>
>

-- 

Mike Douglass                           douglm at rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180