- From: <bugzilla@soe.ucsc.edu>
- Date: Sun, 8 Jan 2006 02:50:27 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=44 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-08 |-10 ------- Additional Comments From julian.reschke@greenbytes.de 2006-01-08 02:50 ------- Text is still present in <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-10.html#rfc.section.9.1>. A few comments on the current status: - Contrary to what Lisa said, it is NOT possible to implement OPTIONS * in a situation where several web applications share the same Java web container; there is no delegation mechanism whatsoever that would make it possible that information from multiple servlets is collected into a single response. It seems to me that similar reasons would make it equally hard in a system like Apache (when it hosts more than one application). - I haven't heard any new feedback from either the HTTP mailing list or CalDAV. - There's no evidence (yet?) of a generic client that actually fails if a server does not return the DAV: header upon OPTIONS. - It's completely unclear how a generic client can make any use of that information, unless it also includes pointers to URLs that indeed support WebDAV. Just knowing that there may be resources on the server allowing WebDAV doesn't seem to be useful at all. And finally: - This is a new requirement, compared to RFC2518, which (a) is not implemented interoperably today, (b) is hard or impossible to implement in many situations and (c) doesn't seem to provide any testable advantage to clients. Therefore I think it must be removed. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
Received on Sunday, 8 January 2006 10:50:31 UTC