Re: axfr-clarify's fraudulent claims of consensus

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Fri, 14 Feb 2003 17:25:40 -0500 (EST)
    From:        Dean Anderson <dean@av8.com>
    Message-ID:  <Pine.LNX.4.44.0302141553360.3790-100000@commander.av8.net>

  | 
  | On Fri, 14 Feb 2003, Andreas Gustafsson wrote:
  | > RFC1035 specifically suggests using separate data structures
  | > that ensure that no such mixing occurs:
  | 
  | The key word is "suggests", which has the meaning...

exactly what you think it does - but note, the suggestion relates to
an implementation technique, which certainly isn't going to be required.
Implementors are free to implement however they desire, as long as they
achieve the objective.

Now ask yourself why 1035 would bother even suggesting an implementation
technique.

Don't you think it entirely possible that it is because the requirement
(that which was to be implemented) is so fundamental to the design of
the DNS, that some kind of suggestion of how to actually comply with the
design was worth making?

Implementation methods are often "suggested" in circumstances like that.
That is, when it seems plausible that implementors might miss an important
point and just do it the "easy way", it is common for the spec to indicate
how the implementation can achieve the desired result - this way implementors
either just blindly copy the suggestion, or at least should think about
why they're doing it a different way, and ask themselves if their results
will be the same as the suggested method.

  | No. This isn't true either.  If we clarify AXFR to standardize the
  | _assumptions_ identically and concretely made by many implementors over a
  | long period of time,

I can absolutely guarantee to you that that will never happen.  No-one is
going to standardise a protocol that essentially says "send whatever data
you feel like sending, and believe whatever the other end sends you
without question" which is exactly what the early implementations did.

When we standardise something, we want to first be as sure as we can be
that the protocol is correct for its purpose.  We aren't always very good
at that, but that should certainly be a major aim - documenting something
that doesn't work is a waste of everyone's time.   AXFR as it has been
commonly implemented simply doesn't work reliably.

kre