Re: QA WG Response to SpecGL comments

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

Received on Sunday, 14 September 2003 01:38:51 UTC