BIND company employee Mark Andrews writes:
No one is trying to force a incompatabile extension on anyone.
You are demanding a rule whose only purpose is to support incompatible
extensions. _You_ are trying to impose costs on _my_ users so that _you_
don't have to bother preserving backwards compatibility in _your_ stupid
protocol extensions. Furthermore, adding insult to injury, you're trying
to sneak this protocol change through as a ``clarification.''
You didn't answer my question: How would you like it if Microsoft wrote
an RFC on some incompatible protocol extension, hid the interoperability
problems until the RFC was published as an elective Proposed Standard,
and then demanded that every BIND installation be ``upgraded'' to deal
with the junk produced by that protocol extension? How do you think your
users would like it?
If you want to break compatibility with a deployed protocol, you have to
admit the massive costs of changing software around the Internet, and
demonstrate benefits that are even more massive. Saying something like
We'd like to offer people a pointless, clumsy, ad-hoc reinvention of
IPSEC, and we realize that there's no need to break compatibility to
do this, and our implementation in fact follows a rule that ensures
compatibility, but we didn't put this rule into the spec because it's
against company policy to think through compatibility issues, and now
instead of fixing the spec we're demanding that other people upgrade
their software
doesn't cut it.
What's particularly amazing about your ``axfr-clarify'' document is that
you admit that it imposes rules violated by BIND 8. How can you possibly
claim that this is necessary for interoperability?
There is nothing incompatable with saying that servers built
from this time on MUST NOT treat records in the authority
and additional sections as part of the results of AXFR.
1. Please stop viewing the entire world through a BIND lens. Don't say
``server'' if you mean ``AXFR client.''
2. When you use a phrase like ``in future implementations,'' you're
admitting that you're violating RFC 2119, section 6. There is no valid
excuse for a protocol to refer to software creation dates.
3. It's content-free to say that an extra requirement doesn't create a
compatibility problem. What I'm talking about are compatibility problems
created by protocol extensions that don't work correctly with unextended
protocol implementations.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago