- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 19 Mar 2008 20:47:05 +0100
- To: Mike Douglass <douglm@rpi.edu>
- CC: WebDAV <w3c-dist-auth@w3.org>
Mike Douglass wrote: > > Rather late to the list I'm afraid... > > Cyrus pointed out this draft to me in relation to some issues with > CalDAV and it seemed it would offer a solution to some practical > difficulties we ran into with the use of CalDAV - how do we make users > subscriptions appear in a CalDAV client. > > The solution I was looking at was essentially some form of alias scheme > which would allow us to implant an alias to a resource in the users > calendar hierarchy. This works for shred calendars on the same system > and will work fine for shared calendars on any other system except that > it's unlikely they are going to tell us that the resource has been > deleted - nor do they care there is a link to that resource e.g. google. > > Given that the server can behave perfectly reasonably in the event that > a targetted resource has gone missing why was it felt necessary to > require that the targetted server a) know about all such bindings and b) > inform the targetting servers? Well, for BIND we assumed people want referential integrity. Maybe you should look at redirect reference resources? (<http://greenbytes.de/tech/webdav/rfc4437.html>) > And if I implement BIND such that it simply treats the target as empty > or non-existant how would anybody know different? By which I mean > wouldn't it be better to define the response if a targetted resource > disappears or becomes unavailable? The conditions as laid out in draft > 20 seem to make this feature unusable for many purposes I'm not entirely sure what you mean... Could you provide an example? BR, Julian
Received on Wednesday, 19 March 2008 19:47:49 UTC