mark@alias.UUCP (Mark Andrews) (12/02/89)
I am reading over RFC854, the telnet protocol specification and have come
upon a confusing paragraph. This excerpt is from from section 3b of
GENERAL CONSIDERATIONS:
b. If a party receives what appears to be a request to enter some
mode it is already in, the request should not be acknowledged.
This non-response is essential to prevent endless loops in the
negotiation. It is required that a response be sent to requests
for a change of mode -- even if the mode is not changed.
The last sentence seems to contradict the remainder of the paragaph. The 1st
line says "If the requested mode is already present, do not send an
acknowledgement", but the last sentence says "an acknowledgement should be
sent EVEN if the mode is not changed".
Could someone explain this ambiguity??
------------------------------------------------------------------------------
Mark Andrews
Systems Programmer,
Alias Research,
Toronto, Canada
Phone: (416)-362-9181
UUCP: mark%alias@csri.utoronto.ca OR alias!mark@csri.utoronto.cakoreth@panarthea.ebay.sun.com (Steven Grimm) (12/03/89)
In article <662@alias.UUCP> mark@alias.UUCP (Mark Andrews) writes: >The 1st line says "If the requested mode is already present, do not send an >acknowledgement", but the last sentence says "an acknowledgement should be >sent EVEN if the mode is not changed". I take this to mean, "If you're already in the requested mode, don't send an acknowledgement. Otherwise, send an acknowledgement whether you change to the requested mode or not." Anyone know any differently? --- " !" - Marcel Marceau Steven Grimm Moderator, comp.{sources,binaries}.atari.st sgrimm@sun.com ...!sun!sgrimm
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (12/03/89)
From MAILER-DAEMON Sat Dec 2 20:19:01 1989 Received: by WLV.IMSD.CONTEL.COM (5.61/1.25) id AA02126; Sat, 2 Dec 89 20:18:40 -0800 Date: Sat, 2 Dec 89 20:18:40 -0800 From: MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: Host unknown Message-Id: <8912030418.AA02126@WLV.IMSD.CONTEL.COM> To: mcc Status: RO ----- Transcript of session follows ----- 550 tcp-ip@nic.ddn.mil... Host unknown ----- Unsent message follows ----- Received: by WLV.IMSD.CONTEL.COM (5.61/1.25) id AA02124; Sat, 2 Dec 89 20:18:40 -0800 Date: Sat, 2 Dec 89 20:18:40 -0800 From: mcc (Merton Campbell Crockett) Message-Id: <8912030418.AA02124@WLV.IMSD.CONTEL.COM> To: swrinde!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!utzoo!censor!geac!alias!mark@ucsd.edu, tcp-ip@nic.ddn.mil Subject: Re: Question about telnet RFC Seems clear enough to me. You receive a request to enter a state or mode from the remote station. If you are currently in the requested state or mode, do nothing. If you are not in the requested state or mode, you MUST send a re- sponse eiher to accept the new state or mode or to refuse the change. Merton
dab@OPUS.CRAY.COM (Dave Borman) (12/05/89)
> I am reading over RFC854, the telnet protocol specification and have come > upon a confusing paragraph. This excerpt is from from section 3b of > GENERAL CONSIDERATIONS: > > b. If a party receives what appears to be a request to enter some > mode it is already in, the request should not be acknowledged. > This non-response is essential to prevent endless loops in the > negotiation. It is required that a response be sent to requests > for a change of mode -- even if the mode is not changed. > > The last sentence seems to contradict the remainder of the paragaph. The 1st > line says "If the requested mode is already present, do not send an > acknowledgement", but the last sentence says "an acknowledgement should be > sent EVEN if the mode is not changed". > > Could someone explain this ambiguity?? > > Mark Andrews If you receive a request for a state that you are in, you don't reply. If you receive a request for a state that you are not in, you MUST reply, and that reply may either be to aggree or disagree with the requested state. If you are WILL(DO/WONT/DONT) OPT, and you receive DO(WILL/DONT/WONT) OPT, you do nothing, because you are already in the requested state. If you are WONT(DONT) OPT, and you receive DO(WILL) OPT, you MUST respond with either WILL(DO) OPT (to acknowledge that you will go to the requested state) or WONT(DONT) OPT (to refuse to go into the requested state) If you are WILL(DO) OPT, and you receive DONT(WONT) OPT, you MUST respond with WONT(DONT) OPT, and turn off the option. 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). Do I then respond with a DONT OPT, or do I just end the negotiation there? It can be argued both ways. 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. 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. 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. -Dave Borman dab@cray.com
brnstnd@stealth.acf.nyu.edu (Dan Bernstein) (12/07/89)
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