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, JulianReceived on Wednesday, 19 March 2008 19:47:49 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 19 March 2008 19:47:50 GMT