- From: Tim Ellison <Tim_Ellison@uk.ibm.com>
- Date: Wed, 15 Aug 2001 11:24:41 +0100
- To: w3c-dist-auth@w3.org
- Cc: minutes@ietf.org
WebDAV Working Group Meeting (1:30pm Monday August 6th, 2001) IETF'51 London, England Lisa Dusseault standing in for Jim Whitehead as Chair. - Lisa D. presented the agenda and it was approved by the group. - Discussion started with DASL. Lisa D. is taking over the role of editor, and has tried to contact previous authors without much success. Lisa D. made a call for participants on the DASL spec. - Larry M. asked if the XML query language from W3C is sufficient for DASL. Lisa thinks it is solving a different problem and that an SQL-like syntax is more appropriate for DASL. - Should include discovery so that the server can answer which properties it supports searches over. Nobody stood up for schema discovery. - How about search over content? Should be in scope of the working group, but should it be a requirement of DASL? - IETF process ? should DASL be part of the WebDAV WG or be in a separate WG or be an independent submission? People agreed that it should not be part of the WebDAV WG. ACLs were in the WebDAV WG charter, DASL isn't. - Question: What remains to do in the WebDAV WG charter? Advanced collections, redirect references, properties registry doc., ordered collections, and raising DAV to a draft standard. - This remaining work is probably just lacking an editor/champion. The WG should push them forward or drop them if there is no interest in the work being done. - Larry M. presented the WebDAV Inter-op report. 58 people, 20 organizations, 35 implementations, (17 clients, 18 servers of which 5 open source). - Participants had agreed not to publish the results for individual tests. - Not many implementations inter-operated completely without any issues. - The event made good progress towards inter-op., some teams made fixes in real time either on-site or in collaboration with development teams 'back home'. - Proposed a virtual inter-op meeting in late-September, say a four hour test window and a telephone conference call. - Mailing list for inter-op discussions is interop@webdav.org, which is by invitation. - Found common inter-op problems, maybe these can be distilled into an implementers' guide. - Little, if any, DeltaV testing took place. - Typical problems include security, URI encoding problems, etc. misunderstandings in the spec. - Inter-op testing uncovered some required features were missing. Many servers did not implement LOCK, and many clients required it. - Some inter-op problems were HTTP issues, such as authentication, multiple authentication headers. - Missing, unused, untested features included DAV:source property (nobody used or implemented it), content-language being reflected in the DAV:getcontentlanguage property. It was noted that the source property should be removed unless there are min. two independent interoperable client and server implementations of it. Jim A. pointed out that the DAV:source property is simply a dead property containing an HREF, there should be nothing difficult to implement it. Translate header was used in place of the source property by some implementations. It is a Boolean switch to tell the server whether to interpret the resource or not. - John S. asked if people had considered using simple URL mangling to indicate the source, such as in PHP's .phps - Poor support for the lang attribute on properties. Maybe it is not used because there is some ambiguity over it in the specification? - The "property behavior" element in MOVE/COPY may not have been tested. - Discovering the root of the repository. Some clients relied upon "OPTIONS /" to respond with DAV information, although servlet implementations would require at least a URL segment. So should clients not rely on "/" being in DAV-space? Clients may use other means of determining the root of the repository. One suggestion [from the floor] was to use the authentication realm. - Security issues included those who use authorization headers from one request with subsequent requests on the same connection. - Cookies in WebDAV. Some servers require that client support cookies, i.e. for session look-up rather than re-authentication. Clients should not be expected to support cookies, but in these circumstances clients should support cookies if they expect performant servers. This is material for the implementer's guide. - Lock-null resources. LOCK followed by PUT, and LOCK followed by MKCOL are both required to be supported according to the spec., but no clients required the LOCK followed by MKCOL behavior. Consider dropping this from the spec. - LOCK followed by UNLOCK should cause the lock-null resource to disappear. Varying implementations were seen. - Support for "If-None-Match: ?" is unknown. - Discussion of status code when creating a lock-null resource, should it be 200 or 201? - Maybe lock-null resources should have a discrete MIME-type to distinguish it as a special resource. However, some server platforms don't remember the MIME-types but rely on the file extensions. - Lock permissions. Lock operations by non-lock creator. Should there be a principal in ACLs that allows 'lock stealing'? Servers should only allow privileged UNLOCK. - If: header confusion. Issues surrounding the size of the header value when dealing with deep collections, and combination problems. When combining values does it mean logical AND or OR? Jim A. to post grammar for the If: header onto the list. - URL escaping ? how to deal with href illegal characters eg., "?/New Folder", are they XML escaped or URL escaped or both, and in what order, e.g. UTF-8 encoding and HEX encoding. Recommended to take a look at Donald's refs to DSIG document on canonicalization. - (At this point the curtain falls and nearly crushes Lisa)! - Where does the xml:lang attribute go? Does anyone care? Maybe should state that implementations should support it anywhere as XML generators may move it up to the root. No objections to putting the lang attribute on the DAV:prop element. - Servers should return URLs with a trailing slash when referring to collections, however, clients should not rely on it. Consider making the standing convention stronger? - Note that URLs returned in a multi-status may be relative to the content-location returned in the response ? should be in the implementer's guide. - Date format: page 27 of the RFC2518 stands. Implementations should follow the spec in this regard. - Lock owner information. Should servers take the information passed by the client, or use information they know based on the client's authenticated principal? Agreed that the server should take the information passed by the client, and maybe augment the lock token information with "creator" as well. - Should clarify which properties are live and which are protected. - Meeting closed at 5:30pm.
Received on Wednesday, 15 August 2001 06:29:00 UTC