Re: careless protocol extensions

["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 posts by non-subscribers.  your subscription address is
  54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if you
  wish to regularly post from an address that is not subscribed to this
  mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to
  have the alternate address added to the list of addresses from which
  submissions are automatically accepted. ]

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



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