- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 14 Jul 2009 14:43:16 +0200
- To: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
- CC: caldav@ietf.org, calsify@ietf.org, w3c-dist-auth@w3.org, Cyrus Daboo <cyrus@daboo.name>, Alexey Melnikov <alexey.melnikov@isode.com>, Lisa Dusseault <Lisa.Dusseault@messagingarchitects.com>
Julian Reschke wrote: > Julian Reschke wrote: >> ... >> 8. Conditional Requests on Scheduling Object Resources >> >> In order to do that, this specification introduces a new WebDAV >> resource property CALDAV:schedule-tag with a corresponding response >> header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request >> header to allow client changes to be appropriately merged with server >> changes in the case where the changes on the server were the result >> of an "inconsequential" scheduling message update. An >> "inconsequential" scheduling message is one which simply updates the >> status information of Attendees due to a reply from an Attendee. >> >> JR: that sounds really heavy-weight; I think it would be good to discuss >> this scenario over on the HTTPbis working group's mailing list. Even >> if new >> state tokens need to be added it is not totally clear why the RFC4918 >> can not be used for checking. >> ... > > Sorry. I meant to say: "...why the RFC4918 'If' header can not be used...". > > BR, Julian Expanding on that...: The spec currently introduces a new type of etag, the "schedule-tag", exposed as a live WebDAV property, and a new HTTP response header, plus a new conditional HTTP request header. WebDAV (RFC 4918) however already supports "state tokens" in the "If" header; right now only lock tokens are used, but there is no reason why a protocol wouldn't be able to introduce new state tokens, and allow them to be checked using the "If" header. -- That would at least avoid introducing a new conditional request header. That being said, it would be nice to get rid of the new state tokens ( schedule tags altogether. I do understand the problem with many clients updating the attendee information simultaneously. Two thoughts on this: 1) In general, issues like that can be avoided by enhancing the granularity of the resource that needs to be updated. For instance, the status for each attendee could be modeled as a separate resource, that could then respond to GET/PUT/DELETE. (I guess the server could advertise its URL as a parameter on the ATTENDEE). 2) It may also be possible to use PATCH for updating the attendee status; we would just need to define a simple payload format which can guard the client from unintentionally changing the status on an event that just changed (my understanding is that PATCH is likely to be finished in time for this spec). Best regards, Julian
Received on Tuesday, 14 July 2009 12:44:08 UTC