Subject: RE: New RFC2518bis draft

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 7 Jul 2002 14:16:56 -0400

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

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

lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 7 Jul 2002 21:20:12 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Sunday, July 07, 2002 8:17 PM
> To: Clemm, Geoff; [email-masked]
> Subject: RE: New RFC2518bis draft
>
>
>

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?

> the 'propname' request to find all the dead and live property names, and

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?

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