RE: Comments on "Authorizing Read Access to XML Content Using the <?access-control?> Processing Instruction 1.0"

On Mon, 5 Dec 2005, Brad Porter wrote:
>
> Certainly a good start would be to document the problems you've noticed.
> I am very happy to continue work on this, though we should move quickly
> to try to have it be a sponsored activity in one of the working groups.
> 
> Usually the biggest problem is finding willing participants to work on
> it.  Seems we have that, so hopefully finding the appropriate sponsoring
> group won't be hard.

Here's some of the issues we've found:

 * Make it clearer that *.acme.com matches acme.com and not just
   www.acme.com

 * It would be useful with a http-header that had the same functionality
   as the PI, as in:

      X-Access-Control: allow="foo bar" deny="baz"

 * Clarify what "combines" means in the sentence:

   # If the user agent encounters multiple <?access-control?> processing
   # instructions in the retrieved XML content, it combines them in
   # document order.

   The question also applies if there are multiple PIs and headers
   specified.

 * Require that the PIs appear in the prolog of the document, i.e.
   before the first element start-tag. This allows the implementation
   to stop downloading early and abort parsing before any elements are
   instantiated. Might even want it to be before other PIs (e.g. the
   stylesheet PI) so that we don't do anything (such as loading 
   remote stylesheets) before we know it's ok.

 * It might be better to fallback to default policy rather then
   to fallback to deny if there are PIs present but that not match the
   requesting server. In most cases default policy will be to deny
   anyway.

 * Would be good to explicitly specify behavior when the requesting
   resource is a non-remote protocol such as file:// or chrome://.
   Most likely that should just match.

 * Similarly, rules for how to handle, e.g., data: URIs.

 * A require-secure attribute is needed to protect against DNS spoofing.

 * Error handling should be very strictly defined -- the parsing rules for 
   the PI are vague in terms of error conditions, e.g.

 * The spec needs a coating of testable conformance criteria to more 
   clearly define what is compliant and what isn't (e.g. see the QA Spec 
   Guidelines).

 * Would be good to define handling of PIs that aren't in the prolog, e.g. 
   should it cause a well-formedness error to highlight errors faster?

This is based on:

   http://www.w3.org/TR/2005/NOTE-access-control-20050613/

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 6 December 2005 05:15:30 UTC