🚀 go-pugleaf

In article <1992Oct30.185456.18118@news.csuohio.edu>
	cowboy@trans.csuohio.edu (Joe Rosenfeld) writes:
>I work at a University Law Library, where we use the internet for many  
>things.  One of our vendors, mead Data central, the creator of Lexis, has  
>an unusual telecommunications system situation.  When we telnet to the  
>site on ANY platform, without using emulation software not available for  
>the NeXT, we get a screen full of garbage.  I have discovered that the  
>reason for this garbage is that Lexis expects to see a 7-e-1  
>communications setup and the telnet session is eight bits.

Then they're violating protocol and are 100% responsible for
correcting the problem.

[RFC 1123]
|         In NVT mode, a Telnet SHOULD NOT send characters with the
|         high-order bit 1, and MUST NOT send it as a parity bit.

>The problem is whether this can be somehow patched or configured into my  
>NeXT telnet session, so that it appears or IS running as a 7-e-1 setup  
>over internet telnet.  Can this be done?  any advice is appreciated.

Telnet connections do not--and must not--operate 7-E.

If you are using a terminal that requires 7-E-1 (unusual these
days, but for the sake of argument), everything to the left of
the point I've labeled "demarcation" would have parity stripped
on input and generated on output; everything to the right would
be 7-N.

[view with fixed-pitch font]

       demarcation
            |
            v
+---+ serial +------+
|TTY|--------|telnet| IP network
+---+  line  |client|============>
             +------+

In the inverse case, where a so-called "milking machine" is used
to make hard ports available via telnet service, the same rule
applies: the terminal server is responsible for making any
necessary conversions.  NeXT's telnet client doesn't provide a
mechanism to to this because it's not supposed to!

The bottom line is: if the telnets at each end are operating with
the default modes, you should never see high bits on.  If,
however, you've negotiated BINARY transmission (you can determine
this by using telnet's "toggle options" command), you should get
an 8-bit-clean path--but that's still a NO PARITY configuration.

When you pay big bucks to a commercial service provider, you
expect them to perform a competent job.  The situation you
describe is inexcusable.

					-=EPS=-