Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!brutus.cs.uiuc.edu!zaphod.mps.ohio-state.edu!sunybcs!sbcs!stealth!brnstnd
From: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Question about telnet RFC
Message-ID: <4172@sbcs.sunysb.edu>
Date: 6 Dec 89 18:09:21 GMT
References: <8912041645.AA26970@opus.cray.com>
Sender: news@sbcs.sunysb.edu
Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Distribution: usa
Organization: IR
Lines: 77

In article <8912041645.AA26970@opus.cray.com> dab@OPUS.CRAY.COM (Dave Borman) writes:
> The unclear point about option negotiation is when one sends a
> request to enable and option, and a refusal comes back (i.e., if
> I send DO OPT and get back a WONT OPT).

The only unclear point about option negotiation is what you do when the
user requests that an option be turned on, but then changes his mind
before you get a reply back. As I discovered several months ago, you can
handle this case in apparent conformance with RFC 854 and still allow
option negotiation loops.

The worst part is that it actually happens in practice. Tell your
implementation to show option negotiations; then connect to something
and tell your implementation to switch back and forth rapidly between
states. (For example, under BSD telnet: toggle option, mode character,
mode line, mode character ...) Stop after two or three switches, and
watch the loop.

Fortunately, Dave and the rest of the BSD telnet crew woke up when I
pointed this out; so, without giving me any credit, they've put some
loop prevention code into the 4.4 version. Hooray for academic honesty.

Back to the easy issue of DO-WONT:

> Do I then respond with
> a DONT OPT, or do I just end the negotiation there?  It can be
> argued both ways.

It can be argued both ways; but those who write books, and those who
understand why protocols fail, are in complete agreement that you end
the negotiation there. There is absolutely no reason to send an extra
negotiation.

> If my state changed when I sent DO OPT, then
> it seems reasonable that I should send a DONT OPT if I receive
> a WONT OPT, to confirm that I have disabled the option.

If your state changed when you sent DO OPT, then you are in violation
of the requirement that an option negotiation not take effect until the
appropriate point in the data stream. Dave's going to respond to this by
saying that your state can change without affecting the data stream; but
then it's not a real state change.

To put it differently, RFC 854 effectively *defines* your ``state'' as
what you're doing to the data stream, and you're not allowed to apply
OPT to the data stream unless/until the other side agrees; so you're in
violation of the RFC if your state changed when you sent DO OPT.

> But if
> I don't change my state until I get the WILL OPT, then I it seems
> reasonable that I do NOT send the DONT OPT, since that is what
> state we are already in.

This is very, very sensible.

To put it still differently: RFC 854 talks about negotiations for the
state you're already in as noncompliant negotiations, to be ignored.
If you send back a DONT after DO-WONT, you're acting the same way as any
other noncompliant implementation.

To put it still differently: RFC 854 explicitly commands, Thou shalt not
send a negotiation for the state you're already in. After DO-WONT you're
in the negative state as before, so sending a DONT is a violation.

To put it in practical terms: The more you send through the network, the
less the network will *work*.

> As it turns out, from the view of the protocol, when you are doing
> proper option negotiation, both cases will work just fine, and
> neither side of the connection should have any dependencies on
> it happening one way or the other.

Yeah, and injecting spurious packets into the Internet doesn't make your
host non-conformant, and it won't make anything fail, but it's still
stupid.

---Dan