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@xxxxxxxxxxxxxxxxx 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