- From: Mike Douglass <douglm@rpi.edu>
- Date: Wed, 19 Mar 2008 15:23:33 -0400
- To: WebDAV <w3c-dist-auth@w3.org>
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? 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 -- Mike Douglass douglm@rpi.edu Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
Received on Wednesday, 19 March 2008 19:24:09 UTC