Tinyfugue was last updated officially on January 14th 2007. Since that time several "out of band" communication protocols, such as ATCP, GMCP/ATCP2, and AARD (102), have been created to facilitate data transfer between MUD clients and MUD servers. These protocols use telnet option "subnegotiation". Tinyfugue needs to be updated to be able to negotiate these newer protocols, and any other future protocols, that use telnet option subnegotiation.
Before telnet option subnegotiation can occur, telnet option "negotiation" must occur. Telnet option negotiation is used to decide which protocols the client and server support. Once a specific telnet option has been agreed upon, they can exchange information using the appropriate telnet option subnegotiation for that telnet option.
Tinyfugue has several basic telnet options hardcoded in its source code. Tinyfugue sends back a negative response when it does not recognize a telnet option. Telnet option negotiation must occur before telnet option subnegotiation can exchange data. Since Tinyfugue responds negatively to all unknown options, it is not possible to begin exchanging data through telnet subnegotiation. Updating the source code to recognize GMCP, ATCP, and AARD (102) telnet options is easy. However, updating the source code for these specific options does not provide a generic method for dealing with other protocols that be created in the future.
One method for solving this issue is to provide Tinyfugue hook events (like the ICONFAIL and SEND hooks) for the several stages of telnet negotiation. With those telnet option hooks in place, the end user would have the ability to accept or deny arbitrary telnet options from servers. Having control over arbitrary telnet options allows the end user to respond to options that are currently in use, and also support options that may come in to use later.
Tinyfugue has a framework for telnet option subnegotiation that is currently used for MCCP, NAWS, and terminal type negotiation. Telnet option subnegotiation has a very generic format. All telnet option subnegotiation messages begin with "IAC SB XX" (255 250 XX) where XX is the telnet option identifier (GMCP uses 201, ATCP uses 200, AARD uses 102, etc). After that byte sequence, the data is sent in whatever format is specified by the protocol documentation (for example GMCP uses JSON formatted messages). Finally, "IAC SE" (255 240) is sent signifying the end of the data. This generic format for telnet subnegotiation means that when Tinyfugue receives a subnegotiation message from the server it is easy to pass the data to the end user for manipulation. The telnet option ID and subnegotiation data could be provided through the use of a Tinyfugue hook.
Providing hooks for telnet option negotiation and subnegotiation only solves half of the problem. The end user also needs to be able to respond to the telnet option negotiation request. It does not help the end user to know that the server is requesting the GMCP telnet option when the end user cannot reply back to the server. The same issue applies to telnet option subnegotiation. In particular, newer telnet subnegotiation options (such as GMCP) allow the end user to request information about the MUD server through client initiated subnegotiation messages. The solution to this half of the problem is to provide a set of commands that can send telnet commands back to the server.
A small set of specialized Tinyfugue functions could be created in order to allow the end user to send telnet commands. There would be a minor issue with using these specialized functions because most telnet commands use byte arrays. End users need the ability to provide some information (such as the telnet negotiation option ID) in the form of numbers or bytes, but other information as normal text (such as the JSON data for GMCP). Also, the functions must be generic enough to allow the input of data for any protocol that might be implemented in the future.
One way to solve the issue of specialized functions with generic or unknown requirements would be to modify Tinyfugue's Send function to accept raw telnet data using a new command switch (such as -r for raw). If that command switch was available, then it might be possible to create Tinyfugue script libraries that are able to correctly respond to current telnet options. When new telnet options become available, new script libraries could be created without the need to edit Tinyfugue's source code.
Thus Tinyfugue currently needs a set of hooks for telnet option negotiation and telnet option subnegotiation and a command or commands used to respond (and initiate) those same items. Once all of those pieces are in place, libraries for telnet options like GMCP, ATCP, and AARD (102) can be created through Tinyfugue scripts.
Subscribe