Re: Telnet Query

"Robert G. Moskowitz" <0003858921@mcimail.com> Mon, 17 May 1993 16:52 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00938; 17 May 93 12:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00934; 17 May 93 12:52 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa08545; 17 May 93 12:52 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 3653; Mon, 17 May 93 12:54:20 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 3648; Mon, 17 May 93 12:54:14 EDT
Date: Mon, 17 May 1993 16:07:00 GMT
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921@mcimail.com>
Subject: Re: Telnet Query
X-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9305171252.aa08545@CNRI.Reston.VA.US>

Howard Gilbert replied:

>>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.

True, true, we have been supporting Write Structured fields automagically in
TN3270 for some time.  But in all cases there can be IACs within the data stream
and there must be an <EOR> as the end of the 3270DS block.  These are the
changes being discussed.

>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.

Thanks, I was mixing TELNET and TCP.  Yes TELNET does not have packets, but I
have watched TELNETDs pump out large streams of bytes and then do a PUSH to
form a 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.

OK, Howard, I get the drift.  Someone should build an FSA for this and fit the
whole thing into Dave Borman's models.  We might have to include this FSA in
RFCS.

>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.

This was covered in the March 30th presentation at Columbus.  It should be in my
transcription of it.  The thoughts of those present was that both positive and
negative responses were negotiable items.  Either side can request them; either
side can deny them.  This would be a sub-negotiation in the 3270-Regime.

I wonder if an argument can be made for always requiring negative responses.  I
do know that there are cases were positive responses are required and those
where it is not wanted.

Robert Moskowitz
Chrysler Corporation
TN3270E WG Chair