Re: Telnet Query

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

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21751; 17 May 93 7:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21747; 17 May 93 7:39 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa29163; 17 May 93 7:39 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 3262; Mon, 17 May 93 07:40:38 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 3257; Mon, 17 May 93 07:40:31 EDT
Date: Mon, 17 May 1993 11:34: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: <9305170739.aa29163@CNRI.Reston.VA.US>

Bruce Crabill replied:

>>We recogonize the need for a header, but <header><3270 data><EOR> is really
>>just <user data><EOR> to the first block diagram in Dave's note.

>Actually, it is not clear to me why the EOR would be needed if we had a
>header that included the data length to follow.

Very true Bruce.

The point is, we do need a header.  Lots of important control info in there.  We
do not NEED a data length field.  Some WANT a data length field.

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.

Now the issue is, what are the consequences of including a data length field?

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

Can an IAC follow a data packet in the same TELNET packet?

Is Dave's processing model correct/complete?  What are its implecations?
Particularly to a server that must be backwards compatible to RFCI type clients?

What will the IESG's review of our technical document be?  Will they feel that
this is acceptable behaviour for a TELNET implementation, or will they
'regulate' us off of port 23?

Are there other issues?

We have to answer these points along with any design that includes a data length
field.

Robert Moskowitz
Chrysler Corporation
TN3270E WG Chair