W3C home > Mailing lists > Public > www-qa@w3.org > June 2003

Re: LC-67 leftover -- MUST use MUST?

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Wed, 25 Jun 2003 11:11:17 -0600 (MDT)
To: Lofton Henderson <lofton@rockynet.com>
cc: www-qa@w3.org
Message-ID: <Pine.BSF.4.53.0306251047470.5542@measurement-factory.com>

On Wed, 25 Jun 2003, Lofton Henderson wrote:

> The first part of LC-67 [1] asks, "must all [conformance
> requirements] use RFC2119 keywords?"
> This was originally addressed, including a proposed resolution, in
> email [2].  It was further discussed a bit at the Crete f2f without
> resolution [3].
> Alternatives:
> -----
> At the face-to-face, these alternatives seemed most popular:
> Alt.1:  yes, per the current wording of the (priority 1) SpecGL
> CP13.1 [4] and its rationale, all specifications must use the
> RFC2119 keywords [in the statement of conformance requirements].
> Alt.2:  no, the RFC2119 keywords are the recommended and preferred way, but
> other language is permitted (e.g., marked-up imperative voice statements),
> as long as the spec unambiguously defines what are its conformance
> requirements and how are they identified in the text.
> Alt.3:  as Alt.3, but the spec must particularly define the correspondence
> between its normative language scheme and the RFC2119 keywords.

Specs SHOULD use RFC 2119, IMO. I am surprised the issue is worth
debating. Clearly, some specs may want to have more conformance levels
than a single level offered by RFC 2119. In RFC 2119 "SHOULD" means
"MUST implement -or- MUST have reasons not to implement", and "MAY"
means "MUST implement -or- MUST NOT implement".

HTTP/1.1 tries to make two conformance levels out of RFC 2119, but I
believe it was an over-engineering mistake, and it did not really
affect implementations (everybody tries to implement MUSTs and
implements SHOULDs if it is not too much trouble).

Someday, I would like to write an RFC 2119 update clarifying the above
and including an accurate conformance statement for RFC 2119 users to

> ** Pro Alt.1:  per the rationale at [4], this forces spec writers to
> unambiguously indicate what are the conformance requirements, and
> makes it very easy for implementers, test builders, etc to find the
> conformance requirements.

Hmm... The rationale at [4] (Checkpoint 13.1) is already covered by
formal requirement of Checkpoint 13.2!



                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance
Received on Wednesday, 25 June 2003 13:11:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:32 UTC