RE: Last call for tn3270e extensions draft: draft-ietf-tn3270e-extensions-04.txt
"Jim Mathewson II" <[email protected]> Wed, 24 Apr 2002 13:10:34 -0400
| Newsgroups | gmane.ietf.tn3270e,gmane.spam.detected |
|---|---|
| Message-ID | <[email protected]> |
--0__=0ABBE136DFCE43BF8f9e8a93df938690918c0ABBE136DFCE43BF
Content-type: multipart/alternative;
Boundary="1__=0ABBE136DFCE43BF8f9e8a93df938690918c0ABBE136DFCE43BF"
--1__=0ABBE136DFCE43BF8f9e8a93df938690918c0ABBE136DFCE43BF
Content-type: text/plain; charset=US-ASCII
I too have a problem with another portion of the TN3270 that needs work to
be done concerning NON-SNA Local Channel Chaining. And I have recently
posted to this forum to get comments of which I have received a few.
I however am VERY concerned and want VERY much to get these pages like they
are CLOSED/APPROVED and am willing to forgo any attempt at making any
modifications to this draft, save the removal which I believe we can or
have all agreed.
Michael Boe will this draft be the last hurrah of this group or will
additional enhancements such as the one Harold is concerned with and the
one I am concerned with have a chance to be resolved in the near future?
James M. Mathewson II
Senior Software Engineer IBM
Email: [email protected]
Phone: 919-254-0122
"Harold Stevenson"
<harold. To: <[email protected]>
stevenson@alebra. cc:
com> Subject: RE: Last call for tn3270e extensions draft: draft-ietf-tn3270e-extensions-04.txt
Sent by: owner-
[email protected].
GOV
04/23/2002 05:18
PM
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
--1__=0ABBE136DFCE43BF8f9e8a93df938690918c0ABBE136DFCE43BF
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
<html><body>I too have a problem with another portion of the TN3270 that needs work to be done concerning NON-SNA Local Channel Chaining. And I have recently posted to this forum to get comments of which I have received a few.<br>
<br>
I however am VERY concerned and want VERY much to get these pages like they are CLOSED/APPROVED and am willing to forgo any attempt at making any modifications to this draft, save the removal which I believe we can or have all agreed. <br>
<br>
Michael Boe will this draft be the last hurrah of this group or will additional enhancements such as the one Harold is concerned with and the one I am concerned with have a chance to be resolved in the near future?<br>
<br>
James M. Mathewson II<br>
Senior Software Engineer IBM<br>
Email: [email protected]<br>
Phone: 919-254-0122<br>
<br>
<img src="cid:[email protected]" width="16" height="16" alt="">"Harold Stevenson" <[email protected]><br>
<br>
<br>
<table V5DOTBL=true width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img src="cid:[email protected]" border="0" height="1" width="72" alt=""><br>
</td><td style="background-image:url(cid:[email protected]); background-repeat: no-repeat; " width="1%"><img src="cid:[email protected]" border="0" height="1" width="225" alt=""><br>
<ul>
<ul>
<ul>
<ul><b><font size="2">"Harold Stevenson" <[email protected]></font></b><br>
<font size="2">Sent by: [email protected]</font>
<p><font size="2">04/23/2002 05:18 PM</font></ul>
</ul>
</ul>
</ul>
</td><td width="100%"><img src="cid:[email protected]" border="0" height="1" width="1" alt=""><br>
<font size="1" face="Arial"> </font><br>
<font size="2"> To: </font><font size="2"><[email protected]></font><br>
<font size="2"> cc: </font><br>
<font size="2"> Subject: </font><font size="2">RE: Last call for tn3270e extensions draft: draft-ietf-tn3270e-extensions-04.txt</font><br>
<br>
<font size="1" face="Arial"> </font></td></tr>
</table>
<br>
<font face="Courier New">The following comments were previously sent after reviewing<br>
draft-ietf-tn3270e-extensions-01.txt. I did see one favorable posting<br>
one my comments, but saw no other comments, nor did I see any mention of<br>
the problem I address in subsequent revisions of the draft. The problem<br>
addressed is pertains to a telnet server that converts between SNA<br>
protocols and telnet protocols. I include them once more in hopes of<br>
generating some thought on the issue before this draft becomes an RFC.<br>
Our company has implemented an ad-hoc solution in our client and server<br>
products, but we would like to see this problem addressed in a standard<br>
way. Here goes ...<br>
<br>
<br>
<br>
I have read the IETF draft on proposed extensions to the TN3270E<br>
protocol (RFC 2355), and think that the extensions proposed in<br>
<draft-ietf-tn3270e-extensions-04.txt> are quite useful. This note is<br>
written in regard to one more functional enhancement I would like to see<br>
added to that draft.<br>
<br>
The issue concerns the use of EndBracket indicator for TN3270E printers<br>
when using a TN3270E server that is an SNA gateway. There is currently<br>
no way in RFC2355 for TNE printer clients to properly acknowledge print<br>
jobs in certain cases. Consider the following case:<br>
<br>
The host printer application sends the print job in a bracket (started<br>
with an SNA RU that has BB set, and ending in an RU that<br>
has EB set). Further, assume that all of the data is contained in RU's,<br>
while the EB indicator arrives in a null RU (i.e. a request unit<br>
containing only an RH with no data), and with Definite Response<br>
Indicator. This would normally cause the server to send to the client a<br>
sequence of TNE data records with the RESPONSE flag set to<br>
ERROR-RESPONSE, followed by an EOJ record. According to RFC 2355, the<br>
header in an EOJ record is not allowed to set the RESPONSE FLAG to a<br>
value other than NO-RESPONSE. The host application is expecting a<br>
response to the NULL RU which will inform it whether or not the job has<br>
been successfully printed. The TNE printer client may have to queue all<br>
of the print data received, positively responding to data records<br>
containing a response flag of ALWAYS-RESPONSE, and, upon receipt of the<br>
EOJ command, dequeue the data and submit it to the printer. This is<br>
typically the approach taken for LPD style printer devices. However, if<br>
the TNE client has problems submitting the print job, it may want to<br>
send a negative response indication to the host application, or delay<br>
sending a positive response until the printing can complete, and thus<br>
holding the printer application from starting another print JOB on the<br>
same LU. In RFC2355, there is no way to accomplish this. Meanwhile, the<br>
server must respond positively to the NULL RU without ever getting a<br>
response from the client.<br>
<br>
I would like to propose a solution. One approach would be to allow the<br>
EOJ command to use the response field. This would cover the case<br>
described above, but is still not ideal in the case where the EB<br>
indication is received in an RU that also contains the last part of data<br>
for the print job. A second approach would be to add the EB indicator in<br>
the header of the TNE data record. This would allow the printer client<br>
to know that he has received that last part of the data job, as well as<br>
EOJ indication, as well as providing the semantics to send an end-to-end<br>
acknowledgement of the EOJ indication. This approach would also allow<br>
the server to send a data record with no data BUT with the EB indicator<br>
set to implement the receipt of EB, Definite Response in a null RU<br>
received by the server.<br>
<br>
Of course, these new functions would need to be agreed upon by client<br>
and server during option negotiation.<br>
<br>
In summary, I believe the draft solves many of the issues involved with<br>
handling bid contention problems and problems involving keyboard restore<br>
processing, which will help the implementers of this protocol handle<br>
these scenarios for display devices. The above mention function<br>
involving EB indication, along with the proposed extensions involving</font><br>
<font face="Courier New">FMH data handling, would go a long way in improving TNE printer<br>
implementations.<br>
<br>
<br>
regards,<br>
<br>
Harold Stevenson<br>
Director, SNA Products<br>
Alebra Technologies, Inc.<br>
tel. no. (508) 293-0356<br>
fax (508) 435-3714<br>
email: [email protected]<br>
web: </font><font face="Courier New"><a href="http://www.alebra.com">http://www.alebra.com</a></font><font face="Courier New"><br>
</font><br>
</body></html>
--1__=0ABBE136DFCE43BF8f9e8a93df938690918c0ABBE136DFCE43BF--
--0__=0ABBE136DFCE43BF8f9e8a93df938690918c0ABBE136DFCE43BF
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <[email protected]>
Content-transfer-encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--0__=0ABBE136DFCE43BF8f9e8a93df938690918c0ABBE136DFCE43BF
Content-type: image/gif;
name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <[email protected]>
Content-transfer-encoding: base64
R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
--0__=0ABBE136DFCE43BF8f9e8a93df938690918c0ABBE136DFCE43BF--