Dean, I am struggling constantly with 2119 as an AD, because if I take
the letter (and the spirit) of 2119 at face value, a lot of people are
doing this wrong. And 2119 is a BCP; it's one of our process documents.
So I'd like this to be cleared up as much as you. I think there is
active harm in the misuse we are seeing.
To Ned's points:
On 1/4/13 7:05 PM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
>> +1 to Brian and others saying upper case should be used sparingly, and
>> only where it really matters. If even then.
>>
> That's the entire point: The terms provide additional information as to
> what the authors consider the important points of compliance to be.
>
We will like end up in violent agreement, but I think the above
statement is incorrect. Nowhere in 2119 will you find the words
"conform" or conformance" or "comply" or "compliance", and I think
there's a reason for that: We long ago found that we did not really care
about conformance or compliance in the IETF. What we cared about was
interoperability of independently developed implementations, because
independently developing implementations that interoperate with other
folks is what makes the Internet robust. Importantly, we specifically
did not want to dictate how you write your code or tell you specific
algorithms to follow; that makes for everyone implementing the same
brittle code.
Meh. I know the IETF has a thing about these terms, and insofar as they can
lead to the use of and/or overreliance on compliance testing rather than
interoperability testing, I agree with that sentiment.
OTOH, when it comes to actually, you know, writing code, this entire attitude
is IMNSHO more than a little precious. Maybe I've missed them, but in my
experience our avoidance of these terms has not resulted in the magical
creation of a widely available perfect reference implementation that allows me
to check interoperability. In fact in a lot of cases when I write code I have
absolutely nothing to test against - and this is often true even when I'm
implementing a standard that's been around for many years.
In such cases the use of compliance language - and yes, it is compliance
language, the avoidance of that term in RFC 2119 notwithstanding - is
essential. And for that matter it's still compliance language even if RFC 2119
terms are not used.
I'll also note that RFC 1123 most certainly does use the term "compliant" in
regards to capitalized terms it defines, and if nitpicking on this point
becames an issue I have zero problem replacing references to RFC 2119 with
references to RFC 1123 in the future.
All that said, I'll again point out that these terms are a double-edged sword,
and can be used to put the emphasis in the wrong place or even to specify
downright silly requirements. But that's a argument for better review of our
specifications, because saying "MUST do this stupid and couterproductive thing"
isn't fixed in any real sense by removing the capitalization.
The useful function of 2119 is that it allows us to document the
important *behavioral* requirements that I have to be aware of when I am
implementing (e.g., even though it's not obvious, my implementation MUST
send such-and-so or the other side is going to crash and burn; e.g.,
even though it's not obvious, the other side MAY send this-and-that, and
therefore my implementation needs to be able to handle it). And those
"even though it's not obvious" statements are important. It wastes my
time as an implementer to try to figure out what interoperability
requirement is meant by, "You MUST implement a variable to keep track of
such-and-so-state" (and yes, we see these in specs lately), and it makes
for everyone potentially implementing the same broken code.
Good point. Pointing out the nonobvious bits where things have to be done in a
certain way is probably the most important use-case for these terms.
Ned