- From: <Tim_Ellison@uk.ibm.com>
- Date: Fri, 4 May 2001 23:52:05 +0100
- To: w3c-dist-auth@w3.org
"Jason Crawford" <ccjason@us.ibm.com> wrote: > << > I think the key part of Geoff's post is "the subset that it can use". The > problem with allprop is that it will return all the live properties > irrespective of whether the client is aware of the properties' semantics. > Sometimes this is what the client wants, say if it is naively displaying a > property sheet; but most likely it is not since there is no way for the > client to interpret the values or know if/how they can be changed. > >> > Actually I'd think that property sheet case would be pretty common. It may be common, but it isn't very interesting, especially since a client likely cannot display the value in a meaningful way or update the value. > And > removing allprop isn't going to prevent people from doing the same thing... > now with two requests rather than one. And sometimes for wide directories > it will be difficult to avoid this (suspected) problem even without > ALLPROP. No dispute that people can write dumb and/or harmful clients. > If this is actually the pivotal concern, I think the best you can > do just warn people of the potential cost that we see of using allprop. > From there on in, let time tell if it's really a problem. If we discover > it is, let's *really* solves the problem then. I'm willing to remove > ALLPROP, but it doesn't sound like doing that really would solve the > problem and it's not clear if there is a problem. I'm actually indifferent to removing allprop -- but I do think that the default for no body and no Depth: header being allprop depth infinity is bizzare. > > It's the old NRA argument -- allprop doesn't kill servers, clients kill > > servers ;-) > At first I thought that analogy was flawed, but as I think about it, I > think that the situation is analogous. This discussion seems to have all > of the same aspects. The differences I see are... > > 1) I don't think it's clear that there actually is a problem in 2518 that > we need to solve. > 2) In 2518, the people that would be vicitimized by the concern are > actually in (more) control over whether they are vulnerable. (Client > programers can discover that they don't really want all those random > properties and perhaps conclude that it's slowing their response time and > stop using ALLPROP. I think clients can disconnect if a response is too > long. And I think servers (with guidance from us) can chose to reject > certain requests if they really feel that they are too expensive.) > > << > I have to agree that it is a stealth action to undermine (the effects of) > allprop. > >> > I'm guessing you're joking, but I'd like to hear why that was put in that > spec. Was there some issue involved that we haven't mentioned here? Not really. Delta-V was spec'd to not return all versioning properties in allprop requests _because_ it was felt that the response would be too expensive for servers to compute, and the scenarios where a client can really make use of all the versioning values taken at a point in time are limited if not minimal. If the issue is tackled in RFC2518 then there would be less incentive for Delta-V to take such a stance. > As it stands now, I have a mild preference for leaving allprop in. I'm > *very* willing to support another position if it will bring us to agreement > and not do any serious damage. > > J. > Tim
Received on Friday, 4 May 2001 18:54:46 UTC