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 rkb@ralvm11.vnet.ibm.com Dan Brendes brendes@raleng.mtc.com Thomas Butts tom@oc.com Roger Fajman raf@cu.nih.gov Cleve Graves cvg@oc.com Jeff Hilgeman jeffh@apertus.com Bill Kelly kellywh@mail.auburn.edu John Klensin Klensin@infoods.unu.edu William Kwan kwan@rabbit.com David Lapp lapp@waterloo.hp.com Marjo Mercado marjo@cup.hp.com Robert Moskowitz 3858921@mcimail.com William Palter palter@tgv.com Jon Penner jjp@bscs.uucp Eddie Renoux elr0262@newsit2.mcdata.com Barbara Sterling bjs@mcdata.com John Tavs tavs@vnet.ibm.com