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

On Wed, 2002-04-24 at 10:10, Jim Mathewson II wrote:
> 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?

The following options exist:

    -- do nothing. Not palatable, but always the default action wrt to
these matters.

    -- keep the WG alive and push the new draft through by updating the
charter. I believe you'll have to find another chair; I'm past my use-by
date :-).

     -- submit the draft as an individual submission. This is perfectly
acceptable for Informational RFCs, and I hear tell that the occasional
Standards Track submission gets through this way. I certainly know that
this is the way of least resistance from a IESG point-of-view. The IESG
is more concerned with relevance and quality of the document (as seen by
amount/quality of review & discussion on the working-groups' aliases).
They are also more concerned with consensus than with whether the
document originated inside/outside a particular WG; WG's are "just"
mechanisms to regulate the madness.

cheers,
/msb

>
> 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
>