Re: Telnet Option Codes
"James B. Van Bokkelen" <jbvb@ftp.com> Fri, 16 April 1993 21:07 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13970; 16 Apr 93 17:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13966; 16 Apr 93 17:07 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa28735; 16 Apr 93 17:07 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.17) id AA03335; Fri, 16 Apr 93 16:07:14 CDT
Received: by hemlock.cray.com id AA27275; 4.1/CRI-5.6; Fri, 16 Apr 93 16:06:59 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com id AA27270; 4.1/CRI-5.6; Fri, 16 Apr 93 16:06:55 CDT
Received: from ftp.com by cray.com (4.1/CRI-MX 2.17) id AA03302; Fri, 16 Apr 93 16:06:51 CDT
Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA11953; Fri, 16 Apr 93 17:06:45 -0400
Date: Fri, 16 Apr 1993 17:06:45 -0400
Message-Id: <9304162106.AA11953@ftp.com>
To: 0003858921@mcimail.com
Subject: Re: Telnet Option Codes
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "James B. Van Bokkelen" <jbvb@ftp.com>
Reply-To: jbvb-tech@ftp.com
Cc: TN3270E@list.nih.gov, telnet-ietf@cray.com
X-Orig-Sender: jbvb@ftp.com
Repository: babyoil.ftp.com
Originating-Client: plug.ftp.com
The sticking point for a TN3287 negotiation is it is not enough to negotiate a terminal type, but a LU NAME must be assigned to this connection, typically dedicated (a given client always gets a given NAME). This implies a sub-negotiation in the terminal type: IAC SB TERM-TYPE IS IBM3287-2 CONNECT CP123456 IAC SE The question is: is there an existing subnegotion option in the Terminal Type option that can be used where I have specified the word: CONNECT (note: IBM3287-2 would be a 'new' terminal type and in this case CP123456 is the requested LU NAME). Neither RFC 930 (the first definition of Telnet Terminal Type) nor RFC 1091 (as I modified it) allow for anything other than a single NVT ASCII string between the IAC SB TERM-TYPE IS and the IAC SE. Beyond that, I've always assumed that a sequence: "IAC SB type type-specific-data IAC SE" only allowed for one 'type'. This seems to be supported by page 2 of RFC 855. The code we have in the field assumes that, as well. I would suggest that if you plan to re-define Telnet Terminal Type so that 1) the server can issue an IS (as opposed to only SEND), and 2) the client should interpret the argument, you need to update RFC 1091. Given that it is fairly widely used, I strongly suggest that you ensure that what you do is backwards-compatible (a goal I managed to achieve with RFC 1091 vs. RFC 930). At any rate, having the server send the terminal type seems superfluous, given that the client is supposed to keep track of what it sent and assume that that is in effect. If instead you want to define a new sub-negotiation, it should be separate from Terminal Type. I think it might be easier to define a new sequence sent by the server, after 3270-REGIME is agreed to: IAC SB LU-NAME IS ..... IAC SE Making agreement on 3270-REGIME a prerequisite would prevent causing problems with marginal IAC SB parsers in older clients. James B. VanBokkelen 2 High St., North Andover, MA 01845 FTP Software Inc. voice: (508) 685-4000 fax: (508) 794-4488
- Re: Telnet Option Codes Robert G. Moskowitz
- Re: Telnet Option Codes James B. Van Bokkelen
- Re: Telnet Option Codes minshall