Re: [caldav] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt]

[Julian Reschke <[e-mail]>]

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