--On Tuesday, May 07, 2013 08:23 +1200 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
On 07/05/2013 02:10, l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)uk wrote:
http://labs.apnic.net/blabs/?p=309
an excellent detective story on badly-written, poorly edited,
standards track RFCs leading to interop problems. Enjoy.
I don't that is quite right. The problem in this case is not
to do with linguistic quality. It's due to a lack of formal
verification among a set of interacting and cross-area RFCs.
(And the problem is wider, because there are two distinct
places in IETF standards where ABNF for the text
representation of IPv6 addresses can be found.) This is a case
where no amount of language editing would have helped.
Actually I used it a couple of months ago in a discussion with
some experts on formal verification, and they rather liked it
as a poster child for the need for formal methods in SDOs.
And that is another oddity and perhaps another lesson. The
robustness principle was formulated, not just as a general good
idea, but because of the understanding that there was little or
no aspiration in pre-IETF specifications to get every T crossed
and I dotted. That level of precision is required for formal
verification (about which there are other problems) or formal
testing and certification (about which there are a different set
of other problems). Not only was Jon aware that we often didn't
go into that level of detail, but there was a case to be made
that we didn't want to because it took too much time to get
after the documents right after the design and specification
were done (please reread that a few times).
Maybe things have changed, but, if one actually believes the
robustness principle, then, in the case Geoff cites, Exchange is
simply non-conforming -- not because the spec prohibits
rejecting on the basis of a fine distinction about IPv6 formats,
but because doing so is unnecessary, inconsistent with the
robustness principle, and, arguably, plain silly.
And that is the other thing we lost when "Proposed Standard"
went from "spec that might contain some problems, lack of
clarity, and less than wonderful writing as long as there were
no known technical defects" to "better get it right because it
is probably the last chance and people are going to build and
ship products on the basis of what it says".
We now have expectations consistent with specs that can be
formally verified and/or tested and that people will interpret
narrowly and a procedural model designed for specs that are much
less formal and complete.
john
john