Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!HOGG.CC.UOREGON.EDU!jqj
From: jqj@HOGG.CC.UOREGON.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TELNET Buffering Woes
Message-ID: <8905041341.AA01963@hogg.cc.uoregon.edu>
Date: 4 May 89 13:41:36 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 17

The usual objection to having ^C send an IAC and cause output flushing
via timing marks is that ^C, like any ascii character, has multiple
context-dependent meanings on the server end.  What I think this
discussion is missing is the observation that much telnet traffic these
days originates not from terminals and RS232-connected devices but from
PCs and workstations running user telnet.  In such environments, it is
fairly easy to have a local key sequence (Hyper-ctrl-C, ^]s iac^M,
PF34, mouse on the interrupt button in your window, or whatever) that
is assigned to generate a telnet interrupt character.  In such an
environment there is no particular need for the new telnet options,
since a user can generate either ^C or IAC; presumably the USER knows
what state her program on the server is in, and so knows what she wants
to send!

My question:  how many server telnets "correctly" (as defined by DAB)
handle receipt of IAC with timing marks?  How many client telnets correctly 
handle generation of timing marks when the user sends IAC?