LC-2067: Conformance statement - MUST and SHOULD

The Last Call comment:
http://www.w3.org/2006/02/lc-comments-tracker/37584/WD-ct-guidelines-20080801/2067

As text:
"* Section 3.4 / 3.5 "A [Content|Transformation] Deployment conforms to
these guidelines if it follows the statements..."  What does "follows"
mean here -- if they conform to all MUST level requirements? SHOULD
and MUST?"

Indeed, the more precise we are in the Conformance section, the better.

Conformance to MUST is implied, but we'd better write it down explicitly 
anyway.

Conformance to SHOULD must be stated, because different specifications 
use SHOULD (or equivalent) differently. For instance:
- QA Framework Specification Guidelines - SHOULD statements are totally 
optional
   [[ Good Practices use the same imperative voice, but are optional. 
They are equivalent to SHOULD or RECOMMENDED statements in the RFC2119 
style. Their implementation or non-implementation does not affect 
conformance ]]
    http://www.w3.org/TR/qaframe-spec/#conformance-criteria

- Web Security Context: User Interface Guidelines - SHOULD statements 
define a second conformance level
  [[ A user agent conforms to this specification at the [Definition: 
basic level] if it honors all MUST and MUST NOT clauses of this 
specification.
  A user agent conforms to this specification at the [Definition: 
advanced level] if it also honors all SHOULD and SHOULD NOT clauses of 
this specification. ]]
   http://www.w3.org/TR/2008/WD-wsc-ui-20080724/#conformance-levels

We use them with a different meaning, closer to the definition of SHOULD 
in RFC 2119: we know there are valid cases when our SHOULD statements 
may not be followed and we expect conforming products will justify 
themselves when not following them.

Given the number of comments received on section 4.1.5 Alteration of 
HTTP Headers values that sound like "yeah, but that's only a SHOULD, 
CT-proxies are free to do whatever they want", I think we could go even 
further than just stating the above in the Conformance Section: we could 
define an Implementation Conformance Statement (ICS) to be filled out by 
products that want to claim conformance to the spec. See for instance:
  * ICS for the above-mentioned QA Framework Specification Guidelines - 
http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/specgl-ics.html
  * an example of ICS for WEBCGM: 
http://www.sdicgm.com/cgmopen/sdi_print_master

The ICS would require justifications for the cases where SHOULD 
statements are not followed, and although that involves more paperwork, 
it seems to fit our case and needs. I would be happy to take an action 
to dig into that direction and prepare a draft ICS, but I want us to 
discuss that beforehand within the task force so that I don't start 
working for nothing...


In any case, I propose the following draft text to replace current 
sections 3.4 and 3.5.

[[
3.4 Content Deployment Conformance

A Content Deployment conforms to these guidelines if it honors all MUST, 
NUST NOT, SHOULD and SHOULD NOT statements in 4.2 Server Response to 
Proxy. A Content Deployment that does not honor SHOULD and SHOULD NOT 
statements in some cases MUST justify itself to claim conformance to 
these guidelines.

3.5 Transformation Deployment Conformance

A Transformation Deployment conforms to these guidelines if it honors 
all MUST, MUST NOT, SHOULD and SHOULD NOT statements in 4.1 Proxy 
Forwarding of Request, 4.3 Proxy Forwarding of Response to User Agent 
and 5 Testing (Normative). A Transformation Deployment that does not 
honor SHOULD and SHOULD NOT statements in some cases MUST justify itself 
to claim conformance to these guidelines.
]]


It's a bit clumsy, I should say, and my immediate reaction to my own 
text is: yes, but where and to whom do they justify themselves? That 
could be answered with an ICS, or with a lighter "Conformance claim" 
section that would define a template claim.

Francois.

Received on Friday, 12 September 2008 13:55:16 UTC