Subject: Question wrt escape/control characters

From: [email-masked] (Joe Navratil)
Date: Tue, 2 Mar 1993 12:58:48 -0800

I've been fooling around with ANSI music via MOO for the past couple days. 
It's worked pretty well, once, I remapped ~ to ^[ (\027) and ` to ^N (\014)
(I was given the suggestion by someone on this list, actually :-) ) 

Anyway.  I was wondering if there are any plans to include a function or
set of constants or whatever that will make it possible to send the *real*
characters, and not have to bother with explaining to people to remap the
stuff, then explain how to remap, etc... or, if there aren't any plans, why
not?

 -Joe

---

From: Pavel Curtis <[email-masked]>
Date: Tue, 2 Mar 1993 15:02:38 -0800

> Date:	Tue, 2 Mar 1993 12:58:48 -0800
> From:	[email-masked] (Joe Navratil)
> 

There are two separate issues in here: allowing MOO code to *receive*
non-printing ASCII characters, and allowing code to create, manipulate, and
(ultimately) send those characters to users' connections.

The current state of affairs is that the server elides all characters from its
input except printing ASCII and the space character.  (Actually, it also
notices the ASCII LF character as an input-line terminator, but it removes it
before passing the line on.)  As there is also no way for a MOO program to
construct a character out of whole cloth (e.g., from an integer character
code), this implies that there is no way for a MOO program to send a string
containing non-printing/non-space ASCII to a user.

The reason for the current state of affairs is a concern for security.  Many
kinds of terminals are open to relatively serious attacks via the receipt of
certain escape codes.  For example, it is possible with many terminals to lock
out the keyboard, to force a transmission of everything on the screen, to load
function keys with arbitrary strings and then force their transmission, etc.
In an open environment like the Internet, it seems prudent to prevent such
mischief.

Of course, in some environments, these security concerns are not as important
and so it might be a good idea for these restrictions to be optional in the
server.  Then, one could add a primitive, perhaps, to convert integer character
codes into single-character strings.

The right solution, probably, is to have the server optionally check output for
`illegal' characters and strip them there.  Then I could unconditionally add
the conversion primitive, since it couldn't do any harm if output-filtering was
enabled.

I will consider adding such a facility to the server.

	Pavel

---

From: Greg Hudson <[email-masked]>
Date: Tue, 2 Mar 1993 18:31:48 -0800

Pavel Curtis writes about direct transmission of control characters:

> The reason for the current state of affairs is a concern for security.

A possibly more serious concern is that most people's environments
cannot handle ANSI or VT-100 codes.  Even if they are using ANSI or
VT-100 terminals, clients such as Tinyfugue and Vaportalk do not
emulate terminals and become confused by non-printing characters.  I'm
not sure how well Emacs clients do.  I'd be worried that simply
allowing programmers to send nonprinting characters down the socket
would lead to quite a few of them doing it indiscriminantly, and many
of those who do not having many separate methods of deciding whether a
terminal can support them, so that a user must go through a lot of
effort to specify to various programs whether or not they should send
nonprinting characters.

As to the discussion about sending bitmaps, mud graphics have been
done before in a more bandwidth-friendly way.  BSXmud is a
client/server combination which allows the server to direct the client
to print a series of filled polygons.  Although this doesn't allow for
anything better than cartoon graphics, bitmaps are awfully expensive
for today's Internet.

I have never heard of MIME, but it's worth noting that muds are in a
somewhat unique situation: there are no standards for communicating
between servers and clients, and no one has successfully implemented
such a standard (even Ken Keys' and my simple proposal that LP and
Dikumud server writers send an IAC GA or use the telnet EOR option to
mark prompts seems to have met with nought more than a short flamewar
and a large yawn).

I may be looking at a different aspect of muddom than some of the
conversants are interested in--I'm generally more concerned with not
leaving people behind than most, and certainly some people are
thinking about fairly controlled environments.  In this case, some of
my arguments are irrelevant.

--GBH

---

From: [email-masked]
Date: Wed, 3 Mar 1993 21:27:14 -0800

> ... A possibly more serious concern is that most people's environments
> cannot handle ANSI or VT-100 codes.  ...

> ... BSXmud is a client/server combination which allows the server to direct 
> the client to print a series of filled polygons. ...

> ... I have never heard of MIME, but it's worth noting that muds are in a
> such a standard ...

> ... some people are thinking about fairly controlled environments.  In this
> case, some of my arguments are irrelevant.

IMHO, the security issue is not worth considering.  Also, Just being able to
send bitmaps or vt100 escape codes isn't strong enough as a good quality,
general, output mechanism for MUDs.  What I "really want" is a very high
level, low bandwidth display protocol with a good client package that
implements it.  Of course, window system vendors have been searching for this
sort of thing for years ...  If the client is good, however, I feel the
standard will stick, and other MUDs will follow suit. 

Given this design decision, MOO really doesn't have to change very much at
all, since there is already enough consideration given to "out of band" data.

I haven't looked into this sort of stuff too much, to tell the truth, although
I think I may have tried a BSXmud late one evening.

--GBH

---

From: [email-masked]
Date: Wed, 3 Mar 1993 21:53:16 -0800

whoops i missigned that.

sorry.

--joe