Re: Telnet Query

["Gilbert, Howard" <[e-mail]>]

>If you have a data length field, you do not need an <EOR>, but need Dave's
2nd
>flow model.
>If you do not use a data length field, you need an <EOR>, and use Dave's
1st
>flow model.

It seems appropriate to point out that the Write Structured Fields command
is followed by two byte binary field length.  One of the structured fields
is 3270DS in which a standard 3270 command can be placed.  Used this way,
the 3270 command would always have a data length (however, the length is
inside the command and not starting at the first byte).  The point here is
that 3270 data stream SOMETIMES has a data length, and it is not that big a
change to require that it ALWAYS have a data length.  There are other more
important issues:

     If you have a length, do you add EOR also
     If you have a length, do you quote IAC.  Can you get away without it?

>Does this mean that a data packet must start at the beginning of a TELNET
>packet, but can span a number of packets?

There is no such thing as a "packet" in TELNET.  TELNET is built on top of
TCP.  All IP and TCP packet boundaries have been lost.  TELNET is a stream
of bytes.  It must be valid that the entire 3270 command be sent as one byte
packets through the network.  It must be valid that two commands be sent in
the same TCP packet.

Generally, one receives a byte of data.  Since there is no current "block",
this byte is the first byte of the length field.  Set a flag.  When the next
byte comes in, the flag says that it is the second byte of the length field.
 You then set a residual byte count and read that many bytes from the data
stream (one at a time if necessary).  When the residual goes to zero,
process the data.

If IAC doubling is required, the second IAC is not in the byte count.
 Furthermore, since IAC can be part of the length field you have a sligthly
more complicated parse.  If IAC control sequences can be transmitted in the
middle of the block, the parse gets worse.  However, it can be handled.

From my view, however, the more pressing issue is that of status in response
to a command.  On a real 3270, a sense error would be reported back to any
Write that contained invalid data (a bad SBA address for example).  TN3270
has ignored such errors since it had no concept of sense, chain, or reply.
 Adding a requirement for "Definite Response" would be a BIG change to the
protocol, while IAC parsing is just a little change.