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:
> incanting "but it won't interoperate with my implementation!" as if
> it were some sort of religious mantra

Interoperability is incredibly important in the real world. You have no
right to go creating interoperability problems where none exist today.

> No, the purpose of clarifying AXFR is not to spread a "big tent" that
> accommodates the idiosyncratic behavior of every AXFR implementation
> out there.  Such a specification, if it is possible at all, would be
> so watered down it would be useless.

That's absurd. In fact, many future implementors would benefit from an
accurate specification of the existing AXFR protocol. This does _not_
mean screwing up interoperability. It does _not_ mean documenting
irrelevant BIND 9 implementation details as if they were the protocol.

> (as DJB's server apparently does, because he considers AXFR
> client/server transactions to be "local matter[s]" rather than
> something to be governed by protocol, go figure).

When did I ever say that local protocols aren't protocols? What I'm
saying is that unauthorized users like you have no right to demand a
response---or even to try to participate in the protocol in the first
place. The protocol is for authorized users.

> The general rules also say that if a server declines to answer a query
> for some administratively-defined reason, it sends back an approriate
> RCODE

No, the specifications don't say that. Servers can say REFUSED if they
want to, but there's no rule saying that they have to.

> the Authority and Additional sections are reserved for
> specific purposes (e.g. referrals, glue, OPTs, TSIGs etc.)

AXFR responses include glue, remember? A server implementor who doesn't
investigate existing practice could reasonably interpret RFC 1034 as
_requiring_ use of the additional section. That would, in turn, cause
failures with careless clients that don't look at the additional section.

I support requiring the careful server behavior. I object to prohibiting
the careful client behavior.

Analogy that I pointed out last year: RFC 2821 clearly prohibits SMTP
clients from sending non-ASCII header bytes, but clearly allows SMTP
servers to accept those bytes.

---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/>