Cas Caswell writes:

>   Second, Telnet Server/iX does term type 10, ie HP terminal behavior only.
>   Therefore we send the D1 read trigger. The default terminal on windows
>   tends to display the D1 as a SPLAT (for lack of a better technical term).
>   This looks bad on your display, but so far as I know doesn't mess up any
>   CI type functionality. If you write an application that reads the screen,
>   you should look into using FDC 192,30 (see the Asynch Programmer's
>   Reference Manual for details) to disable the read trigger. Of course we
>   only support Telnet/iX Server with clients doing HP terminal emulation.
>   So technically using the default windows terminal emulater is
>   unsupported.

Cas,

As you may know, we're in the process of putting together a full-function
Windows-based HP terminal emulator that we will distribute for free. Because
it will be free, I suspect that it will be a big seller :-) (actually, I'm
not kidding. If we do a good job, I suspect that the terminal emulator should
become a standard item).

At the moment, our plans are to support only Telnet rather than NS/VT. NS/VT
would seem have no advantages over Telnet if the client is in block mode for
outgoing data flow. Likewise, there should be no differences on incoming data
flow, either. Thus, unless I'm misunderstanding something, the single great
advantage that NS/VT has over Telnet is when the user is typing characters.
Under Telnet, each character is transmitted to the host and echoed back -- a
process that can be slow and unpredictably non-responsive, especially when
performed some distance from the host.

However, it would be very easy for us to program up the terminal emulator to
buffer up a complete line and transmit it a line at a time under Telnet, just
as NS/VT does -- if we knew the HP3000 wasn't in a single- or fixed
number-character read state. And if we did know we were in a fixed
number-character read state on the HP3000, we could easily keep track of that
number of characters and transmit the line once that limit was reached.

Clearly, we're honoring the DC1 read trigger in the new terminal emulator
now. But this is an HP3000-ism that, while greatly increasing the assurance
of proper data transmission, does nothing to much interfere with talking to
basically any other box, from the terminal's point of view.

The same could be done with Telnet/iX, if you (HP) would be willing to do it.
If Telnet/iX were to transmit an escape sequence (simply make one up) to tell
the remote terminal that we were now in a n-character read mode sometime just
prior to the DC1, we'd be in hog heaven. (The same sequence could be
transmitted with a 0 length to indicate that we've switched back to an
unlimited, CR-delimited read mode).

Clearly, the transmission of this sequence would generate a bigger SPLAT on
the windows default Telnet client's screen, but it provide a dramatic
difference in the perceived responsiveness of an HP3000-specific Telnet
client terminal that honors this information, especially in those situations
of a busy host or busy LAN.

Although the standard windows Telnet client wouldn't understand nor honor
this sequence, it wouldn't adversely impact its operation either. Because the
standard client is always essentially in a single-character read mode, the
HP3000 would behave normally -- and the standard client would do the best
that it can (given that it doesn't understand much about the HP3000 anyway).


A second subject -- Security

In distinct contrast to last year's giant poster project, the terminal hasn't
generated zero public discussion on HP3000-L. However, it has generated a ton
of private e-mails to me, almost all of which have had one good suggestion or
another (and we're recording every one of those suggestions).

Gary Dietz of Whitman College had a particularly appropriate request, but one
again that we can't do with you, Cas. Gary's concern is transmitting
passwords over the open net. He wrote:

>  Also, have you ever given any thought to implementing any sort of
>  encryption, to avoid the problems of clear-text passwords being
distributed
>  across the network?  To my knowledge nobody is doing this for the HP3000
>  yet.  On our Unix box we use a product called F-Secure SSH, which provides
>  encryption and RSA authentication.  I know that this goes way beyond the
>  "terminal emulator" function, and would involve also writing a "server"
>  application for the 3000, but it is certainly a feature that would be
quite
>  beneficial.

I think that this is actually quite a good idea -- but we can't do it by
ourselves, since we can only control one half of the conversation. We would
be pleased to work with you to implement some form of public key encryption
mechanism to pass either passwords alone or essentially all text in encrypted
format back and forth from the terminal to the HP3000, again with an escape
sequence (much like turning echo on and off, perhaps).

As LAN-based transmissions becomes more common in the HP3000 population --
and as the remoteness of the client from the HP3000 host becomes further --
the pressure to do something like this can only likely increase.

Again, this is a behavior that can be made to be completely transparent to
all prior use, especially if the client terminal is the party that initiates
the request to turn encryption on. In this manner, no existing terminal or
terminal emulator would be affected. Their transmissions would remain simply
clear text.


A Third Subject -- a Progress Report on QCTerm

Alfredo Rego is fond of quoting Henry Ford, where he says, "Never complain,
never explain" -- but, what the heck, I'll explain anyway. Things have slowed
down significantly associated with the development of the terminal over the
past few weeks, which means it's going to be a bit later than I originally
expected.

There are only two of us working on the terminal -- and we've both had very
fine cases of the flu for the past six weeks (I personally slept through
almost two weeks of that time). Thus, in the twelve manweeks of work that
could have gotten done, perhaps only one or two were actually accomplished.
But this is the way life goes. Programming is a human activity, not rote
machine work. And as with all life, you're born, you die, and in between, you
sometimes get sick.

Nonetheless, a "rough-draft, first-cut, pre-alpha" copy will be available
soon. It will be important to understand what this first version will be --
just a glimpse of what the eventual terminal will look like, as well as a
chance for you all to say whether or not we need to reverse course in one or
another design decisions.

Wirt Atmar