Subject: TN5250E device startup response

From: Aladin Dajani <[email-masked]>
Date: Fri, 5 Jun 1998 12:20:47 -0400

I noticed that RFC 1205 (or is it 1572 ?  I am new to this forum and these numbers confuse me a little)
establishes different mechanisms for handling Device Name Collisions in Display sessions and Printer
sessions.  Whereas for Display sessions, the collision will be implicitly indicated by re-requesting the
device name variable during negotiations, printer sessions will receive an explicit response header.

I believe that a response record should be returned for display sessions as well.  The Response Code
portion of the Response Record should be very useful in determining the reason for device creation failure.
Recall that some AS/400 administrators turn off device auto-creation, the response record will then allow
distinction between failures due to device name collisions vs. non-existent devices.

Aladin Dajani
Hummingbird Communications Ltd.
[email-masked]

---

From: [email-masked]
Date: Wed, 10 Jun 1998 14:18:27 -0700

I agree; I would like Telnet display sessions to receive a start-up
     confirmation record.  I also want to mention a compatibility warning.

     Another good reason for a display confirmation record is to provide
     the auto-created device name to a display session.  The device name is
     really very useful to PC users.  This change would make Telnet
     displays behave more like APPC-connected display sessions.

     The warning about compatibility is that some Telnet clients will have
     problems if they suddenly begin receiving a start-up confirmation
     record tomorrow.  Since they've never gotten one in the past, many
     clients don't know what to do with it.  The start-up confirmation
     shouldn't be sent to a client unless they somehow indicate they're
     capable of processing it.

     Thanks for listening,
     Barry Hansen
     [email-masked]
     WRQ, Inc.

______________________________ Forward Header __________________________________
Subject: TN5250E device startup response
Author:  aladin ([email-masked]) at internet
Date:    6/5/98 9:20 AM

I noticed that RFC 1205 (or is it 1572 ?  I am new to this forum and these
numbers confuse me a little) establishes different mechanisms for handling
Device Name Collisions in Display sessions and Printer sessions.  Whereas for
Display sessions, the collision will be implicitly indicated by re-requesting
the device name variable during negotiations, printer sessions will receive an
explicit response header.

I believe that a response record should be returned for display sessions as
well.  The Response Code portion of the Response Record should be very useful in
determining the reason for device creation failure.  Recall that some AS/400
administrators turn off device auto-creation, the response record will then
allow distinction between failures due to device name collisions vs.
non-existent devices.

Aladin Dajani

---

From: Jeffrey Stevens <[email-masked]>
Date: Thu, 18 Jun 1998 18:40:57 -0500

Just to clarify, our RFC is a Draft RFC, and can be gotten from the link
http://www.ietf.org/ids.by.wg/tn3270e.html.  We do not have a formal RFC
number yet.

Also, Telnet displays and printer devices differ in that displays were not
originally designed to have Startup Response Records. The Telnet interface
for displays (RFC1205) is an integrated protocol designed for displays
(3270, 5250, VTxxx type terminals).  At the time RFC1205 was developed, the
need for the client to know the device name selected was not anticipated.

When we extended this protocol to printers, we added the SRR interface
since there were no backwards compatibility issues.  Thus, you can get the
device name for printer devices.

While we agree the auto-selected display name would be useful to clients,
we did not consider adding SRR for displays because of the backwards
compatibility issues involved, and the potential to break existing
clients.  Instead, we extended the Telnet protocol via the NEW-ENVIRON
otpion to allow you to select the device name by negotiating a USERVAR
called DEVNAME until an acceptable device was found.  Unfortunately, this
does not help clients to know the device name for auto-selected devices
(QPADEVnnnn).

--
J.S. (Jeffrey) Stevens      AS/400 TCP/IP          (Telnet/WSG/LPD)
Work:  [email-masked]        Personal:  [email-masked]

---

From: Aladin Dajani <[email-masked]>
Date: Fri, 19 Jun 1998 09:25:15 -0400

Jeffery Stevens wrote:
"Instead, we extended the Telnet protocol via the NEW-ENVIRON
otpion to allow you to select the device name by negotiating a USERVAR
called DEVNAME until an acceptable device was found.  Unfortunately, this
does not help clients to know the device name for auto-selected devices
(QPADEVnnnn)."

Although not knowing your device name is an annoyance, another drawback
of not having an SRR is not knowing the reason for device creation failure.
This is more than just an annoyance. The benefits of having an SRR for displays,
I believe, outweight the effort to implement it on the server side.

A NEW-ENVIRON parameter could be defined to negotiate the SRR much in
the same way IBMRSEED is negotiated, a blank response means the client
does not support SRR and the server will not send one!  This will resolve the
compatibility issue while maintaining a better interface.

Aladin Dajani