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
- SSCP-LU session and SCS data Bill Kelly