Minutes from WebDAV WG meeting March 19, 2002 53rd IETF, Minneapolis Reported by Larry Masinter, Adobe Chair present: Lisa Dusseault, Xythos Status of Various Efforts ------------------------- DeltaV: The DeltaV working group is closed, however issues are still being discussed actively on the working group mailing list. No interop events are planned as yet. Q: Any clients for DeltaV? TeamStream (Xythos web file client) is a very limited client. Might assume that server vendors have clients. SubVersion has a client, but will only work with SubVersion for a while. Interop Plans: WebDAV to Draft Standard requires demonstration of interoperability of various features between independent implementations. First interop was last August, another last fall, want to start again this spring. Suggestion from Brotsky: schedule rolling, round-robin, server interops, e.g., server-client pair have dates for focus on interop issues. Match servers with clients every month. Some folks were interested. Access control: in last call. Some discussion of special-purpose principal search reports. DASL draft: Revived in WebDAV WG rather than defunct DASL WG. Julian Reschke planning 2 separate drafts. The framework draft will cover the model and the request/response syntax. A separate mailing list exists for DASL, but some comments are mirrored on the WebDAV mailing list. Search framework issues: character comparison, how to discover what search arbiter to search namespace portion, what are search arbiters? Not special resources. Is any collection a potential search arbiter? Need for "more results" query. Issue: there is some overlap of issues between DASL and XML Query. However, XML Query doesn't handle marshalling, for example. Coordination between DASL and XML is needed. Query: member of XML Query working group will review DASL. Individual drafts related to WebDAV: - tickets (proposal to support tickets for access control by unnamed users) - quota (proposal to expose 2 named properties to handle quota on collections: size and quota limit in bytes) - property datatypes Proposal to W3C to do XML element datatyping, predated XML schemas - Ordering Long list of dead drafts & proposals either dead or sleeping - bindings, redirect references, ordered collections, property registration proposal, property namespace and allprop, use of dublin core metadata in dav, additional webdav ... (take from slide) comment: since drafts expire after 6 months, these proposals are dead unless re-raised. Issue of differing use models driving WebDAV development in different directions - use WebDAV as a file system. - Use to work on local repository and publish/share to WebDAV. - Synchronized use model, work on local store and sync, work from any machine, online or offline. - Acrobat use webdav repositories for annotations when not for the documents themselves. - Webdav for Web Site authoring and not for much for file sharing. Some evidence: webdav getting more interest from PC users, increasing press. WebDAV tutorial at AIIM (document & content management folks). Many document management tutorials. Article in PC magazine. RFC 2518bis (potentially) closed issues --------------------------------------- For moving to Draft, need two independent interoperable implementations of every feature: two clients & two servers for each feature. Use and meaning of allprop? If allprop doesn't mean "all properties" what does it mean? Proposal: all properties defined in 2518 plus all dead properties client sets, but not live properties defined in other drafts. This has already been put into practice by servers, and that wasn't an issue at the interop event. Who controls lock owner field? Client does. If a server-controlled field is needed, this will have to be done in a separate draft, not in RFC2518 bis. When to refresh a lock timeout? Nobody implemented what the document said. New model: only a lock refresh request refreshes the lock. Where root of repository may be? Some clients couldn't handle servers where path elements that aren't webdav resources. Some servers couldn't do what some clients wanted. This has been clarified, in http://host/a/b/c/d, http://host/a/b might not be a webdav resource. lock-null resources were removed from the spec. Most of the complex lock-null features weren't being used. A simpler model of creating a locked empty regular resource seems to be interoperable, it even work with clients that can lock unmapped URLs. Removed propertybehavior feature. Open issues in RFC2518bis ------------------------- If header Don't know what to do with the 'if' header. Ambiguities in the specification lead to clients not implementing complex behavior. The syntax doesn't support multiline values, which could mean problems when large header values must appear all in one header. E.g. IIS5 locks only resources, not collections, which results in many more locks in some situations. Operating on a collection containing many locked resources requires specifying different tagged lock tokens for each resource in If header. This results in such header length that web intermediaries cause problems. How to apply with Depth and Destination headers? "If" header confuses two purposes: - conditional which clients requires to be met - provision of lock token, which server requires to be there Implementations seem to be more forgiving than spec suggests. Can we demonstrate use or interoperability for Tagged production? boolean combination logic support? Use of ETags in "If" header? Proposal: only use "if" header for a list of lock tokens. Possible fix: add a header that does only one thing well, comma-delimited lock tokens? Possible fix: describe current behavior of the if header, and leave it at that. Dirk: If no-one is using the original if-header as originally specified: it's like there are two 'if' headers, maybe would allow existing syntax that clients use to be continue to be used, but in a more liberal way. This is one of the thorniest issues. Source Property Another remaining issue: with the 'source' property. Have there been any implementations? (appears to be none) Proposal: remove 'source' property Those against this proposal (not present but their arguments were recapped) say that one can't use WebDAV for what it was originally intended to do, without source property Those against this proposal fall into two camps. 1: source property is fine, we just need to put ourselves out to demonstrate interoperability. 2: source is not fine, let's use replacement that actually works Does the source property actually works? One known problem with source property: 2518 doesn't define how to present and describe multiple sources Brief discussion of using (Microsoft) Translate header. It's a boolean flag in a header. What it really means is "I'm in authoring mode" or "I'm in browsing mode". If header is missing, browser is assumed. "Translate: F" when present asks for source rather than result. This is included in all authoring client requests. Although Translate doesn't handle multiple source files directly either, it's possible that it addresses scenarios that are required to be addressed. May have some advantages. For example, since it's present on all requests, the server can infer other preferences like 'PROPFIND returns size of original files'.