[access-control] Requirements, UCs and design rationale [Was: Subject: Re: [waf] minutes from 9 January 2008 Voice Conf (fwd) ]

Ian, All,

On Jan 11, 2008, at 6:30 AM, ext Ian Hickson wrote:

> On a broader note, it is unclear to me why we are still discussing
> requirements. We have a perfectly fine specification, we should go  
> ahead
> and publish it and move on. We already have two specifications that  
> are
> dependent on the current design (XBL2 and XMLHttpRequest2).

My interpretation of the Process Document is the requirements must be  
documented before the spec can enter LC thus this discussion appears  
to be mandatory (section 7.4.2):


A Working Group's Last Call announcement is a signal that:

     * the Working Group believes that it has satisfied its relevant  
technical requirements (e.g., of the charter or requirements  
document) in the Working Draft;

That is, we are required to explicitly identify the spec's "relevant  
technical requirements". David's requirements document is a start but  
it needs work.

> I don't even understand the problems that have been raised. As far  
> as I
> can tell nobody has raised any real problems with the current  
> design; the
> OPTIONS suggestion seems to be based purely on theoretical concerns of
> spec purity, and the concerns of the client having the last say  
> appear to
> miss the point of the technology (which is entirely about preventing
> information leakage and protecting against new attack vectors on the
> client while enabling features that clients have previously blocked).

I think it would be helpful if we could point to a single place (e.g.  
wiki page, FAQ, design constraints section in the UC+Reqs doc, etc.)  
that describes the rationale used to substantiate the current design.  
For example, states why HEAD and OPTIONS are not used and identifies  
the requirements that justifies that design decision, etc.

Anne, would you be willing to do something like this?

Regards, Art Barstow

Received on Friday, 11 January 2008 17:54:30 UTC