- From: Lisa Dusseault <lisa@xythos.com>
- Date: Sun, 15 Sep 2002 11:13:38 -0700
- To: "Webdav WG" <w3c-dist-auth@w3c.org>
We had a great interop last week, IMO. Overall, servers and clients now have much greater success, and more consistent expectations of each other. Progress was made on issues and recommendations for RFC2518bis and quota draft. I tried to keep track of all the Interop issues and recommendations that people thought should feed into RFC2518 bis. I'll list all these issues in this first email, then start more detailed discussions on some of them in separate email. These are in no particular order. Not all the reasons, justifications or scenarios for these suggestions are given here. To the extent that we discussed each of these, WG meeting consensus was reached in each case. Of course the final resolution for each issue and the content of RFC2518 bis are fully subject to discussion on the list. - Be more clear more about what a client should do about various errors that may return in a 207. 2518 could explain for each error case, what the client might expect to do - retry a different way, give up, etc. - Clients should accept cookies. More on this in later email. - Simplify timeout definition so that it only allows one TimeType, and no "other". - Add a new string in DAV: header to advertise support for RFC2518 bis - Change the DAV: header BNF to allow coded URLs syntactically. - Error responses that must contain headers (like 302) don't contain those headers in multistatus. E.g. when you MOVE a collection, but one of the collection members is redirected, a 302 would be most convenient and normally comes along with a location. Clarify in 2518 bis. - Be more clear in xml element definitions how they can be extended and why. - Support absolute paths as well as absolute URIs in Destination header. URI spec has token "abs_path" which would work. - Change section 13.7 (and others?) to be perfectly clear that last modified and etags should ONLY reflect the results of GET requests, not property or other state changes like lock. - Be clear in spec that servers MUST do ETags. Explain how necessary this is to solve the lost update problem. - COPY request, destination on different server: how to fail? 502 - Litmus large path names causing failure? Specify better what error to return. - Close out issue on PUT creating intermediate collections. We will not. - Changing ETags on LOCK? No - How to force authentication from clients? Ilya will propose OPTIONS header. - Servers must use trailing slash whenever collection URLs are returned. Language proposed for 2518 bis - Servers should not be allowed to withhold lock owner information from clients. Clients control the content of this element, thus clients can decide on sensitivity. - LOCK on non-existent resource creates a resource. What is content-type? Server defined, or use 204. - Clients get confused if host names change; Clients expect full/relative URLs? Dealt with in text on multistatus response - Body in MKCOL - must be XML?, no it doesn't have to be! - Can a single principal take out >1 shared lock? Yes! - Are shared write locks interoperable? Yes-humans can decide when to update the document that is locked with shared locks. Automatic processes probably shouldn't use shared locks. - Should if and lock-token header be split up? Yes - BODY on LOCK refresh - can client reset timeout or owner? No body. Yes clients can refresh timeout with header, but not owner because LOCK refresh has no body. - Source property is "out" of bis. Proposal for authoring dynamic content should be in another draft. - If header should not be required in order to supply a lock token to change a locked resource. A proposal is needed for a new header that does not force the request to fail if the lock token is no longer applicable. More on this in a later email. NON-2518 ISSUE: - Quota draft was edited. It should be reissued and go to proposed.
Received on Sunday, 15 September 2002 14:14:37 UTC