Re: RFCS: More comments

Peter DiCamillo <CMSMAINT%BROWNVM.bitnet@list.nih.gov> Wed, 21 July 1993 23:33 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13493; 21 Jul 93 19:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13489; 21 Jul 93 19:33 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa29068; 21 Jul 93 19:33 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 6676; Wed, 21 Jul 93 19:33:12 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 6672; Wed, 21 Jul 93 19:33:04 EDT
Date: Wed, 21 Jul 1993 18:15:55 -0400
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter DiCamillo <CMSMAINT%BROWNVM.bitnet@list.nih.gov>
Subject: Re: RFCS: More comments
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
In-Reply-To: Message of Wed, 21 Jul 1993 08:54:56 -0500 from <kellywh@MAIL.AUBURN.EDU>
Message-ID: <9307211933.aa29068@CNRI.Reston.VA.US>

On Wed, 21 Jul 1993 08:54:56 -0500 Bill Kelly said:
>Thanks for the input.  First, to nit-pick, I just want to clarify that
>we're talking about RFCS here
Sorry, I didn't mean to add to the confusion.

>I wasn't sure how this could be useful, either, but it was in the
>presentation that Bob did (and that I think Scott Herzog and Jon Penner of
>DCA pretty much wrote) at the March IETF.  I don't remember it being
>discussed, but I could've missed it if it was.  Azi's comments on this
>subject make me think it would be worth including NVT-DATA even if only a
>few vendors make use of it.  Perhaps Jon (or some of the other vendors)
>could elaborate on its usefulness, or if there was any discussion of it at
>IETF someone could summarize it to the list?
After reading Azi's, your and Fred's response, I can see why this is
worth having.  However, I think if we're going to have it, its use
must be clarified.  I'll propose the following text to be inserted
under section 9, "Basic TN3270E":

   At any given time, a client can be considered to be operating
   in either 3270 or NVT mode.  The client is initially in 3270
   mode when TN3270E operation is successfully negotiated.  When a
   client receives a message with a DATA-TYPE different than the
   mode it is operating in, the client switches its mode of operation.
   Switching modes results in the client performing the equivalent of
   a 3270 Erase/Reset operation, as described in [6], using the default
   partition size.  The server cannot assume the client preserves
   any attributes of the previous environment across a mode switch.

   Typically, NVT data is used by a server to interact with the user
   of a client.  It allows the server to do this using a simple NVT
   data stream, instead of requiring a 3270 data stream.  An example
   would be a server which displays a list of 3270 applications to which
   it can connect the client.  The server would use NVT data to display
   the list and read the user's choice.  Then the server would connect to
   the application, and begin the exchange of 3270 data between the
   application and the client.

Here's an interesting question this brings up.  A telnet client
usually sends individual characters to the server immediately when the
user enters them.  In NVT-DATA mode, does the client send each new
character preceded by the 4-byte header?  For efficiency, we may want
to define it so that in NVT-DATA mode, characters are buffered until the
user presses "return" or "enter".

Peter