Re: Stds track RFC Internet Draft

[Bill Kelly <[e-mail]>]

Fred,

On Wed, 21 Jul 1993, Fred Bohle wrote:

> > Here are my comments about the draft.  They start with a >.

Thanks!

>
>    IAC SB TN3270E FUNCTIONS IS <function-list> IAC SE
>
>       Either side may send this command.  This command is sent as a
>       response to a FUNCTIONS REQUEST command and implies acceptance
>       of the set of functions sent to it in the REQUEST command.  Note
>       that the list of functions in the FUNCTIONS IS command must
>       match the list that was received in the previous FUNCTIONS
>       REQUEST command.
>
> >
> > Is there a need to separate the negotiations into two parts?  Can't they
> > be combined?  Just delimit the two lists by DEVICE-TYPE and FUNCTIONS and
> > end with IAC SE.
> >

It just seemed more straightforward to do it in two stages.  I thought that
it might make things more complex than they need to be given that some of
the functions are applicable only to one or another device-type.  Things
like the server accepting the function-list while at the same time
rejecting the device-type (or device-name) just seemed odd to me.  Feel
free to post some replacement text, though. :-)

>
>       Valid device-types are those defined in the "Assigned Numbers"
>       RFC [5] in the section entitled "Telnet Terminal Names",
>       restricted to the subset of names that represent IBM 3270
>       terminals, plus the following:
>
>           IBM-3287-1
> >
> >  Let's list them all.  Copy the list from Assigned Numbers.
> >  And shouldn't we only list the ones with the -E suffix, since
> >  we are requiring the support of Query?  We said before that
> >  the -E suffix really meant support of Query.
> >

Okay by me, if it's okay with everyone else.

>
>       This is to ensure that a terminal device that has some
>       significance to host applications (and is therefore likely to be
>       the target of a specific session request) is not "accidentally"
>       assigned to a generic request and winds up associated with a
>       client that has no use for it.  Note that the reverse situation
>       is allowed.  That is, a specific terminal session request could
>       ask for a device-name that happens to be in the "generic
>       terminal pool."  The nature of the host applications would
>       probably mean that such a request has no real use, but it does
>       no harm to allow the connection to be established.
>
> >
> >  Steve D'angona asked me to support Reconnect by sending certain
> >  status codes when we disconnect.  Allowing the user to select a
> >  specific terminal from the generic pool would allow support of
> >  Reconnect.  By the way Steve, if you are listening, what are the
> >  status codes you want us to send?
> >

OK.  So I should just remove the last sentence in that paragraph?

>
>         Response-Flag Name  Code                Meaning
>         ------------------  ----   ---------------------------------
>         POSITIVE-RESPONSE     0    The previous message was received
>                                    and executed successfully with
>                                    no errors.
>
>         NEGATIVE-RESPONSE     1    The previous message was received
>                                    but an error(s) occurred while
>                                    processing it.
>
>       Accompanying device status information will be found in the data
>       portion of the message.
>
> >
> >  The TN3278 doc specifies device status in detail.  Perhaps we should
> >  too.  You could just copy in the text here from that doc.
> >

Do you mean more detail than what's in section 10.4?

> 10. Details of Processing TN3270E Functions
>
>    Agreement by both parties to a specific function in the FUNCTIONS
>    REQUEST function-list implies agreement by each party to support a
>    related set of values in the TN3270E header.  It also implies a
>    willingness to adhere to the rules governing the processing of data
> >
> >  Let's define this better.  Use such words as "violation of the
> >  protocol",  "will be considered non-conforming".
> >

Okay; would this remove the need for one side to be prepared for a "bad"
partner?  Just kill the session or something if the other guy violates the
protocol?

>    10.3 The BIND-IMAGE Function
>
>       This function can only be supported when the TN3270E server
>       represents SNA 3270 devices.
> >
> >  Why?  Wouldn't printer supporters like to see the bind?
> >

*sigh*  That sentence does not (intend) to exclude printers!  But since
you're the second person to have interpreted it that way (I think Azi did
too), I suppose I should clarify it.

>        - Whenever a data message is sent with a DATA-TYPE of either
>          SCS-DATA or 3270-DATA, the sender must set the RESPONSE-FLAG
>          field to either NO-RESPONSE, ERROR-RESPONSE, or
>          ALWAYS-RESPONSE.  It is anticipated that the client side will
>          normally set RESPONSE-FLAG to NO-RESPONSE.  The server, if it
>          represents an SNA device, should set RESPONSE-FLAG to reflect
> >
> >  Are we using the Host Requirements convention of MUST/SHOULD/MAY/MUST NOT?
> >  It seems to me that there are Vtam applications that set DR when it is
> >  not truly needed, and that TN3270 gets a performance boost by not waiting
> >  for a round trip time before it sends Vtam a DR.  I suggest that this
> >  decision be made by the Client, or Server based on local information,
> >  like configuration or local decisions by the person at the Client.  If
> >  we let the Client decide this,  we need to put it into this protocol
> >  somewhere.
> >

It seems to me that we would be better off letting the host application
decide what sort of response is needed, like it's always been done.
Pehaps we could make this stuff configurable at the client, but make one
of its options to allow the host applications to do what they want (i.e.,
the "old fashioned" way).

>    The 3270 SYSREQ key is useful in an SNA environment when the ATTN
>    key is not sufficient to terminate a process.  While there are
>    other uses for the SYSREQ key, and while its function is more
>    complicated than what is dealt with in this document, it seems
>    reasonable to implement a subset of the SYSREQ key support that
>    would be beneficial to a large number of users.  This subset would
>    be limited to support for the sequence of pressing SYSREQ and
>    typing LOGOFF that many users employ to immediately terminate an
> >
> >  On a real 3270, you usually hit Clear, type LOGOFF and press SYSREQ.
> >  On a TN3270E session, I guess you see the SYSREQ followed by LOGOFF.
> >

Really? That's not been my experience.  On the other hand, I haven't
worked from a real 3270 terminal attached to an SNA controller in years -
everything's emulation on a PC.

>
>       Server:  IAC DO TN3270E
>       Client:  IAC WON'T TN3270E
>       Server:  IAC DO TERMINAL-TYPE
>       Client:  IAC WILL TERMINAL-TYPE
>       Server:  IAC SB TERMINAL-TYPE SEND IAC SE
>       Client:  IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
>       Server:  IAC DO EOR
>       Client:  IAC WILL EOR
> >
> >  DO BINARY / WILL BINARY ???
> >  Let's be complete here.
> >
>            .            .
>            .            .
>          (traditional tn3270 negotiation continues)

Okay. (Sheesh, how picky can you get? Not good enough just to say
"traditional tn3270 negotiation continues"...)  :-)

Thanks again for all the input, Fred.

-Bill

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