Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/tn3270e/tn3270e-minutes-93nov.txt

Text File | 1994-02-16 | 6KB | 126 lines

CURRENT_MEETING_REPORT_

Reported by Robert Moskowitz/Chrysler Corporation

Minutes of the TELNET TN3270 Enhancements Working Group (TN3270E)


``TN3270 Current Practices''

There was some discussion of the ``current practices'' Internet-Draft,
and it was agreed that with a few editorial changes it is ready to be
submitted to the IESG with the request that it be published as an
Informational RFC. Bob Moskowitz mentioned the possibility that all
three of the working group's documents might wind up on the standards
track, and become various ``flavors'' of Standards RFCs.  Several
members objected to this approach and only wanted one standards
document.


``TN3270 Extensions for LUname and Printer Selection''

Discussion centered around two areas:  IPDS printer support and handling
of errors during term-type negotiation.  IPDS problems arise due to the
difference in LU1 and LU3 support (function management headers versus
structured fields).  It was agreed that LU3 IPDS support can be attained
by adding a term-type of IBM-4224; this will be a ``queryable'' device
type.  LU1 IPDS support will not be included in TN3287 at this time.

The TN3270 Extensions Internet-Draft will document a list of error codes
(and their meanings) that represent problems that can occur while
negotiating the term-type.  If an error occurs, the server will send the
error number to the client instead of negotiating the EOR and Binary
options; it will then close the connection.  The client will be able to
take whatever action it deems appropriate, which could include such
things as sending a message to the user or attempting to reconnect.

The goal is one more content change on the TN3270 Extension
Internet-Draft followed by a quick editorial cleanup and submission to
our Area Director for review and forwarding to the RFC Editor.


``TN3270E Enhancements''

First up was the subject of sequence numbers; some members questioned
the need for them.  It was agreed that sequence numbers will be needed
when exception response processing occurs.  It was also decided that the
sequence number field in the TN3270E header need only be maintained when
the RESPONSES function has been agreed to; otherwise, this field will
contain binary zeroes.

There was a lively discussion of the initial negotiation of the TN3270E
option (i.e., the WILL/DO and WON'T/DON'T TN3270E negotiation).  It was
pointed out that since TN3270E will be a TELNET option governed by the
TELNET RFC, it must be treated like other TELNET options:  both parties
must be free to send WILL, DO, WON'T and DON'T. Some in the group would
like to have the server be the only party allowed to actually initiate
the TN3270E negotiation---that if a client sends a DO TN3270E, the
server should respond with a DON'T TN3270E, and subsequently send a DO
TN3270E when it is ready.  It was agreed that input from people such as
Steve Alexander, TElNET Working Group Chair, would be helpful in
resolving this issue.



TN3270E Term-type Negotiation

Next came a discussion of the TN3270E term-type negotiation.  Two of the
``gateway-based server'' vendors present expressed serious concerns with
the recently proposed method of simply negotiating TERMINAL or PRINTER
and having the server send out a Read Partition Query.  These objections
had to do with the notion of sending out 3270 data before a session has
actually been established.  It was suggested that the best approach
would be to leave the Document as it reads now (which includes 3278
models 2, 3, 4 and 5, both with and w/o the ``-E'' suffix) and to add a
``DYNAMIC'' term-type, which would allow for the ``non-standard'' screen
sizes.  There was also a suggestion that what is really being negotiated
are screen sizes and whether or not a device is queryable; therefore,
model designations should be done away with and these items should be
negotiated directly.  More discussion on the list will be required to
resolve this issue.

John Klensin, Applications Area co-Director, briefly discussed the
question of WILL/DO and WON'T/DON'T TN3270E. He also stated that the
current practices Internet-Draft will be published as an Informational
RFC, not a Standards one.  John also reported that all of our
Internet-Drafts will be reviewed by TELNET experts before being
submitted to the RFC process to attempt to avoid open discussions during
the Last Call process.  Further, there will be some further thought on
what RFC designation will be used for the TN3270 Extensions
Internet-Draft.



RFC 1538

With time running out, a brief discussion of RFC 1538 (SNA/IP) ensued.
Two of the vendors present are implementing a form of SNA over IP
(although they are not compatible).  It was pointed out that IBM would
prefer to address the issue through the APPN Implementor's Workshop,
rather than in the IETF. Discussion will take place between higher
levels of the IETF and IBM as to where best to work on this.



Attendees

Rich Bowen               [e-mail]
Dan Brendes              [e-mail]
Thomas Butts             [e-mail]
Roger Fajman             [e-mail]
Cleve Graves             [e-mail]
Jeff Hilgeman            [e-mail]
Bill Kelly               [e-mail]
John Klensin             [e-mail]
William Kwan             [e-mail]
David Lapp               [e-mail]
Marjo Mercado            [e-mail]
Robert Moskowitz         [e-mail]
William Palter           [e-mail]
Jon Penner               [e-mail]
Eddie Renoux             [e-mail]
Barbara Sterling         [e-mail]
John Tavs                [e-mail]