- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 26 Oct 2002 18:59:03 +0200
- To: <w3c-dist-auth@w3c.org>
Hi. We recently submitted our internet draft ([1]) to the RFC editor for publication as Informational (non-working-group) RFC. From the abstract: "Recent specifications extending the "Web Distributed Authoring Protocol" (WebDAV, [RFC2518]) like "Versioning Extensions to WebDAV" [RFC3253] and "WebDAV Access Control Protocol" [ACL] restrict the set of properties returned automatically upon a PROPFIND/allprop request in order to avoid the expensive computation of properties that the client in many cases isn't interested in. However, this change from the behaviour defined in WebDAV can lead to situations where clients need to perform two requests to retrieve all properties they are interested in (one using PROPFIND/allprop, then PROPFIND/prop enumerating the new properties that weren't reported upon the first request). This specification defines a backward-compatible extension to add specific properties to the set of properties returned upon PROPFIND/allprop, thus saving at least one PROPFIND request." The proposed solution is to use a backward-compatible extension to the PROPFIND marshalling (old servers if compliant to RFC2518 MUST ignore this element, because it's not define in RFC2518): <?xml version="1.0" encoding="utf-8" ?> <propfind xmlns="DAV:" xmlns:in="http://sapportals.com/xmlns/cm/webdav"> <allprop/> <in:include> <checked-in/> <checked-out/> </in:include> </propfind> This instructs the server to return all dead properties, the RFC2518 live properties, and additionally the RFC3253 properties DAV:checked-in and DAV:checked-out. This protocol extension has been implemented in both our client and server for over a year now and solves the issue stated in the abstract for us (when communicating with our own servers, that is). As the Internet Draft has been stable for several months, we feel it is ready for publication as RFC. At this point, we are looking for opinions from the working group about *how* this should proceed in the standards process. I'm aware of the following alternatives: 1) Decide that the problem as stated does not require a generic solution backed by a working group document. In this case, the Internet Draft (after possibly minor editorial changes) should proceed on it's path to publication as Informational RFC (the IETF standards process is defined in RFC2026, [2]). 2) Decide that this problem indeed should be resolved by a change/extension defined by a working group document. 2a) ...for inclusion into RFC2518bis, or 2b) ...to be published as a separate document (probably then as a "proposed standard", as defined in RFC2026, section 4.1.1). Feedback appreciated. Julian [1] <http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-02.ht ml> [2] <http://www.ietf.org/rfc/rfc2026.txt> -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 26 October 2002 12:59:37 UTC