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
- Re: RFCS: More comments Peter DiCamillo
- Re: RFCS: More comments Robert G. Moskowitz
- Re: ASCII tn3270 datastream A. Harry Williams