W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

RE: [ACL] Principal Identity

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 22 Nov 2001 08:05:36 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B104EC8C63@SUS-MA1IT01>
To: Webdav WG <w3c-dist-auth@w3c.org>
Allowing a server to return a server-defined set of live properties
with an ALLPROP is fine with me.  I also agree that this should be
coupled with a deprecation of the use of ALLPROP by generic clients.

This allows a server to chose how "interoperable" it wants to be with
existing clients that use ALLPROP, without forcing it to do anything
egregiously inefficient (the 2518 properties and dead properties are
reasonable to require, because it is extremely unlikely that they will
be very expensive to compute).


-----Original Message-----
From: Daniel Brotsky [mailto:dbrotsky@adobe.com]
Sent: Wednesday, November 21, 2001 11:27 PM
To: Lisa Dusseault
Cc: Clemm, Geoff; Webdav WG
Subject: RE: [ACL] Principal Identity

At 6:51 AM -0800 11/21/01, Lisa Dusseault wrote:
>  > I feel that interoperability means that existing clients will
>>  continue to work "as well as possible" with the new definition of
>>  ALLPROP.  Since ALLPROP originally meant "all properties," and the
>>  objection has been "that can be too expensive for servers," I think
>>  the compromise is to have ALLPROP mean "as many of the defined
>>  properties as the server feels it's reasonable to compute."
>You have a very good point - existing clients will expect to see dead
>>  I think Geoff's suggestion (DAV live props and all dead ones) is a
>>  good guideline for servers, both because these properties are
>>  presumably cheap and because an existing client who just set a dead
>>  property is likely to be very surprised when ALLPROP doesn't return
>>  it.  I suggested adding "at least" because I think that gives servers
>>  the proper control over just how interoperable they want to be with
>>  old clients.
>However, although that proposal supports existing clients better, it isn't
>clearly defined, as I explained in a previous email today.

I believe that your example shows well that it's completely up to 
each server which properties are live and which are dead, and that 
any given server implementation may allow for configuration that 
changes this.  But that doesn't mean that the notion of a "dead 
property" is ill-defined for a given server and time of test.  Nor 
does it mean that a requirement that servers return "at least all DAV 
live properties and all dead properties (i.e., all non-live 
properties that would give non-404 responses when queried for by 
name)" can't be tested on any given server at any given time.  It 
simply means that it's at the server's discretion what properties are 
live, and that no test can be performed unless this is properly 
documented for the server being tested.

>>  Probably the place you and I really agree is that we'd both rather
>>  see ALLPROP go away entirely :^).  But I think we also agree that
>>  such a move would be too backward-incompatible.
>It's clear new clients must not expect allprop to mean all properties, but
>we also agree that old clients must be able to operate.  However if we
>define a clear behaviour for allprop or some replacement, then perhaps we
>should simply discourage use of allprop in revised 2518.

Actually I think we should do both :^).  I think we should adopt 
Geoff's proposed semantics for ALLPROP (with my "at least" addition), 
and I think we should *also* deprecate the use of ALLPROP by generic 
clients.  That way ALLPROP clearly becomes (i) a "quick and dirty" 
way of looking at an asset that's primarily used by older generic 
clients and is supported in that usage only for backwards 
compatibility; and (ii) a shortcut used by server-specific clients 
who know exactly which properties the server chooses to return on 

Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Thursday, 22 November 2001 08:06:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:24 UTC