RE: Last call for tn3270e extensions draft: draft-ietf-tn3270e-extensions-04.txt

The following comments were previously sent after reviewing
draft-ietf-tn3270e-extensions-01.txt. I did see one favorable posting
one my comments, but saw no other comments, nor did I see any mention of
the problem I address in subsequent revisions of the draft. The problem
addressed is pertains to a telnet server that converts between SNA
protocols and telnet protocols. I include them once more in hopes of
generating some thought on the issue before this draft becomes an RFC.
Our company has implemented an ad-hoc solution in our client and server
products, but we would like to see this problem addressed in a standard
way. Here goes ...



I have read the IETF draft on proposed extensions to the TN3270E
protocol (RFC 2355), and think that the extensions proposed in
<draft-ietf-tn3270e-extensions-04.txt> are quite useful. This note is
written in regard to one more functional enhancement I would like to see
added to that draft.

The issue concerns the use of EndBracket indicator for TN3270E printers
when using a TN3270E server that is an SNA gateway. There is currently
no way in RFC2355 for TNE printer clients to properly acknowledge print
jobs in certain cases. Consider the following case:

The host printer application sends the print job in a bracket (started
with an SNA RU that has BB set, and ending in an RU that
has EB set). Further, assume that all of the data is contained in RU's,
while the EB indicator arrives in a null RU (i.e. a request unit
containing only an RH with no data), and with Definite Response
Indicator. This would normally cause the server to send to the client a
sequence of TNE data records with the RESPONSE flag set to
ERROR-RESPONSE, followed by an EOJ record. According to RFC 2355, the
header in an EOJ record is not allowed to set the RESPONSE FLAG to a
value other than NO-RESPONSE.  The host application is expecting a
response to the NULL RU which will inform it whether or not the job has
been successfully printed. The TNE printer client may have to queue all
of the print data received, positively responding to data records
containing a response flag of ALWAYS-RESPONSE, and, upon receipt of the
EOJ command, dequeue the data and submit it to the printer. This is
typically the approach taken for LPD style printer devices. However, if
the TNE client has problems submitting the print job, it may want to
send a negative response indication to the host application, or delay
sending a positive response until the printing can complete, and thus
holding the printer application from starting another print JOB on the
same LU. In RFC2355, there is no way to accomplish this. Meanwhile, the
server must respond positively to the NULL RU without ever getting a
response from the client.

I would like to propose a solution. One approach would be to allow the
EOJ command to use the response field. This would cover the case
described above, but is still not ideal in the case where the EB
indication is received in an RU that also contains the last part of data
for the print job. A second approach would be to add the EB indicator in
the header of the TNE data record. This would allow the printer client
to know that he has received that last part of the data job, as well as
EOJ indication, as well as providing the semantics to send an end-to-end
acknowledgement of the EOJ indication. This approach would also allow
the server to send a data record with no data BUT with the EB indicator
set to implement the receipt of EB, Definite Response in a null RU
received by the server.

Of course, these new functions would need to be agreed upon by client
and server during option negotiation.

In summary, I believe the draft solves many of the issues involved with
handling bid contention problems and problems involving keyboard restore
processing, which will help the implementers of this protocol handle
these scenarios for display devices. The above mention function
involving EB indication, along with the proposed extensions involving
FMH data handling, would go a long way in improving TNE printer
implementations.


regards,

Harold Stevenson
Director, SNA Products
Alebra Technologies, Inc.
tel. no.   (508) 293-0356
fax   (508) 435-3714
email:    [email protected]
web:   http://www.alebra.com