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 >