Don't use bucky bits to input control characters.

[larsbrinkhoff]

The supdup client uses the "intelligent terminal protocol" to transfer input control characters as their corresponding upper case character with the control bit set.

I'd argue that this is confusing for applications, unless %TOCFI also is set.

RFC 734 doesn't clearly say what to do. There's this:

Input differs dramatically between the 7-bit and 12-bit character sets. In the 7-bit character set, all characters input whose value is 037 octal or less are assumed to be (ASCII) control characters. In the 12-bit character set, there are 5 "bucky" bits which may be attached to the character. ... Under normal circumstances, characters input from the keyboard are sent to the foreign host as is. There are two exceptions; the first occurs when an octal 034 character is to be sent; it must be quoted by being sent twice, because 034 is used as an escape character for protocol commands. The second exception occurs when %TOFCI is set and a character with non-zero bucky bits is to be sent.

But also this:

In addition, the following special characters exist for input only.  These
characters are  function keys  rather than  printing characters;  however,
some of these  characters have some  format effect or  graphic which  they
echo as; the host, not the SUPDUP program, handles any such mappings.

Value   Character       Usual echo              Usual Function

 0000   [NULL]
 0010   [BACK SPACE]                            text formatting
 0011   [TAB]                                   text formatting
 0012   [LINE FEED]                             text formatting
 0013   [VT]                                    text formatting
 0014   [FORM]                                  text formatting
 0015   [RETURN]                                text formatting
 0032   [CALL]          uparrow-Z               escape to system
 0033   [ALTMODE]       lozenge or $            special activation
 0037   [BACK NEXT]     uparrow-underscore      monitor command prefix
 0177   [RUBOUT]                                character delete

 4101   [ESCAPE]                                local terminal command
 4102   [BREAK]                                 local subsystem escape
 4103   [CLEAR]
 4110   [HELP]                                  requests a help message

BUCKY BITS

For all input characters, the following  "bucky bits" may be added to  the
character.

[larsbrinkhoff]

The background for this change is that I updated ITS' DDT to read the full 12-bit characters to do something useful with the meta bit. But now supdup stopped working because DDT gets e.g. ^F as %TXCTL + F. Even though DDT checks for %TOCFI and it's not set.

[larsbrinkhoff]

So what I did here was to change the supdup client to pass all control characters unchanged, except of course ^\ which is quoted.

[dabridgham]

AIM 644 seems fairly clear with "If %TOFCI is zero, SUPDUP input is restricted to a subset which is essentially ASCII (but 034 must still be encoded as a sequence of two 034's)".

I recall when I first wrote the Unix SUPDUP client I wanted to set %TOFCI because I had modified my VT52 to have a META key and I wanted that to work. I think the code was changed later on to not set %TOFCI because it didn't really generate "all the meaningful codes of the 12-bit character code".

[bictorv]

It seems like a sane thing. Did you check what the Java Supdup client does? And what the LISPM Supdup client does?

[larsbrinkhoff]

No, I only checked this one and ITS. I'm too lazy to look into the Java sources. The Lispm file says it sets %TOFCI so I guess it it's free to send bucky bits. Ideally all clients and servers should be tested, but I'll have to rely on volunteers. Or future bug reports.