Feedback for allprop/include proposal needed

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