Dominique,
Thanks for considering the issue. Unfortunately, I cannot
accept the limitations of QAWG scope as an excuse because key QAWG
documents imply (IMHO) that it is in scope: either the WG scope needs
polishing or requiring a security section is within the WG scope.
I think that most would agree that having a good security
section in a specification improves security and reliability of
implementations. Security (and reliability in general) is clearly a
quality issue. Better [quality] specifications are those with good
security sections (all other factors being equal) -- they often breed
better [more reliable] implementations.
I will now quote specific QAWG documents that define
(AFAIK) QAWG scope.
http://www.w3.org/QA/Activity
"The Quality Assurance (QA) Activity at W3C has a dual focus:
to solidify and extend current quality practices ..."
Being careful about and thinking ahead of the security of
implementations is a current quality practice (at least at IETF and
other forums I have access to).
http://www.w3.org/QA/Activity
Works on the quality of the specs themselves (...
in particular, that they are coordinated with the TAG).
TAG already deals with a growing number of security aspects/concerns
related to web architecture.
http://www.w3.org/TR/qaframe-intro/
Foremost amongst the purposes of defining a common QA
Framework is the principal goal of the QA Activity itself:
to improve the quality of W3C standards' implementations
in the field.
Again, having a good security section would improve the quality of W3C
standards' implementations in the field.
Please note that I do not expect QAWG to tell spec authors _how_ to
write a good security section. Such explanations may come from other,
more security-experienced W3C bodies or can be adopted from, say,
relevant IETF recommendations (as informative references). I expect
QAWG to tell spec authors to think about security and write a security
section. Period.
To summarize, I see no basis to "consider security requirements to be
outside of the scope of QA Framework" and hence cannot agree with the
resolution. For me to accept a negative resolution, either the QAWG
scope should be narrowed/clarified or a different reason should be
given.
Sorry for creating more work for you, but I think this issue is
important enough.
HTH,
Alex.
--
| HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
| all of the above - PolyBox appliance
On Fri, 12 Sep 2003, Dominique HazaÅ½l-Massieux wrote:
> Thank you for your comments on Last Call WD of "QA Framework:
> Specification Guidelines" (SpecGL). This is QAWG's response.
>
> Your reply -- whether you accept or reject QAWG's disposition of
> your comments -- is requested by September 26, 2003. If you do not
> reply by then, your default response is recorded as "Accept". If you
> need an extended deadline to send your comments, please let us know
> as soon as possible so that we can negotiate a new date.
>
> You will find QAWG's response to your comments in the "Disposition
> of Comments" (DoC) document [1]. Please note that [1] is for
> Specification Guidelines only. Operational Guidelines and
> Introduction specifications are being handled separately.
>
> In the descriptive information before the table in [1], you will
> find a complete description of the contents of the DoC table.
>
> If you do not accept QAWG's disposition of your comments, please
> provide details, including: your reasons; and, what changes to the
> dispositions would be required to satisfy you.
>
> Please copy the QAWG list on your reply (www-qa-wg@w3.org -- the Cc:
> of this message).
>
> Regards,
> For Lofton Henderson (QAWG co-chair, for the QAWG),
> Dominique Hazael-Massieux, SpecGL Lead Editor
>
> [1] http://www.w3.org/QA/WG/2003/09/SpecGL-DoC
> More specifically, the responses to your comments start at:
>