RE: RFC2518bis: allprop deprecated (4.1)

Just to follow up on this thread from a couple of months ago:

I would be happy to see allprop defined as being:
"all 2518 props and all dead props".  I also support the
allprop-include extension, but that would have to be
specified in a different standard track, since it is 
new functionality (unless we can get some interoperable 
implementations out there fast).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, February 28, 2002 12:22 PM
To: Webdav WG
Subject: RE: RFC2518bis: allprop deprecated (4.1)


Following up to my own post:

the last WG meeting minutes (at
<http://www.ietf.org/proceedings/01dec/127.htm>) say:

"What 'allprop' means....

MUST include all 2518 props and all dead props to maintain interrop. However
new live props in ACL DASL etc are being defined as NOT returned by allprop.
Property dead on one server may not be dead on another server. allprop is
historical. Promote using propname. Is it legal for Xythos to use the adobe
namespace? You could have a property that is defined dead on one server be
live on another!

allprop must return all properties required for interrop.

Eric - property should be defined dead or non-nead...you can't mix and
match.

Should we deprecate allprop?
Perhaps use allprop-include or other mechanism to save roundtrip and
deprecate allprop. Sitecopy properties would not be the same. Is deprecate
something we can do in IETF? Take it out and reference them back to the old
draft. Geoff - Short description plus reference back to old spec. We took a
vote and 3 people would like it to become a info note, nobody objected."


I'm not sure I understand what the last paragraph says. I certainly do *not*
agree to remove allprop without replacing it with something which is as
efficient. See remarks in my previous mail.

Julian

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
> Sent: Thursday, February 21, 2002 9:52 AM
> To: Lisa Dusseault; Webdav WG
> Subject: RFC2518bis: allprop deprecated (4.1)
>
>
> Lisa,
>
> I don't agree at all with the deprecation, and I don't think that
> there was
> consensus about this.
>
> The draft says:
>
> Clients MUST not send allprop requests in any form (either the empty body
> PROPFIND or the specific allprop element), because allprop is
> being removed.
> WebDAV servers increasingly have expensively-calculated or lengthy
> properties (see DeltaV and ACL specifications [TODO: ref RFC when
> available]) and do not return all properties already.  Instead, WebDAV
> clients can use propname requests to discover what properties exist, and
> request named properties when retrieving values.  A WebDAV server MAY omit
> certain live properties from other specifications when responding to an
> allprop request from an older client, and MAY return only custom (dead)
> properties and those defined in this specification.
>
> In particular:
>
> "WebDAV servers increasingly have expensively-calculated or lengthy
> properties (see DeltaV and ACL specifications [TODO: ref RFC when
> available]) and do not return all properties already."
>
> -> This is an argument for *restricting* the set of properties returned on
> allprop, not for removing the feature (and that's what deltaV does).
>
> "Instead, WebDAV clients can use propname requests to discover what
> properties exist, and request named properties when retrieving values."
>
> -> And the benefit is? The client will issue two calls: first it will use
> propname to find the list of properties. Computing whether a live property
> exists maybe as expensive as computing it (for instance, to find
> out whether
> something is checked in/out). *Then* it will submit PROPFIND /
> prop will all
> these properties. So as compared to the current situation, the server may
> have to compute things twice which wouldn't have been computed at
> all before
> (since asking for allprop wouldn't require computing live deltaV
> properties).
>
> -> Even leaving the propname vs live properties issue out, this
> doesn't make
> sense. You are removing a working and interoperable protocol
> feature without
> sound reason. As a fallback you offer a workaround which requires at least
> one additional trip to the server, possibly heavy computation on
> the client
> (computing the set of all property names on the members of a
> collection) and
> then additional marshalling (when I do a PROPFIND/prop with a long list of
> (dead) property names on a collection with depth 1, the server
> will have to
> 404-status them for many collection members).
>
> -> I agree that PROPFIND needs to be cleaned up, but this is not
> the way to
> go. The draft continues with:
>
> "A WebDAV server MAY omit certain live properties from other
> specifications
> when responding to an allprop request from an older client, and MAY return
> only custom (dead) properties and those defined in this specification."
>
> -> I think this may make sense. We will however need a way to get all dead
> properties and a set of named properties with a single request
> (see [1]). We
> may also have to find a way for a client to discover that something is a
> live property.
>
>
> [1]
> <http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-allprop
-include-l
atest.html>

Received on Saturday, 20 April 2002 16:16:29 UTC