SSCP-LU session and SCS data

Bill Kelly <kellywh@mail.auburn.edu> Wed, 21 July 1993 18:29 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08736; 21 Jul 93 14:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08732; 21 Jul 93 14:29 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa19530; 21 Jul 93 14:29 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 6105; Wed, 21 Jul 93 14:28:37 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 6099; Wed, 21 Jul 93 14:28:31 EDT
Date: Wed, 21 Jul 1993 13:09:38 -0500
Reply-To: Bill Kelly <kellywh@mail.auburn.edu>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Kelly <kellywh@mail.auburn.edu>
Subject: SSCP-LU session and SCS data
X-To: TN3270E list <tn3270e@list.nih.gov>
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9307211429.aa19530@CNRI.Reston.VA.US>

Hi Azi,

I was not trying to imply that data on the SSCP-LU session could contain
3270 orders, commands, etc.; they are certainly not allowed.  I was
questioning whether what I understood to be SCS datastream (including the
SCS control codes) is allowed.

Doug Rein of Apertus has kindly pointed me to a clear explanation of the
SSCP-LU session in the 3174 Functional Description manual (GA23-0218).  It
appears that I was confusing SCS control codes with the SCS datastream.
The SSCP-LU session uses the SCS datastream (SSCP-supported graphic codes)
but only a very small subset of the SCS control codes, namely NL (unless
APL feature is installed, in which case the Graphic Escape character is
also supported).

So it sounds to me like we have two "flavors" of SCS support:

- one used by LU type 1 printers and which includes support for the full
  range of SCS control codes

- one used on the SSCP-LU session and which (for our purposes) only
  supports the NL SCS control code

If you want to use the SCS-DATA flag in the TN3270E header for the SSCP-LU
session, then that might have implications for the negotiation of the
SNA-CHAR-STREAM function.  In other words, if you require that all clients
support SCS-DATA as a DATA-TYPE so as to accomplish the SYSREQ-LOGOFF
sequence, then I think we need to distinguish that from SCS printer datastream
support (so that a terminal client isn't required to support all SCS
control codes).

Perhaps the thing to do is require that all clients support the SCS-DATA
flag in the header, and change the SNA-CHAR-STREAM function to an
SCS-CTL-CODES function.  Let only printer sessions negotiate the
SCS-CTL-CODES function.  Only on a printer session for which SCS-CTL-CODES
has been agreed to could the full range of SCS control codes be sent.

I'm still waiting to see exactly how you want to use SCS-DATA to implement
the SYSREQ-LOGOFF sequence.  The only thing I can think of is the
following:

  - as the draft currently states, the user presses SYSREQ, whereupon the
    client sends Telnet AO, and the server enters "suspended mode" for the
    session

  - your modification would add that if the user types any characters and
    presses Enter, the client should send that to the server with a header
    in which the DATA-TYPE flag is set to SCS-DATA

Other than that, the method in the draft would remain the same.  Is this
what you have in mind?  It seems reasonable to me.  In fact, I'll be the
first to admit that the draft is vague about the transmission of LOGOFF -
it says nothing about the header flags, NVT-DATA -vs- 3270-DATA or anything.

Thanks,

Bill Kelly               phone: (205) 844-4512
Auburn University     Internet: kellywh@mail.auburn.edu