Re: in support of axfr-clarify

["D. J. Bernstein" <djb@cr.yp.to>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  your subscription address is
  54830374684695-namedroppers@sublist.cr.yp.to, please post from it or
  fix subscription your subscription address! ]

Kevin Darcy writes:
> you've been bending the _de_facto_ rules in these regards (e.g.
> "section agnosticism" or whatever you call it)

How is it possible for people to be so fundamentally confused about such
a simple issue?

RFC 1034 says that the AXFR server sends ``messages'' that ``carry'' all
the records. This is ambiguous: does ``carry'' refer to all sections of
the message, or is it restricted to the answer section?

I decided to take the safest possible interpretation:

   * My AXFR _server_ puts all records in the answer section, just in
     case some clients look only at the answer section.

   * My AXFR _client_ reads all sections, just in case some servers use
     other sections.

The accusation that I'm ``bending the rules'' is utterly without merit.
I am doing what any careful implementor would have done, for the sake of
interoperability. My server behavior and client behavior are both fully
compliant with the protocol specifications.

Now, it appears that every other _server_ implementor has made the same
decision to use only the answer section, so no harm would have arisen if
my _client_ had been less careful. But the leap from ``this client can
handle protocol violations that, thankfully, do not occur'' to ``this
client itself violates the protocol'' is utterly absurd.

The BIND company's ``clarification'' does two things:

   * It requires _servers_ to use the careful _server_ strategy. I have
     no objection to this: it's what servers are already doing, it is
     necessary for interoperability with careless clients, and it
     removes a frivolous source of variability in the protocol.

   * It prohibits _clients_ from using the careful _client_ strategy. I
     object to this: it is _not_ consistent with the installed base, and
     it is _not_ necessary for interoperability.

How can anyone confuse a constraint on _servers_ with a constraint on
_clients_? It isn't just Kevin; the same blatant confusion appeared in
the message from the DNSEXT chairs on 13 November.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>