On 08/05/2013 08:33, Ned Freed wrote:
On 08/05/2013 03:28, John C Klensin wrote:
...
I'll also point out that this has diddley-squat to do with
formal verification processes. Again as Mark Anrdrews points
out, we deployed something with a restriction that
subsequently turned out to be unnecessary, and now we're stuck
with it. Indeed, had formal verification processes been
properly used, they would have flagged any attempt to change
this as breaking interoperability.
Also agreed.
To be clear, I'm no fan of formal verification either, but this
*is* a case where the IETF's lapse in formality has come back to
bite, and the Postel principle would have helped. Also, given the
original subject of the thread, I don't see how language editing
could have made any difference.
Reread the notes about the history behind this in this thread. You haven't
even
come close to making a case that formal verification of the standards would
have prevented this from happening.
You are correct if only considering the mail standards. I suspect
that a serious attempt at formal verification would have thrown
up an inconsistency between the set of mail-related standards and
the URI standard. However, I think the underlying problem here is
that we ended up defining the text representation of IPv6 addresses
in three different places, rather than having a single normative
source. (ABNF in the mail standards, ABNF in the URI standard,
and English in ipv6/6man standards.)
(Formal verification of implementation
compliance to the standards would of course have prevented Apple's client bug,
but that's a very different thing.)
You are, however, correct that this has nothing to do with specification
editing.
Ned