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