W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 2008

Re: Security considerations, was Re: Area Director feedback on draft-reschke-webdav-search-15 re supported query complexity

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 12 Jul 2008 22:14:34 +0200
Message-ID: <487910AA.208@gmx.de>
To: Javier Godoy <rjgodoy@fich.unl.edu.ar>
CC: www-webdav-dasl@w3.org

Javier Godoy wrote:
> Julian, your recent posting of draft version 17 reminded me about this 
> thread.
> Sorry for my late reply, this week have been too complicated for me.
> 
> In order to not delay the Last Call, I think it can be closed with no 
> action
> (other than changes already applied in version 16).

Ok. If you think that something needs to be done, you can still make a 
proposal now (and also raise the point during LC, that's what it's for, 
after all).

> ...
>> Honestly, I don't think so.
>>
>> The text you're referring to was put in because the original feature
>> discovery in DASL was broken (in that the DASL header uses URIs, while 
>> the
>> request body uses expanded names), so this was put as an afterthought for
>> "modern" servers.
> 
> I'm not following you. Do you mean it is broken because "[although] the 
> URIs
> can be used to identify each supported search grammar, there is not
> necessarily a direct relationship between the URI and the XML element name
> that can be used in XML based SEARCH requests"?

Yes. In theory there could be an expanded name without an equivalent 
URI, and also there's no 1-to-1 relationship between URIs and expanded 
names.

> Identifying a grammar by URI, when it could be identified by namespace and
> element name is an unnecessary complication, but something we could live
> with: if a client doesn't know the URI, likely it will not know about the
> identified grammar, then providing the element name does not help (it 
> cannot
> write a query using that grammar);
> conversely, if it knows the grammar it will know the URI.

Right. It's mainly a notation problem, caused by the fact that the 
original authors didn't realize that there's no direct mapping between 
URI and expanded name. The right fix would have been to drop the DASL 
header, or to use expanded names or URIs instead. But even back then, we 
didn't want to break existing servers.

> Other thing I don't understand is why DAV:supported-query-grammar-set is
> REQUIRED when RFC 3744 is supported. If it comes to fix a flaw with the 
> DASL
> header, it is useful despite of whether RFC 3744 is supported or not. I
> guess it may be because "old" servers, implementing only the DASL header,
> didn't know about 3744, then the requirement only applies to newer servers
> (?)

The idea was that if a server implements RFC3253 or RFC3744, it's 
"modern" enough to implement the additional live property.

>>> SEARCH (at least, basicsearch) already defines it own
>>> mechanism for advertising privileges in QSD responses. A property for
>>> which the clien has no privileges is neither DAV:selectable,
>>> DAV:searchable nor DAV:sortable... and that should be enough.
>>
>> Which of course raises the question whether the result of QSD should
>> reflect privileges; this may be very hard to implement.
> 
> Not only hard to implement, but probably a bad idea...  Even though my 
> first
> though was that they should (not at a requirement level, but as a hint 
> about a
> restriction which is not described anywhere else), analyzing it 
> carefully, now I
> realize that QSD property descriptions and privileges are very 
> different: QSD
> describes the properties of all the resources searchable through the 
> arbiter, or
> the properties of all the resources within the specified scopes, while
> privileges are defined on a per-resource basis.

Right.

> ...
> Lack of RFC 3744 privileges is one possible interpretation of the actual
> wording: "the client does not have read access".
> 
> If one want to be explicit, one could say "Read access may be determined by
> Access Control Protocol [RFC 3744], or other server-specific 
> mechanisms." But
> i'm afraid it is very very obvious.

+1.

BR, Julian
Received on Saturday, 12 July 2008 20:15:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:10 GMT