From JNCatMIT-XX  Thu Sep 30 00:00:00 1982
From: JNCatMIT-XX (J. Noel Chiappa)
Date: 30 Sep 1982, 00:00
Subject: [Ben Littauer <littauer at BBN-UNIX>: TAC/ITS telnet problems]
Message-ID: <mailman.251.1479821107.4695.its@nocrew.org>

Mail-from: ARPANET site MIT-MC rcvd at 30-Sep-82 1601-EDT
Date: Sep 30 1982 15:52:57 EDT (Thursday)
From: Ben Littauer <littauer at BBN-UNIX>
Subject: TAC/ITS telnet problems
To: REM at mit-mc, POURNE at mit-mc, EAK at mit-mc, JNC at mit-mc
Cc: frye at BBN-UNIX, ditmars at BBN-UNIX, clifford at BBN-UNIX, littauer at BBN-UNIX


There has been a lot of traffic recently about this TAC/ITS telnet bug.
There are many misconceptions about what is going on in the TAC, and I
can only assume that much of the speculation I see about what ITS is doing
is also wrong.  I am currently looking into this problem, and trying to
sort out the facts.  It would be helpful if I had a contact at MIT who
could get me access to and account on MIT-MC and who would KNOW what MC
is supposed to do in these funny situations.  Any volunteers?  I expect 
to be doing some investigation during this coming week.  I can be
reached via netmail or at BBN (497-3196).

One major confusion about the TAC relates to its buffer sizes.  The TAC
has static buffering on input and dynamic buffering on output, and both
input and output buffers are relatively small.  The TIP's buffers could
be of any size, depending on the configuration of the machine.  The TAC
does not have, nor will it ever have, 1000 character buffers for 63 
terminals in a 32K word machine...  
				    -ben-

-------


From JNCatMIT-XX  Tue Sep 28 00:00:00 1982
From: JNCatMIT-XX (J. Noel Chiappa)
Date: 28 Sep 1982, 00:00
Subject: Anyone know why ITS got unfriendly?
In-Reply-To: Your message of 28-Sep-82 2026-EDT
Message-ID: <mailman.252.1479821108.4695.its@nocrew.org>

	I'll forward your message to the TAC maintainer, Clifford at BBN-UNIX,
and see what we get back.
-------


From EAKatMIT-MC  Tue Sep 28 00:00:00 1982
From: EAKatMIT-MC (Earl A. Killian)
Date: 28 September 1982, 00:00
Subject: Anyone know why ITS got unfriendly?
Message-ID: <mailman.253.1479821108.4695.its@nocrew.org>

Because the TACs (the new TIP) seem to misimplement to TELNET
protocol.  When ITS tries to flush the data in the network using
the same method that works on TIPs it causes things to come to a
grinding halt.  I suspect someone just removed the code that
attempts to do the flushing as begin better than wedging.


From GJC at MIT-MC  Mon Sep 27 00:00:00 1982
From: GJC at MIT-MC (GJC at MIT-MC)
Date: 27 Sep 1982 00:00
Subject: No subject
Message-ID: <mailman.254.1479821108.4695.its@nocrew.org>

I've noticed a funny intermittent bug from local MC terminals today.
The characters "IOB" sometimes end up in the input stream randomly
when other keys are typed. I've noticed this both on TTY 31 and
on the VT52 near the system consol on the 9'th floor.



From CSTACYatMIT-MC  Fri Sep 24 00:00:00 1982
From: CSTACYatMIT-MC (Christopher C. Stacy)
Date: 24 September 1982, 00:00
Subject: ai namedragon
Message-ID: <mailman.256.1479821108.4695.its@nocrew.org>


There being no TV-11 anymore, I retired the name dragon.


From CENTatMIT-AI  Fri Sep 24 00:00:00 1982
From: CENTatMIT-AI (Pandora B. Berman)
Date: 24 September 1982, 00:00
Subject: ai namedragon
Message-ID: <mailman.257.1479821108.4695.its@nocrew.org>

for at least the past few weeks, taraka has been consistently hanging onto
whatever verion of lsr1 was lsr1 1 when taraka was started up. that is, 
taraka is NOT checking at intervals for a newer version and releasing the old
one to be deleted. it seems the only way to change tarka's idea of what
is the current version of the database is to gun taraka and start a new one.
this is much less than optimal. please investigate.

From DCPatMIT-MC  Thu Sep 23 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 23 September 1982, 00:00
Subject: Whither XGP?
Message-ID: <mailman.258.1479821108.4695.its@nocrew.org>

[Is BUG-ITS the right place for all of this??]

My Versatec spooler understands KST files; it has nothing to do
with the Versatec.  If you read DCP;PRESS ANOUNC you will see
that when the Versatec spooler TRIES to do press files, it
translates the press fonts into somee (hopefully) reasonable XGP
font.

If you are trying to get closer to the state of the art, flush
XGP format files.  In theory (if I turned on XGP file recognition
in the spooler), XGP files produced by R come out correctly, but
XGP files produced by TJ6 or BOLIO (and I think @) cause it to
crash.  This is interesting, becuase the :DOVER program does the
exact opposite (does everything (as far as I can tell) EXCEPT R
produced XGP files).  "Well, why don't you look at :DOVER to see
how it does it?" you might ask.  I did; it is just as
incomprehensible when it comes to XGP files as anything else I've
seen.  

From JNCatMIT-XX  Wed Sep 22 00:00:00 1982
From: JNCatMIT-XX (J. Noel Chiappa)
Date: 22 Sep 1982, 00:00
Subject: Whither XGP?
In-Reply-To: Your message of 21-Sep-82 1816-EDT
Message-ID: <mailman.262.1479821108.4695.its@nocrew.org>

	ML has it's own private direct PDP-10 interface to the CHAOS
net. I don't know if you could plug the XGP-11 into the DL-10 (or the
DTE, if it's a multi-11 one) on MC without buying new hardware, but I
doubt it. In any case, the software would require tons of work, and
I doubt there is anyone at MIT competent to do it. Basically, you're
out of luck.
-------


From Devon at MIT-ML  Fri Sep 10 00:00:00 1982
From: Devon at MIT-ML (Devon at MIT-ML)
Date: 10 Sep 1982 00:00
Subject: AI's broken Ten-11 interface
Message-ID: <mailman.265.1479821108.4695.its@nocrew.org>

When the Ten-11 interface is enabled, AI goes into an infinite loop
while trying to initialize the Chaos-11's buffers.  The NXM light stays
off when it's running, but it quickly lights up when single-stepping.
This occurs around pc=60477 (T11CK2) with the TV-11 disabled (so it
won't die trying to hack the TV-11).  Single-stepping this loop seems to
show a SETZM instruction skipping.  Perhaps the single-step key is
bouncy, but this instruction is trying to write a zero into the Chaos-11
so it might be related to the Ten-11 failure.  Would someone look at the
crash dump in the file AI:CRASH;TREE TOAD and check this out?  AI is
only available via ARPAnet because it can't talk to the PDP-11's.

From DEVONatMIT-MC  Thu Sep  9 00:00:00 1982
From: DEVONatMIT-MC (Devon S. McCullough)
Date: 9 September 1982, 00:00
Subject: No subject
Message-ID: <mailman.266.1479821108.4695.its@nocrew.org>

Date: 07 Sep 1982 00:00
From: DCP0 at MIT-MC
    To: DEVON at MIT-MC
    CC: (BUG ITS) at MIT-MC
        DEVON at MIT-MC 09/07/82 06:35:11
        One question?  If ITS sends a IAC WILL BINARY to a TIP or
        TAC, does this turn off interpretation of the IAC character
        somehow, so it should no longer be doubled?  That would be
        nasty.

    An IAC is only doubled when a 377 wants to pass all the way
    through the TELNET stream.  This is still the case when a machine
    is in TRANSMIT BINARY. 

    I think there is a big difference of opinion on the intercept
    character issue.  Characcters go from KEYBOARD to COMMAND
    PROCESSOR to TELNET STREAM to FOREIGN TELNET STREAM.  Normally
    the command processor passes through characters to the telnet
    stream, unless the intercept character is typed.  The impression
    from some people I get is that if the TAC goes into TRANSMIT
    BINARY, then the command processor will not trap the intercept
    character.  Well, my opinion is that that is a completely
    cretenous behavior.  TRANSMIT BINARY only has to do with the
    TELNET STREAM, and not the COMMAND PROCESSOR.  If TACS will not
    intercept @ when in TRANSMIT BINARY, then it is in violation of
    the description of TRANSMIT BINARY found in the April 1976
    ARPANET PROTOCOL HANDBOOK.  I doubt it has changed.

There is a difference in opinion.  The command processor is free to
decide when it's appropriate to catch the intercept character and when
it's not, and currently it does the most reasonable thing.

TIP users would be grossly inconvenienced if command characters were
intercepted in binary mode.  Fortunately they aren't.  This issue is
totally outside the scope of the protocol, and I saw no mention of it
in the APRAnet Protocol Handbook - can you give me a page number?

From DCP0 at MIT-MC  Wed Sep  8 00:00:00 1982
From: DCP0 at MIT-MC (DCP0 at MIT-MC)
Date: 08 Sep 1982 00:00
Subject: No subject
Message-ID: <mailman.267.1479821108.4695.its@nocrew.org>

Just curious, What is the kludge in DECUUO that requires the
second word of a UNAME entry in the MFD to be zero?? 

From DCP0 at MIT-MC  Tue Sep  7 00:00:00 1982
From: DCP0 at MIT-MC (DCP0 at MIT-MC)
Date: 07 Sep 1982 00:00
Subject: No subject
Message-ID: <mailman.268.1479821108.4695.its@nocrew.org>

An IAC is only doubled when a 377 wants to pass all the way
through the TELNET stream.  This is still the case when a machine
is in TRANSMIT BINARY. 

I think there is a big difference of opinion on the intercept
character issue.  Characcters go from KEYBOARD to COMMAND
PROCESSOR to TELNET STREAM to FOREIGN TELNET STREAM.  Normally
the command processor passes through characters to the telnet
stream, unless the intercept character is typed.  The impression
from some people I get is that if the TAC goes into TRANSMIT
BINARY, then the command processor will not trap the intercept
character.  Well, my opinion is that that is a completely
cretenous behavior.  TRANSMIT BINARY only has to do with the
TELNET STREAM, and not the COMMAND PROCESSOR.  If TACS will not
intercept @ when in TRANSMIT BINARY, then it is in violation of
the description of TRANSMIT BINARY found in the April 1976
ARPANET PROTOCOL HANDBOOK.  I doubt it has changed.

From DEVON at MIT-MC  Tue Sep  7 00:00:00 1982
From: DEVON at MIT-MC (DEVON at MIT-MC)
Date: 07 Sep 1982 00:00
Subject: No subject
Message-ID: <mailman.269.1479821108.4695.its@nocrew.org>

I spent several hours this morning trying to track down a sporadic TAC or TELSER bug
wherein either the TAC gets wedged and refuses to accept binary output when ITS wants
to do so, or else it accepts and TELSER is too wedged to notice the ack from the TAC.

Couldn't duplicate it once the symptoms became clear enough to try to get them on purpose.
Who has done this before?  Is there some interaction or protocol change I'm unaware of?
I'm not sure whether the TAC or TELSER is at fault.  The basic symptom is that I will
send IAC WILL BINARY (I do :imgout 377 373 0 at DDT) and the TRBINF in telser stays zero.
Alternating between WILL and WONT produces no effect either.

From DEVON at MIT-MC  Tue Sep  7 00:00:00 1982
From: DEVON at MIT-MC (DEVON at MIT-MC)
Date: 07 Sep 1982 00:00
Subject: No subject
Message-ID: <mailman.270.1479821108.4695.its@nocrew.org>

One question?  If ITS sends a IAC WILL BINARY to a TIP or TAC, does this turn off interpretation of the IAC character somehow, so it should no longer be doubled?  That would be nasty.

From DEVONatMIT-MC  Tue Sep  7 00:00:00 1982
From: DEVONatMIT-MC (Devon S. McCullough)
Date: 7 September 1982, 00:00
Subject: connecting to ITS from an ARPAnet TAC
Message-ID: <mailman.271.1479821108.4695.its@nocrew.org>

TelSer should always initialize TelNet connections with IAC WILL BINARY.

TCTYP really should try to adjust a TIP or TAC connection when %TPMTA
is called for, maybe by means of a new keyword, like EIGHT or META.
If connected via a TIP/TAC, TCTYP should then issue IAC DO BINARY.

Extensive experiments tonight with USC-TAC show that everything will
work fine if you tell a TAC that ITS is going to transmit binary.

It works well for some people to ask the TIP/TAC to transmit binary,
but this disables @ interception, and will thus screw many TIP/TAC
users.  The only way they'd have to undo this is either hang up and
redial the TIP/TAC, or log out and wait for TelSer's 2 minute timeout.
Since I need this feature to enable my terminal's META key, I have
fixed my login file to do :IMGOUT 377 373 0 and logout to do :IMGOUT
377 376 0 when my TCTYP specifies %TPMTA.  These magic numbers are IAC
DO BINARY and IAC DONT BINARY respectively.

Apropos nothing in particular, the TIP manual claims that if the host
sends 207 <command> ^J to a TIP in OLD TELNET it will work as if the
user had typed @ <command> ^J on his terminal, but it does work on
TACs so I guess New TelNet never evolved a replacement for this
necessary feature, or are they STILL ruinning OLD TELNET???

From DCPatMIT-MC  Sun Sep  5 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 5 September 1982, 00:00
Subject: MINITS supdup to MC
Message-ID: <mailman.272.1479821108.4695.its@nocrew.org>

I believe there is a bug-minits mailing list.  Anyway,  

I think MINITS does do the decrement hack necessary for ITS.  I
can not make it fail on my AAA which is connected to a MINITS and
I am SUPDUPing to MC.  I have tried printing files which have
lines lengths greater than that of the terminal and cannot make
it fail.  I suspect the problem is actually the setup modes of
the terminal.  ITS assumes (or enforces in the initial string)
and MINITS assumes (but does not currently have an initial string
to enforce it with) that /terminals/ DO NOT automatically wrap
when a character is displayed on the last column.  This may be a
personal preference, but if you are on an AAA and if the second
bit of setup mode D is on, turn it off and tell me if it still
loses.  If you type S to get out of setup, it will save the
current configuration (and hope you dont have wars over the
proper modes).


From KMPatMIT-MC  Sun Sep  5 00:00:00 1982
From: KMPatMIT-MC (Kent M. Pitman)
Date: 5 September 1982, 00:00
Subject: MINITS supdup to MC
Message-ID: <mailman.273.1479821108.4695.its@nocrew.org>

When Supdup'ing to MC, MINITS (I guess) incorrectly supports over-run lines.
it seems that they don't end up incrementing ITS' notion of what line it's 
on, so at the bottom of the screen, some hardware scrolling happens because
ITS doesn't realize soon enough that it's time to give a --more-- break and 
pop to the top of the screen. this effect is easy to reproduce.
just print a file which has lines longer than the line length and watch what
happens as you reach the bottom of the screen.


From DCPatMIT-MC  Fri Sep  3 00:00:00 1982
From: DCPatMIT-MC (David C. Plummer)
Date: 3 September 1982, 00:00
Subject: No subject
Message-ID: <mailman.274.1479821108.4695.its@nocrew.org>

I think you are confused (though it could be me).  DO TRANSMIT
BINARY does not mean the TAC can't trap its escape character, itjust
means it should not do any special processing on the characters.
There is another option I belive for complete binary transmission
which cannot be reverted; I do not think TRANSMIT BINARY is that option.
I gues one of us should check the protocol specification...


From DEVONatMIT-MC  Fri Sep  3 00:00:00 1982
From: DEVONatMIT-MC (Devon S. McCullough)
Date: 3 September 1982, 00:00
Subject: No subject
Message-ID: <mailman.275.1479821108.4695.its@nocrew.org>

DO TRANSMIT BINARY would screw people who try to close their ITS
connection and reconnect, since in binary mode the TIP (TAC) does not
hack local user commands.  Perhaps the TIP/TAC ressets this when you
close the connection?  It would still be boring to logout and have to
wait until TelSer gets around to closing your connection.

Currently TelSer knows about CR and CRLF and sets your TCTYP in
accordance with the protocol you are sending, so this is no problem.

From DCP at MIT-MC  Fri Sep  3 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 03 Sep 1982 00:00
Subject: No subject
Message-ID: <mailman.276.1479821108.4695.its@nocrew.org>

Is there any reason why ITS should change a %TDFS into a space
on overprinting terminals?  Here is the problem:

I am on an overprinting terminal, SUPDUPing to ITS.  I Telnet
to a system that can't deal with overprinting terminal.  VAX VMS
and I think VAX Unix have this problem.  When using CHTN, I toggle
VT52 emulation mode and tell the VAX I have a vt52 (with perhaps 
a higher screen).  When the foreign system sends an ESCAPE C (or 
whatever it is that goes forward), CHTN tells ITS to go forward.
When ITS is sending to a replacing terminal, it sends %TDFS (I hope),
but for an overprinting terminal (which it still thinks I am in this
case), it sends a space (which unfortunately is now destructive).


From JNCatMIT-XX  Fri Sep  3 00:00:00 1982
From: JNCatMIT-XX (J. Noel Chiappa)
Date: 3 Sep 1982, 00:00
Subject: TelSer
Message-ID: <mailman.277.1479821108.4695.its@nocrew.org>

	Sounds like a good idea to me. Will any ITS wizards out there
speak up if this is unreasonable? Otherwise, I'd say do it.
-------


From DCP at MIT-MC  Fri Sep  3 00:00:00 1982
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 03 Sep 1982 00:00
Subject: No subject
Message-ID: <mailman.278.1479821108.4695.its@nocrew.org>

If TELSER sends WILL TRANSMIT BINARY, then that only allows ITS
to send binary to the TAC.  You also want DO TRANSMIT BINARY
which lets the TAC legally send binary to ITS.  I aggree that
most times there will be no noticiable difference in terminal
handling.  When a user types both RETURN and LINEFEED to
something like DDT, ITS may get marginally confused, but thems
the breaks. 

I do not use TACs.  Somebody that does should try out a new
TELSER on MC or ML some night and see if it works.  Make sure CR,
LF, and CR LF all do what you expect.  Compare with old behavior.


From DEVON at MIT-MC  Fri Sep  3 00:00:00 1982
From: DEVON at MIT-MC (DEVON at MIT-MC)
Date: 03 Sep 1982 00:00
Subject: No subject
Message-ID: <mailman.279.1479821108.4695.its@nocrew.org>

When TIPs were generally used, the default output mode was (apparently) binary, but now that TACs are in vogue, terminal programs that used to work with TIPs lose, because they are only receiving 7 bits.  Perhaps TelSer should WILL Transmit Binary, which is necessary in some cases and harmless otherwise.