Re: RFC 2119 section 6

[Brian Wellington <[e-mail]>]

On Thu, 12 Jul 2001, D. J. Bernstein wrote:

> Brian Wellington writes:
> > The point is that there are extensions already that are reasonable
> > given the spirit of the original AXFR specification.
>
> Nothing in the original specification requires that AXFR clients stop
> reading packets at the end of the answer section. If you dispute this,
> please quote the text that you believe imposes such a requirement.

Dan, you're missing the point.  The whole point of the axfr-clarify draft
is that the original specification is unclear.  Obviously there is no such
stated requirement, or we wouldn't be having this painfully long argument.

> > No one but you thinks it's necassary that all of these sites deploy the
> > new code.
>
> I have repeatedly asked why I should make this change to the code. What
> exactly is the benefit?
>
> The answer from your coworker Mark Andrews is that he might someday do
> something that _fails_---causes ``damage,'' he says---if it encounters
> the unchanged code. He says he wants to avoid ``breaking things.''

That seems like a perfectly reasonable point.

> But changing the code isn't enough to prevent these failures. The
> changed code would have to be _deployed_. That's the cost I'm talking
> about. Deployment takes time and effort.

Not true.  If you changed the code now, deployment would naturally occur
by the time incompatible features were used.

> Is the BIND company backing away from demanding that my users suffer
> this cost? If so, I ask again: What exactly is the benefit of my making
> this change to the code?

Compatibility with future extensions and the future standard.  And the
fact that it would take less time than continuing to argue.  And it
doesn't hurt anything.

> > For the record, your comments about BIND 9's handling of unknown types
> > in http://cr.yp.to/djbdns/newtypes.html are wrong.
>
> The page was accurate when I wrote it. Are you saying that BIND was
> subsequently fixed? Which versions?

9.1.0.

Brian



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.