- From: Javier Godoy <rjgodoy@fich.unl.edu.ar>
- Date: Sat, 12 Jul 2008 16:21:23 -0300
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: <www-webdav-dasl@w3.org>
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). On Wed, 02 Jul 2008 21:24:16 +0200, Julian Reschke wrote: > > Javier Godoy wrote: >> ... >>> o Query constraints on content (as with DAV:contains, defined in >>> Section 5.16) for which the client does not have read access need >>> to be evaluated as if a GET would return a 4xx status code. >> >> And is the result of this evaluation FALSE? or is it UNKNOWN? >> I would expect the latter because expressions on properties evaluate as >> UNKNOWN when the property is not defined, but Section 5.16 states that [[ >> The DAV:contains operator (...) evaluates to TRUE if the content of the >> resource satisfies the search. Otherwise, it evaluates to FALSE. >> ]] > > Would that be a problem? I think it is a detail, not a problem. IMHO it would be more correct to define UNKNOWN as the result of non-evaluable operands about the content, instead of FALSE, but I also think it has no practical implication. When "not contains" is applied to a resource for which the client has no read access, it would evaluate as TRUE (instead of UNKNOWN) . Then a query criteria specifying "other_condition AND not contains" would be evaluated as: other_condition AND not FALSE = other_condition instead of other_condition AND not UNKNOWN which may be FALSE (if the other condition is false) or UNKNWON (if other_condition is UNKNOWN or TRUE) But criteria like "other_condition AND not contains" seems not to be very useful (e.g., Content-Length <=1024 AND not contains "foobar"). (Just out of curiosity I asked Google for "not contains foobar" and it found 2 results: http://tinyurl.com/6ajobc ;-) > I personally do not have a preference, and the DASL implementation I did a > few years back did not support DAV:contains anyway. As explained above, I do not see a reason for evaluating as FALSE, and I think an implementation doing so would be faulty, but that fault would be (almost) imperceptible. The truth value UNKNOWN is explained in detail in Appendix A, and that explanation is consistent with the case under discussion. >>> I'm not too enthusiastic to add more RFC3744 related language; after >>> all, some of the SEARCH implementations do not support RFC3744 anyway, >> >> IMHO, if the DAV:supported-query-grammar-set property is REQUIRED when >> both RFC 3744 and SEARCH are supported, then the interaction between both >> extensions should have been regarded as important at some point in the >> developement of DASL / SEARCH. > > 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"? 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. 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 (?) >> 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. The client may have read access for some property in a sub-scope of the scope being described by QSD, then the server should look up ACLs for every resource within scope before considering some property as "not searchable" (it will be easy if the client is never allowed to read that property, otherwise I think it may be too much computation for nothing). Other caveat: "If a property does not have such a description, or is not described at all, then the server MAY still allow the property to be used in the corresponding section." (section 5.9.12). The interpretation of omitted descriptions is up to the client (which I think will suppose the query is allowed, or will not care about the QSD at all) . >> However, a brief statement about RFC 3744 in Section 7 should not harm >> anyone (just a suggestion, it is up to you, +1 anyway) > Any proposals? 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. Best Regards Javier
Received on Saturday, 12 July 2008 19:23:48 UTC