- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Sun, 8 Sep 2002 14:27:27 +0200
- To: <w3c-dist-auth@w3.org>
Hi, again apologies for us not attending the meeting. However, I'd like to contribute to the upcoming WG meetings by summarizing the status of our various WebDAV related activities. 1) Internet Draft "Datatypes for WebDAV properties" [1] Initially, this only covered marshalling of type information for WebDAV properties. It builds on the datatype part of XML schema (not the structure part), and is compatible to what other XML vocabularies do (for instance, SOAP). It's also very similar to the type system in Microsoft IIS, Exhange and Sharepoint -- the main difference being that it's based on W3C recommendations. This part of the draft has been stable since almost a year, and support has been present in shipping SAP Enterpise Portal servers for several months now. Recently, we have started to extend the draft to marshall information that should make it possible for generic clients to treat a resource's properties in a more meaningful way. It includes - flags ("hidden" and "protected") -- this is already in the draft, and - display names (language dependant). We attempt to come up with a common proposal with Eric Sedlar (Oracle). At this point, we're also interested in feedback from authors of generic clients, such as TeamStream, WebDrive, kCura, Adobe and (yes) Microsoft. 2) Internet Draft "Computing the CHECKIN URI in WebDAV versioning" [2] This has been stable for several months now and is implemented in shipping SAP Enterprise Portal servers. From the abstract: "In many cases, a versioning-aware client might want to display/include the URI of the version it's editing while it's being edited. For instance, an editor might include this as meta information, or the author of a document might want to know the URI of the version before it's checked in. A well-known example is the W3C way of referring to document versions in recommendations: it contains references to "the current version", to "this version" and to the "previous version". Something like this is currently impossible with WebDAV versioning [RFC3253], as the version URI is determined at the time of CHECKIN." We will probably submit it for publication as Informational RFC soon, unless other WG members file like participating in this activity. 3) Internet Draft "Including additional properties in WebDAV PROPFIND/allprop requests" [3] Again, this has been stable for several months now and is implemented in shipping SAP Enterprise Portal servers. From the abstract: "Recent specifications extending the Web Distributed Authoring Protocol (WebDAV) restrict the set of properties returned automatically upon a PROPFIND/allprop request. This specification defines a method to add specific properties to the set of properties returned upon PROPFIND/allprop." The current draft has been submitted to the RFC editor for publication as Informational RFC two weeks ago. 4) WebDAV SEARCH [4] This draft is very slowly progressing and is fully supported in the current SAP Enterprise Portal version. The main open issues are: - whether or not the section describing the SEARCH method in general should be rewritten to specify RFC3253-like error response marshalling (needs editorial time and commitment from current implementors to change/upgrade implementations) and - cleanup of DAV:basicsearch, mainly to properly define valid lexical value spaces, and how datatypes relate to the various operators (such as: string collations and so on) 5) WebDAV Ordered Collections Protocol [5] We feel that this protocol is stable, and we have volunteered in March to resubmit it after clean up. We still plan to reformat the draft to use RFC3253-based error marshalling. 6) WebDAV Bindings [6] We are very interested in this draft and have the necessary code in place to support the protocol. In fact, our test server implementation (see "Always-On Interop Server" mailings) supports the DAV:resourceid property. It probably would be good if there would be a generally accepted URI scheme in place -- I propose to work with Michael Mealling (Verisign) to get the features we need (basically the same as in in the RFC2518 "opaquelocktoken" scheme) into the UUID URN namespace. 7) WebDAV Redirect Reference Resources [7] We have implemented this draft, and are *very* interested in getting better client support for it. At a minimum, clients should be able to correctly process a server's 302 response (for instance, the basic MS webfolder client doesn't on PROPFIND, but the newer versions shipping with Sharepoint and Office XP do). 8) Other Stuff - We support the plan of adding DAV:ishidden into RFC2518bis -- a conforming server wouldn't need to do more than persist it as dead property. Conforming clients would just treat a value of "1" as signal not to display a resource in it's UI. - We support extending DAV:activelock to optionally provide the root of a deep lock, as described in [2]. If there's interest, we may be able to enable support for it on our public test server before the end of the interop event. - I think we need to clarify the relationship between WebDAV and HTTP variant handling. This should go into a separate document. - We should consider the relation of the various new WebDAV methods/HTTP headers to RFC2774 (HTTP Extension Framework). Should we use that framework in future work? Julian [1] <http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-la test.html> [2] <http://greenbytes.de/tech/webdav/draft-reschke-deltav-compute-checkin-uri-l atest.html> [3] <http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-lates t.html> [4] <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html> [5] <http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest .html> [6] <http://greenbytes.de/tech/webdav/draft-ietf-webdav-binding-protocol-02.html > [7] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0049.html> [8] <ftp://ftp.isi.edu/in-notes/rfc2774.txt> -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 8 September 2002 20:37:39 UTC