NVT data on TN3270 session

azi <rndi!azi@uunet.uu.net> Wed, 21 July 1993 05:08 UTC

Date: Wed, 21 Jul 1993 07:33:55 +0200
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: azi <rndi!azi@uunet.uu.net>
Subject: NVT data on TN3270 session
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9307210108.aa06521@CNRI.Reston.VA.US>

Peter wrote:

>2. I'm puzzled by the inclusion of NVT-DATA as one of the data types,
>   and RFC provides no explanation for its presence, or how it is
>   intended to be used.  I'm not necessarily saying it should be
>   removed, but could someone explain the motivation behind it?
>   Traditionally, NVT data is sent either before 3270 mode has been
>   negotiated, or later only after negotiating an end to 3270 mode.
>   Nothing in the RFC would seem to preclude continuing to do that.
>   Also, nothing in the RFC seems to preclude sending a block of
>   NVT data at any arbitrary time in the middle of a 3270 session.
>   What is a client expected to do if that happens?  If it's not
>  intended to be used that way, that needs to be clarified.

I think this is a usable option. It can be used for any internal
server-client communication. Currently, if the server has something
to say to the client (e.g. internal security) it should send it in a 3270
data stream. Allowing NVT data to be sent will allow it to be done
in normal ASCII data stream, the native data stream for may servers.

Elazar (Azi) Ronen
Software development manager,RADLINX Ltd.
7 Arad st.
Tel Aviv 69710
Israel

Tel: 972-3-6475188
Fax: 972-3-6475057
Email: rndi!azi@uunet.uu.net or uunet.uu.net!rndi!azi

NVT data on TN3270 session azi