RE: New RFC2518bis draft

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Sunday, July 07, 2002 8:17 PM
> To: Clemm, Geoff; w3c-dist-auth@w3c.org
> Subject: RE: New RFC2518bis draft
>
>
>
> > Lisa: I noticed that you did not respond to Julian's concern
> > about deprecating DAV:allprop.  Does this mean that you agree with
> > his proposal to have it mean "2518 properties and all dead
> properties"?
> > Note that I am happy to have DAV:allprop be given this interpretation.
>
> With an issue as difficult as "allprop", where it was originally given a
> meaning that we cannot continue to support, I do not believe that every
> concern can be completely addressed. I think all of Julian's concerns
> are valid and share them, yet we still have to compromise among these
> concerns to find a solution.
>
> The proposed text in 2518 bis does deprecate allprop as well as redefine
> it to a certain extent. If 'allprop' is redefined, without being renamed
> or deprecated, it will cause confusion for new implementors.  Here are
> some of the options:
>  1) Deprecate.
>  2) Redefine and leave in place.  Disadvantage: confusion to new
> implementers who will be misled by the apparent meaning of 'allprop'
> into misunderstanding what it does.

Advantage: this is the current situation with RFC3253 and the ACL spec, and
this doesn't seem to cause any confusion at all. All we need is to clarify
RFC2518.

I agree that the name "allprop" will be a bit confusing. But that's
something that can be solved by properly explaining it, right?

>  3) Rename and redefine (e.g. 'deadprop', defined to return all the dead
> properties).  Disadvantage: servers that were previously compliant with
> 2518 will not be compliant with 2518bis.
>
> No functionality is lost by deprecating allprop - clients can always use
> the 'propname' request to find all the dead and live property names, and
> select among those.

Yes, but at greatly increased cost, both in number of roundtrips, client
complexity and computation time in the server. I've explained this in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JanMar/0186.html>:

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

In particular this means that if a client really *wants* propname, the
server will have to compute whether each and every live property is present,
while with the current RFC3253 definition of allprop, adding new live
properties doesn't cause any additional overhead *at all*.

Could you please address this concern?

> I'd like to see broader support for one of the other options and
> discussion of the tradeoffs before changing the current proposed text.

Actually, I'd like to see a broad discussion before changing the *current*
status, as defined by RFC2518/3253.

Received on Sunday, 7 July 2002 15:20:56 UTC