Comments on Stds track RFC Internet Draft

Bill Kelly <> Fri, 09 July 1993 16:23 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa04993; 9 Jul 93 12:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04989; 9 Jul 93 12:23 EDT
Received: from by CNRI.Reston.VA.US id aa15001; 9 Jul 93 12:23 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 0264; Fri, 09 Jul 93 12:25:00 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 0259; Fri, 09 Jul 93 12:24:49 EDT
Date: Fri, 9 Jul 1993 11:31:57 -0500
Reply-To: Bill Kelly <>
X-Orig-Sender: IETF TN3270E Working Group List <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Kelly <>
Subject: Comments on Stds track RFC Internet Draft
X-To: TN3270E list <>
To: Multiple recipients of list TN3270E <>
Message-ID: <9307091223.aa15001@CNRI.Reston.VA.US>

Hi all,

Owen has not been able to devote the time he had hoped to working on the
draft RFCs.  As I'm sure you are aware, it's been awfully quiet on the
list for the last month or two.  Bob has been fending off the IETF higher-
ups, who (rightly) want to see results.

So, in order to at least try to get things moving again, I've put together
a proposed Internet Draft laying out the standards track protocol, and
will be posting it along with these comments.  (See below for ftp access.)
The idea is that it's better to get *something* submitted as a draft to
at least keep us alive as an IETF Working Group, even if it means we
submit a draft in two weeks that winds up being gutted and completely
revised by subsequent drafts.

Several notes on this draft:

- It was done in great haste, so I expect there to be holes, both large
  and small.  I point out just a few a little bit later in this posting.

- I took the non-controversial approach when it came to Peter's proposal
  about length fields in headers eliminating the need for IAC scanning
  and EOR processing.  The method I've used works pretty much like today's
  tn3270 in this respect.  This doesn't mean that the approach in the
  draft is the best way, just one that (I think) might work.  It seems like
  there was a fairly wide variety of opinions on this when it was discussed.

- Not all of the items discussed at the IETF meeting are included in the
  document.  This is mainly because I wasn't sure of the reasons they need
  to be supported.  SNA Bid and CD, for example, are absent.  The mechanism
  is in the protocol to support them if needed, I think.  I did include
  SNA bind image passing, although again I had no specific reason to
  justify it.

Some more holes/items to be discussed:

1) Valid device-names

   As it stands, the draft includes all the 3270 terminal devices listed in
   the Assigned Numbers RFC, plus IBM-3287-1 for a printer device.  Bruce
   has suggested we do away with all that, since there are other means of
   determining the screen size and extended datastream support for terminals.

   What about it folks?  I believe that if we simply negotiated two device-
   types - TERMINAL and PRINTER, we could probably get everything else
   from the SNA bind (but what about non-SNA servers?) and/or the structured
   field Query Reply.  The draft already states that all TN3270E clients must
   be able to reply to a Read Partition Query (even if only to say that it
   doesn't support structured fields); what about extending it to say they
   must be able to convey presentation space and other basic information?
   I've never done much structured field stuff, but it looks like we could
   require clients to support just a few Query Replies that would get the job

2) 3270 ATTN and SYSREQ keys

   I think discussion centered on using Telnet BREAK for ATTN and IP for
   SYSREQ.  The draft uses IP for ATTN and AO for SYSREQ.  The reasoning
   behind this was that BREAK is not a Telnet command - it's an NVT "key."
   RFC 854 states (of the BRK key):

        "It is intended to indicate that the Break Key or the Attention
        key was hit.  Note, however, that this is intended to provide a
        129th code for systems which require it, not as a synonym for
        the standard IP representation."

   I wasn't exactly sure what this meant.  After reading over IP and AO, IP
   just seemed appropriate for ATTN.  Since SYSREQ doesn't initially send
   anything to the host application (it just keeps on running), but it
   prevents the host app from being able to send to the device, I thought
   it seemed appropriate to use AO for SYSREQ.

   Whatever the group wants to do, though...what do those clients and
   servers that support ATTN now use?

3) "Bad" clients and servers

   How should a client or server react if the other side sends a header
   value that relates to a TN3270E function that was not agreed to in the

4) Re-negotiation of TN3270E functions?

   Once a session has been rolling along for a while, is there any reason one
   might want to re-negotiate function support?  Any reason this shouldn't
   be allowed?

5) Session outage

   Not a word in there about what happens when a connection fails.  Probably
   not an issue for terminals, but may be a major one for printers.  This
   has been discussed a little in the past, but needs more.

6) Examples

   There probably need to be some examples of data flow.  I only had time
   to include examples of the device-type and function negotiation.

7) Some of the non-SNA response info (status and sense byte stuff) may need
   to be cleaned up a little (or a lot?).

There are probably a lot more, some of which occurred to me over the past few
days, but I can't recall any more at the moment.

Also, in case the form feeds embedded in the document get munged up in the
mailing process, I've made a copy of it available via anonymous ftp.  If
you want to grab it:

 - ftp to (

 - userid anonymous (actually, it's anonymou - the 's' is ignored.  What
                     can I say?  It's an MVS host!)

 - password anything you like (except null)

 - for the time being, you'll need to issue a cd 'public' command
  (INCLUDING the single quotes); I hope to eliminate the need for this part
  sometime next week

 - there's not much there, so you can wing it from this point

This is read-only access [else, it's my job! ;-) ].


Bill Kelly               phone: (205) 844-4512
Auburn University     Internet: