[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[DISC] Escaping #$#



Another item missing from the spec:

	How do you escape/quote a line beginning with #$#  ?

That is, what text does one send so that a line of the form
  #$#<arbitrary-characters>
will appear in the ordinary (non-OOB) datastream at the far end?

This is an issue for the LambdaMOO server as well as for MCP, since I
haven't yet seen anything about it in the MOO Programmers' Manual.

"Don't do that," is not an acceptable answer.  This is not simply
a matter of avoiding using the name #$# as a MOO command name.  

I will grant that #$# was (most likely) chosen so as to not naturally
come up that often, but even so, assuming it won't come up at all
is just a very BAD assumption.  If nothing else, it comes up fairly
often in discussions about MCP and OOB messages in MOO input 
streams, discussions in which people will fairly often refer to 
#$#, not to mention the possibility of even having lines start with
#$#.  

Now try pasting or MOOmailing the previous paragraph to someone.

A similar matter has to do all of the times I see a line starting with
>From in a sendmail-processed mail message.  It's infrequent, but the
infrequency of it actually makes it worse since few are inclined to 
fix it, so we're just screwed.

I've noticed that JHCore $player:notify DOES prefix a space to #$#
lines.  This is fine for the immediate issue of preventing OOB spoofs,
but it sucks as a general quoting convention:  on input, every line
beginning with a space (of which there will be many) would have to be
checked to see if the next 3 chars are #$# so that the space can be
removed.  And then we have to deal with the fact that
#$#...
 #$#...
are conflated, meaning the sender has to be doing yet more work.

ALTERNATIVES:
- - - - - - - - - - - - - - -
(1) Reserve an OOB sequence to be used for quoting, e.g., 
      # $ # " <space>

- - - - - - - - - - - - - - -
(2) Introduce a new special "OOB-quote" sequence, e.g., 
      # $ "
    to be distinct from the OOB sequence
      # $ #
    itself.  Servers and clients would need to handle both of these.
- - - - - - - - - - - - - -

In either case lines beginning with the quote sequence would have the
characters of the quote sequence stripped off; remaining characters
would stay in the ordinary stream verbatim.  The sender is responsible
for quoting lines that would otherwise be interpreted as ordinary OOBs.
For example, under alternative (1), given the stream (indented by 2
spaces)

  streams, discussions in which people fairly often refer to
  #$#" #$#, not to mention the possibility of even having lines start
  #$#cmd 1237625 foo*: "" _data-tag: 666
  #$#" #$#,
  #$#* 666 1237625 first line of foo
  #$#" #$#" , or even
  #$#* 666 1237625 second line of foo
  #$#" #$#" #$" .
  #$#: 666
  
a client should parse out the OOB 'cmd' message with its 2-line 'foo:'
field, leaving behind

  streams, discussions in which people fairly often refer to
  #$#, not to mention the possibility of even having lines start
  #$#,
  #$#" , or even
  #$#" #$#" .
  
in the ordinary stream.  

The corresponding stream to send under alternative (2) would be

  streams, discussions in which people fairly often refer to
  #$"#$#, not to mention the possibility of even having lines start
  #$#cmd 1237625 foo*: "" _data-tag: 666
  #$"#$#,
  #$#* 666 1237625 first line of foo
  #$"#$#" , or even
  #$#* 666 1237625 second line of foo
  #$"#$#" #$#" .
  #$#: 666

I mention possibility (2) since, though (1) is cleaner and slightly
easier for client writers (having the advantage that every line
requiring special treatment begins with #$#), it may be virtually
impossible to implement on the current MOO server, given how hard it is
to take something already grabbed by #0:do_out_of_band_command() and
re-insert it into the ordinary input stream at the right place.  

Secondly, since there may exist servers that don't grok OOB-quotes, it
would be better that these lines be passed through garbled rather than
entirely dropped on the floor as per the usual treatment for bad MCP
messages.