On 24/01/2008, at 12:11 PM, Ian Hickson wrote:
On Thu, 24 Jan 2008, Mark Nottingham wrote:
The heart of the issue is how policy is discovered; the current ED
uses
a per-resource OPTIONS, while almost every other solution in this
space
uses a well-known-location.
robots.txt is a per-domain policy (to prevent a host from being
overwhelmed); there are per-resource ways of controlling spiders as
well.
So why not take that approach? E.g., HTTP headers / PI for safe
methods, well-known location (or an addition to robots.txt) for unsafe
methods.
p3p.xml is a per-domain policy intended to be fetched before the
resource
in question is fetched, for reasons that don't apply here. There are
also
ways of providing per-resource information for this policy.
Furthermore,
P3P has had such a poor uptake that I don't think it's a good thing to
look at.
For reasons that are completely unrelated.
Sitemaps are site-specific (domain-specific) and are intended to act
as a
manifest for other resources, and thus wouldn't make sense at a
per-resource level.
None of these seem appropriate precedents for Access Control, which is
specifically a per-resource concern.
What does that really mean? Whether or not a spider can access
something, whether or not a privacy policy applies, and what metadata
is associated is also a "per-resource concern."
The decision to Recommend a new mechanism for discovering policy
shouldn't be taken lightly.
I hardly think that HTTP headers and "OPTIONS" can be called a "new
mechanism". After all, every per-resource policy mechanism uses them
already!
Which other per-resource policy mechanism uses OPTIONS (discounting
WebDAV, which is a stretch here)? I have no quarrel with using HTTP
headers / PIs for GET responses; it's the per-resource authorisation
request (whether OPTIONS or GET) that is problematic.
I've pointed out several problems with the current proposal, and
haven't
received satisfactory responses to many of them.
As far as I can tell, all feedback has been responded to -- can you be
more specific as to what technical feedback hasn't been answered?
* Inability to cache OPTIONS, and the resulting problems for scaling
this mechanism by caching policy in anything but the client
* per-resource OPTIONS requests are too chatty, don't scale to large
numbers of resources, eventually causing developers to come up with
workarounds such as boxcarring messages
* Access-Control syntax is still suboptimal
--
Mark Nottingham [EMAIL PROTECTED]
