Re: Newly revised standards-track RFC

Roger Fajman <RAF@cu.nih.gov> Wed, 06 April 1994 23:08 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13640; 6 Apr 94 19:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13636; 6 Apr 94 19:08 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa05746; 6 Apr 94 19:08 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 4381; Wed, 06 Apr 94 19:06:11 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 4380; Wed, 06 Apr 94 19:05:35 EDT
Date: Wed, 6 Apr 1994 17:41:59 EDT
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: Roger Fajman <RAF@cu.nih.gov>
Subject: Re: Newly revised standards-track RFC
X-To: TN3270E@LIST.NIH.GOV
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9404061908.aa05746@CNRI.Reston.VA.US>

>    The presence of Telnet commands within a TN3270E data message
>    (i.e., between the header and the trailing IAC EOR) is not
>    recommended; neither clients nor servers should send such data.
>    IAC-commands should be sent between TN3270E data messages, with no
>    header and no trailing IAC EOR.  If a TN3270E data message
>    containing an IAC-command sequence (other than IAC IAC) is received,
>    it is implementation dependent how the IAC-command sequence will be
>    processed; the processing may be defered until after the current
>    TN3270E data message has processed.  (Any IAC-command sequence that
>    is received within a TN3270E data message that would normally require
>    response must be responded to at some point to avoid the potential
>    for deadlocks. Any IAC-command that does not require a response
>    may just be ignored.)

It might be easier to implement responding to Telnet commands that
appear in the middle of a 3270 data block as if they occurred before
the block, rather than after.  If the block is being buffered up until
it is complete, then the Telnet commands could be processed while the
block is being received.  I think it should be the receiver's option to
process them as if they occurred before or after.  We probably should
also say that it is OK to deny requests in the middle of a block that
would be accepted between blocks.