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):
[[
<http://www.w3.org/2005/10/Process-20051014/tr.html#last-call>
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
---
