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

This is an excellent list.  I'll work on a version of this document with 
these updates and circulate by the end of next week.

Brad

Ian Hickson wrote:

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

Received on Tuesday, 6 December 2005 21:17:28 UTC