Re: RFC2518bis: allprop deprecated (4.1)

Am Samstag den, 20. April 2002, um 22:15, schrieb Clemm, Geoff:

> 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).

I had an implementation of allprop-include at the last
webdav interop in my webdav-proxy. It did not break
any present servers (nor IIS/Sharepoint).

So, I would encourage (especially Deltav/ACL
capable client) developers to have a look at:
http://www.greenbytes.de/tech/webdav/

//Stefan

> 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 Sunday, 21 April 2002 05:20:20 UTC