Re: Telnet Query

Michael StJohns <> Sat, 15 May 1993 16:54 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa02508; 15 May 93 12:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02504; 15 May 93 12:54 EDT
Received: from by CNRI.Reston.VA.US id aa11272; 15 May 93 12:54 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 1950; Sat, 15 May 93 12:56:20 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 1945; Sat, 15 May 93 12:56:14 EDT
Date: Sat, 15 May 1993 12:54:15 -0500
Reply-To: IETF TN3270E Working Group List <>
X-Orig-Sender: IETF TN3270E Working Group List <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Michael StJohns <>
Subject: Re: Telnet Query
X-To: Christian Huitema <>, "David A. Borman" <>
X-cc: iab@ISI.EDU,,
To: Multiple recipients of list TN3270E <>
Message-ID: <9305151254.aa11272@CNRI.Reston.VA.US>

Christian - without commenting on whether or not the idea of "packets"
makes sense within a telnet stream (I've read Dave's note a couple of times
and I'm not sure which way to jump) it makes sense to make this part of the
telnet protocol rather than a separate protocol.  Why?  -> The notion of
fall back.  If you can't negotiate TN3270 mode, you still get dumb  (or
perhaps dumber) terminal service.  Whereas if you have a TN3270 only
protocol you're out of luck if one end or the other doesn't do the
protocol.  Telnet has a fairly powerful optioning mechanism -- I wish more
of our protocols had ways of negotiating options this cleanly.


At 09:04 5/14/93 +0200, Christian Huitema wrote:
> the "3270 extensions" that you describe look pretty much
>like redesigning the protocol. For my own enlightment, could you please
>explain why you dont consider just splitting "3270" and "telnet", and design
>an ad hoc "tn3270" protocol?
Michael StJohns, Major USAF, Program Mgr, ARPA/CSTO (703) 696-2271