Re: careless protocol extensions

[Mark.Andrews@isc.org]

> [ post by non-subscriber.  with the massive amount of spam, it is easy to mis
> s
>   and therefore delete posts by non-subscribers.  your subscription address i
> s
>   54830374684695-namedroppers@sublist.cr.yp.to, please post from it or, if yo
> u
>   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. ]
> 
> All of this was discussed in detail a long time ago. In any legitimate
> standards organization, the results of that discussion would have been
> recorded for future reference.
> 
> Andreas Gustafsson writes:
> > Although it is not necessary for interoperability of the base
> > protocol, it is necessary in order to support protocol extensions that
> > send out-of-band data in sections other than the answer section, such
> > as TSIG signed transfers.
> 
> No, it is not necessary. Backwards compatibility is not rocket science.
> Servers must not---and, according to you, BIND does not---send TSIG junk
> to clients that haven't indicated that they want it. (I have no desire
> to support TSIG; IPSEC is a vastly better solution.)
> 
> If the TSIG specification fails to impose this basic interoperability
> requirement, then that's a bug in the TSIG specification. It is the
> responsibility of optional protocol extensions to maintain perfect
> compatibility with the unextended protocol. The alternative---forcing
> the entire Internet to change its software for every careless protocol
> extension that comes along---is insane.
> 
> 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?
> 
> ---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/>

	No one is trying to force a incompatabile extension on anyone.

	How is saying that the client should enforce what the server
	should be enforcing going to create incompatabilities?

	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.

	We already have servers that enforce this. They have existed
	since basically the begining.  Having servers behave
	differently in the presence of changes to the spec is *bad*.
	Specifing what their behaviour is in advance means that the
	effect of changes can be predicted.

	Now if anyone is going to add extentions they are also going
	to need to add knobs to disable the extention.  It would
	just be nice if those knobs rarely need to be changed.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

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