Mark Nottingham wrote:
On 23/01/2008, at 9:50 AM, Anne van Kesteren wrote:
On Tue, 22 Jan 2008 23:14:26 +0100, Mark Nottingham
<[EMAIL PROTECTED]> wrote:
On 22/01/2008, at 8:59 PM, Anne van Kesteren wrote:
On Tue, 22 Jan 2008 04:56:52 +0100, Mark Nottingham <[EMAIL PROTECTED]
[...] Separate from the server-side vs. client-side policy
enforcement issue (which I'm not bringing up here explicitly, since
it's an open issue AFAICT, although the WG doesn't link to its
issues list from its home page), the Working Group needs to
motivate the decision to have access control policy only apply on a
per-resource basis, rather than per resource tree, or site-wide.
It's not an open issue.
Let's have one, then. The W3C has already solved the problem of
site-wide metadata once, and there should be *some* reason for taking
a different path this time.
Actually, we have an open issue on this one and it's proposed for
closing as we have per resource policy requirement.
Perhaps it would be good to get consensus on requirements first...
At any rate, take a look at P3P, which does allow per-resource policy.
I think use cases for having per-resource access is pretty easy to come
up with. I'd rather ask, why would per server, or even per directory, be
enough?
So P3P has a few ways to associate policies with documents [1]:
1. "magic uri"
The policy file is located at a magic uri that is defined in the
specification. We've gotten a lot of negative feedback about this
approach before, I know hixie is very much against it and has provided
good arguments in the past.
2/3. <link> tag.
My main concern is that this is very (X)HTML specific. Especially since
most of the use cases I've heard described has been about transferring
non-html files cross domains. It also forces the implementation to parse
potentially the whole resource before being able to determine the access
policy.
Generally the PI syntax in the access-control spec seems like an
improvement over this solution.
4. HTTP header.
This is a header that contains a pointer to the actual policy file.
Seems like our solution of actually putting the access policy inside the
header instead results in a much less chatty implementation.
/ Jonas
[1] http://www.w3.org/TR/P3P/#ref_syntax
