Re: RFC Comments

[Bill Kelly <[e-mail]>]

I'm glad to see discussion returning to our discussion list!

On Wed, 21 Jul 1993, azi wrote:

> 1) What about the SCS encoded (and not 3270 formatted) SSCP-LU session
>   support ? Everything is ready - why dont use it ? (also solves the
>   SYS_REQ issue)

I'm still struggling with this.  I'm not yet ready to call the Unformatted
Systems Services data on the SSCP-LU session the same thing as SCS data.
In the 3174 Reference Summary (GX27-3872), for example, it documents the
SCS Control Codes (forms feed, horizontal tab, etc) and explicitly states
that "SCS control codes are honored by the CUT printers when operating as
LU type 1 when attached to the 3174".  Are you saying that 3270 terminal
devices would accept these codes as well?  Further, that I could include
some of those codes in, say, USS message 10 and a terminal would interpret
them correctly?  (I haven't tested that, but I might.)  I would be
surprised to find that to be true, but as they say - you learn something
new every day.

Even assuming that it is true that the character-coded unformatted data on
the SSCP-LU session is the same as SCS data (in every aspect), I'm still
not clear exactly how you intend to use that in support of the SYSREQ key.
Could you elaborate?  Would the user just press the "SYSREQ" key, then
type something (like "LOGOFF") which the client would send to the server
with the SCS-DATA flag on?

>
> 2) A small challenge to the all : Why wasn't the SNA RH format chosen
>    as the TN3270E-header ? This will allow us to use all SNA functions
>    (including chaining).  Currently we just have to define which functions
>    are supported, but for future use - we have all the SNA information, and
>    it is even shorter !

For servers representing SNA devices, this approach might work (I'm not
sure about the legality of it, though.  Lifting stuff directly from a
proprietary protocol?).  What about the DATA-TYPE flag values of NVT-DATA
and BIND-IMAGE, which are obviously not in an SNA RH?  I suppose 1 byte could
be added to the RH.  It does seem that if we were to add much more to
TN3270E (such as chaining and brackets), we'd wind up with most of the SNA
RH in the TN3270E header.

I tend to think that we'd find a lot of resistance in the IETF if we tried
to take SNA RHs, put them in TN3270E, and actually say that's what we did.
I think people would view that as "SNA-izing" TCP/IP, and that is viewed
as a Bad Thing.  We're better off taking what functions are needed and
putting them in a TN3270E header.  The distinction may seem silly, but we
do have to have the approval of the IETF as a whole.

Also, as Peter has pointed out in the past, "3270" does not automatically
imply "SNA".  One might ask why should we impose a header with all of the
things in SNA RHs on non-SNA TN3270E servers which couldn't support most
of the functions represented by bits in the RH?  (I realize that we're
doing almost the same thing if we put most of the RH values in the TN3270E
header, but again, I think there's a lot of resistance out there to
"SNA-izing" TCP/IP [or non-SNA 3270, for that matter].)

-Bill

Bill Kelly               phone: [phone]
Auburn University     Internet: [e-mail]