On 23/01/2008, at 5:36 PM, Jonas Sicking wrote:
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.
While the web architectural implications of a "magic" well-known
location are known, it's also an eminently practical solution, one
that's been used not only for P3P, but also robots.txt and site maps
(which leverages robots). Why is this problem so different that it
requires people to learn a whole new way to associate policy with
resources?
Saying "hixie is very much against it" utterly fails to convince me;
provide use cases, requirements, and specific rationale for the trade-
offs made and gain consensus on them. Document the good arguments.
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.
No particular argument there.
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.
It depends. Having a well-known location means that policy only has to
be retrieved once per site, rather than once per resource.
--
Mark Nottingham [EMAIL PROTECTED]
