Area Director feedback on draft-reschke-webdav-search-15

[Julian Reschke]

Hi,

I got initial IESG feedback on draft-reschke-webdav-search-15, which had
been sitting in state "publication requested" for some time.

A bunch of editorial issues have already been fixed, see
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html>
for the latest and greatest.

There are two outstanding issues concerning what clients can really
expect from a compliant server, though...:

1) Supported Scope
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-15.html#rfc.section.5.4.2>)

As far as I understand, the original authors wanted to allow cases where
a certain search arbiter could provide search functionality for a
distinct set of resources. Think http://google.com implementing SEARCH.
We all know that this hasn't been implemented in practice, but the
specification still allows it.

This means that clients can discover pro grammatically that a resource
supports SEARCH, and what grammars it supports, but not the scopes that
can be specified.

Now DAV:basicsearch is really designed for WebDAV resources. I assume
that all non-interactive clients assume that a search arbiter supporting
DAV:basicsearch really is capable of searching the URL namespace below
itself. Is this a sane assumption? Can we make that a SHOULD?


2) Supported query complexity

The security considerations allow a server to reject queries due to
their complexity
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-15.html#rfc.section.7>).
Is there any kind of minimum we can require servers to support?


BR, Julian

[Julian Reschke]

Hi,

I've finished those changes that were simple, please review
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html>
  and
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest-from-previous.diff.html>
for just the diffs.

Note that I have been encouraged to aim for "Proposed Standard", so
Appendix B has been renamed and rephrased accordingly.

With respect to one of the points mentioned earlier...:

> 1) Supported Scope
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-15.html#rfc.section.5.4.2>)
>
>
> As far as I understand, the original authors wanted to allow cases where
> a certain search arbiter could provide search functionality for a
> distinct set of resources. Think http://google.com implementing SEARCH.
> We all know that this hasn't been implemented in practice, but the
> specification still allows it.
>
> This means that clients can discover pro grammatically that a resource
> supports SEARCH, and what grammars it supports, but not the scopes that
> can be specified.
>
> Now DAV:basicsearch is really designed for WebDAV resources. I assume
> that all non-interactive clients assume that a search arbiter supporting
> DAV:basicsearch really is capable of searching the URL namespace below
> itself. Is this a sane assumption? Can we make that a SHOULD?

My proposal is to make this a "SHOULD", and to mention the lack of scope
discovery in the the "Future Extensions" appendix.

> ...

BR, Julian

[Jim Davis-7]

Julian Reschke wrote:

>>
>> As far as I understand, the original authors wanted to allow cases
>> where a certain search arbiter could provide search functionality for
>> a distinct set of resources. Think http://google.com implementing
>> SEARCH. We all know that this hasn't been implemented in practice,
>> but the specification still allows it.
>>
>> This means that clients can discover pro grammatically that a
>> resource supports SEARCH, and what grammars it supports, but not the
>> scopes that can be specified.

Yes, that is exactly the use case.  Back in the day it was Alta-Vista,
not Google, but that was precisely the idea.
>> Now DAV:basicsearch is really designed for WebDAV resources. I assume
>> that all non-interactive clients assume that a search arbiter
>> supporting DAV:basicsearch really is capable of searching the URL
>> namespace below itself. Is this a sane assumption? Can we make that a
>> SHOULD?
Yes, "SHOULD" makes sense.  "MUST" would not be right, of course, but I
agree that clients will make that assumption, so it ought to be encoded
into the specification.
> 1) Supported Scope
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-15.html#rfc.section.5.4.2>)
>
>
> My proposal is to make this a "SHOULD", and to mention the lack of
> scope discovery in the the "Future Extensions" appendix.
And I look forward to reading of progress in addressing this gap.

--
Jim Davis
http://www.econetwork.net/~jdavis
jrd3@...
416-929-5854

[Jim Davis-7]

Julian Reschke wrote:
> 2) Supported query complexity
>
> The security considerations allow a server to reject queries due to
> their complexity
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-15.html#rfc.section.7>).
> Is there any kind of minimum we can require servers to support?
In my opinion nothing is needed to address this.  For one thing, the
security concern, as stated, applies to all query grammars, not just
basic search, so if the spec addresses it, it either has to say
something so general as to be useless, or it can say something about
basic search alone.  And if we did state a minimum, would it be a SHOULD
or a MUST?  If a MUST, we'd have to set it fairly low, wouldn't we?

--
Jim Davis
http://www.econetwork.net/~jdavis
jrd3@...
416-929-5854

[Javier Godoy-2]

Jim Davis wrote:

> Julian Reschke wrote:
>> 2) Supported query complexity

[[
   A query must not allow one to retrieve information about values or
   existence of properties that one could not obtain via PROPFIND. (e.g.
   by use in DAV:orderby, or in expressions on properties.)
]]

IMHO this should be an uppercase MUST NOT, in order to emphasize that SEARCH
must comply with the Access Control Protocol (RFC 3744).
(At least, the DAV:read privilege must be honored, as well as DAV:read-acl
and DAV:read-current-user-privilege-set if DAV:acl is
searchable/selectable/sortable.)

>> The security considerations allow a server to reject queries due to their
>> complexity
>> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-15.html#rfc.section.7>).
>> Is there any kind of minimum we can require servers to support?
>
> In my opinion nothing is needed to address this.  For one thing, the
> security concern, as stated, applies to all query grammars, not just basic
> search, so if the spec addresses it, it either has to say something so
> general as to be useless, or it can say something about basic search
> alone.

Clients guessing by trial and error if their queries are allowed or not,
looks as a potential interoperability problem. However, the definition of
allowed queries is implementation-dependent, and if a query is "legitimate",
it should be already allowed; and if it is not legitimate, it may be
rejected or not (e.g: a non-legitimate query may be allowed if it is not
expensive and it does not compromise sensitive information).

I cannot think of a requirement which do not depend on the grammar. We could
assume that any grammar defines a select-like clause, criteria and scopes,
but that is not enough (for instance, the order element is specific of
DAV:basicsearch, and a query may be rejected because it requests too much
ordering on a big result set).

About DAV:basicsearch, one could say that if a PROPFIND succeeds in some
scope supporting DAV:basicsearch, then an equivalent query (unordered, with
no criteria, and selecting the same properties) should succeed unless any
property were not selectable. That is a formal minimum, but I don't think it
is useful enough, and I'm not sure if it should be a
requirement/recommendation. One could also say that if the criteria is
simpler than a minimum then it should succeed... but how would be that
minimum defined? How many and which expressions define a reasonable minimum?

Again, I think the answer is implementation-dependent.


Best Regards

Javier

[Julian Reschke]

Jim Davis wrote:
> ...
>> My proposal is to make this a "SHOULD", and to mention the lack of
>> scope discovery in the the "Future Extensions" appendix.
> And I look forward to reading of progress in addressing this gap.
> ...

OK.

So I changed 5.4.2 to:

5.4.2.  Scope

    A Scope can be an arbitrary URI reference.

    Servers, of course, may support only particular scopes.  This may
    include limitations for particular schemes such as "http:" or "ftp:"
    or certain URI namespaces.  However, WebDAV compliant search arbiters
    minimally SHOULD support scopes that match their own URI.

and added:

B.8.  Search Scope Discovery

    Given a Search Arbiter resource, there's currently no way to discover
    programmatically the supported sets of search scopes.  Future
    revisions of this specification could specify a scope discovery
    mechanism, similar to the Query Schema Discovery defined in
    Section 4.


Diffs:
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest-from-previous.diff.html>


BR, Julian

[Julian Reschke]

Jim Davis wrote:

>
> Julian Reschke wrote:
>> 2) Supported query complexity
>>
>> The security considerations allow a server to reject queries due to
>> their complexity
>> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-15.html#rfc.section.7>).
>> Is there any kind of minimum we can require servers to support?
> In my opinion nothing is needed to address this.  For one thing, the
> security concern, as stated, applies to all query grammars, not just
> basic search, so if the spec addresses it, it either has to say
> something so general as to be useless, or it can say something about
> basic search alone.  And if we did state a minimum, would it be a SHOULD
> or a MUST?  If a MUST, we'd have to set it fairly low, wouldn't we?

Indeed.

I do agree it would be a nice-to-have, I just don't see how to get there...

BR, Julian

[Julian Reschke]

Javier Godoy wrote:

> ...
> [[
>   A query must not allow one to retrieve information about values or
>   existence of properties that one could not obtain via PROPFIND. (e.g.
>   by use in DAV:orderby, or in expressions on properties.)
> ]]
>
> IMHO this should be an uppercase MUST NOT, in order to emphasize that
> SEARCH
> must comply with the Access Control Protocol (RFC 3744).
> (At least, the DAV:read privilege must be honored, as well as DAV:read-acl
> and DAV:read-current-user-privilege-set if DAV:acl is
> searchable/selectable/sortable.)
> ...

In the meantime, this says:

    A query MUST NOT allow clients to retrieve information that wouldn't
    have been available through the GET or PROPFIND methods in the first
    place.  In particular:

    o  Query constraints on WebDAV properties for which the client does
       not have read access need to be evaluated as if the property did
       not exist (see Section 5.5.3).

    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.

I'm not too enthusiastic to add more RFC3744 related language; after
all, some of the SEARCH implementations do not support RFC3744 anyway,
so it seems to be a better approach to describe this in terms of whether
the client is able to GET the content/PROPFIND a property (thus talk
about status codes, not RFC3744 privileges).

BR, Julian

[Javier Godoy-2]

----- Original Message -----
From: "Julian Reschke" <julian.reschke@...>
To: "Javier Godoy" <rjgodoy@...>
Cc: "Jim Davis" <jrd3@...>; <www-webdav-dasl@...>
Sent: Wednesday, July 02, 2008 12:29 PM
Subject: Re: Security considerations, was Re: Area Director feedback on
draft-reschke-webdav-search-15 re supported query complexity

>
> Javier Godoy wrote:
>> ...
>> [[
>>   A query must not allow one to retrieve information about values or
>>   existence of properties that one could not obtain via PROPFIND. (e.g.
>>   by use in DAV:orderby, or in expressions on properties.)
>> ]]
>>
> In the meantime, this says:
>
>    A query MUST NOT allow clients to retrieve information that wouldn't
>    have been available through the GET or PROPFIND methods in the first
>    place.  In particular:
>
>    o  Query constraints on WebDAV properties for which the client does
>       not have read access need to be evaluated as if the property did
>       not exist (see Section 5.5.3).

+1


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

There is either an omission in 5.16, or a not-so-obvious choice because of
compatibility or other issues (?) which may be explictly stated.

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


> so it seems to be a better approach to describe this in terms of whether
> the client is able to GET the content/PROPFIND a property (thus talk about
> status codes, not RFC3744 privileges).

I agree about not being too verbose about RFC 3744 details, but because of a
different reason: the *only* standard privilege (let alone the DAV:acl
property) from RFC 3744 that applies to SEARCH is DAV:read, which affects
both GET and PROPFIND. Generally, properties are controlled by DAV:read or
by a non-standard privilege aggregated under DAV:read. Therefore, the RFC
3744 language is not enough for defining the behavior of the SEARCH method
and GET/PROPFIND fits better.

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

However, a brief statement about RFC 3744 in Section 7 should not harm
anyone (just a suggestion, it is up to you, +1 anyway)


Best Regards

Javier

[Julian Reschke]

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 personally do not have a preference, and the DASL implementation I did
a few years back did not support DAV:contains anyway.

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

>> so it seems to be a better approach to describe this in terms of
>> whether the client is able to GET the content/PROPFIND a property
>> (thus talk about status codes, not RFC3744 privileges).
>
> I agree about not being too verbose about RFC 3744 details, but because
> of a different reason: the *only* standard privilege (let alone the
> DAV:acl property) from RFC 3744 that applies to SEARCH is DAV:read,
> which affects both GET and PROPFIND. Generally, properties are

Correct.

> controlled by DAV:read or by a non-standard privilege aggregated under
> DAV:read. Therefore, the RFC 3744 language is not enough for defining
> the behavior of the SEARCH method and GET/PROPFIND fits better.
>
> Furthermore, 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.

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

BR, Julian

[Jim Davis-7]

Julian Reschke wrote:

> Javier Godoy wrote:
>> ...
>> [[
>>   A query must not allow one to retrieve information about values or
>>   existence of properties that one could not obtain via PROPFIND. (e.g.
>>   by use in DAV:orderby, or in expressions on properties.)
>> ]]
>>
>> IMHO this should be an uppercase MUST NOT, in order to emphasize that
>> SEARCH
>> must comply with the Access Control Protocol (RFC 3744).
>> (At least, the DAV:read privilege must be honored, as well as
>> DAV:read-acl
>> and DAV:read-current-user-privilege-set if DAV:acl is
>> searchable/selectable/sortable.)

The original intention of this had nothing to do with access control.  
For one thing, there was no access control back then.  The point is that
a server should not expose properties for use in orderby or where
expressions that it would not be willing to have exposed via PROPFIND,
because a clever caller can deduce the value of a property even if it
could not read it directly.  For example, suppose the salary property is
considered private, but  if one selects where salary  > n one finds all
people whose salary exceeds n  By gradually increasing n, one can
identify the salary even though could not read salary directly.

Having said that, I don't know how to say this in the strict language of
MUST NOT.  For one thing, it depends on the query grammar.  With
basicsearch, you can do this with DAV:where or DAV:orderby, and perhaps
in other ways as well.  With other grammars, perhaps there are other
ways to leak the information.

--
Jim Davis
http://www.econetwork.net/~jdavis
jrd3@...
416-929-5854

[Javier Godoy-2]

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

[Julian Reschke]

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