NUTS NetLINK pseudo-RFC #1 This is a pseudo-RFC. It is not as formal as an actual RFC. Replies should be directed both to the original author and the newsgroup, where possible, due to inconsistend USENET delivery (esp. to the author's semi-local news server). In this pseudo-RFC, the author of this document proposes a superset of the NUTS Netlink protocol, with full backwards compatibility, but providing additional functionality. Before one can propose changes, additions, etc., one must first attempt to interpret the original protocol. Below is a list of the basic NetLINK commands to the best of my knowledge, as interpreted from the source code. Commands and basic function: + indicates required items (*) DISCONNECT -- polite talkers should send this before closing down a connection to another talker's netlink port. If no disconnect is received, an error message may be displayed. Handling this command when received is only necesary if an error message is displayed when the connection is lost unexpectedly. Usage: DISCONNECT\n (+) TRANS -- this is used when a used logs in via netlink. Usage: varies by version (see above) (+) REL -- this releases a user login... Usage: REL username\n (+) ACT -- this executes a command, may be disabled if you only want to allow speech and no motion or anything, though that's rather cruel. Usage: ACT username action[]\n (+) GRANTED -- sent when permission for a user to login is granted, Usage: GRANTED username\n (+) DENIED -- A. "DENIED CONNECT #" indicates you aren't allowed to connect your site to a remote site in the initial negotiation or the remote host refused for other reasons. A list of these numbers is provided below. B. "DENIED username #" means a user login was denied. Reasons for "DENIED CONNECT": 1 -- not in valid sites list 2 -- unable to create netlink object (out of memory) 3 -- no room had an available slot for inbound link ("no free room links."). Reasons for "DENIED username": 1 -- (not reused from above) 2 -- (not reused from above) 3 -- (not reused from above) 4 -- link for incoming/outgoing users only (opposite of what user is attempting) 5 -- user already logged in (at remote site) 6 -- A. out of memory creating user object -- only useful if uses dynamically allocated user structs. B. ver<3.3.3 may also return this for banned users and users below minlogin (when sending to older talkers, both conventions should be honored, by version number). 7 -- incorrect password (for valid local users) 8 -- A. login level below minlogin -- nuts 3.3.3 and up only, else use 6. B. request for action by user not logged in. 9 -- user banned -- nuts 3.3.3 and up only, else use 6. (+) MSG -- indicates beginning of text to be send unprocessed. Usage: MSG username\n(body of message)EMSG\n (+) PRM -- requests that user's originating site display a prompt. Usage: PRM username\n (+) VERIFICATION -- sent by client to tell server _its_ version info, etc. Usage: VERIFICATION password version\n, where password is the password for the netlink connection and version is a dotted triple, like 3.3.3.... (+) VERIFY -- response to VERIFICATION. Usage: VERIFY OKAY *\n, where * is IN, OUT, or ALL. (+) REMVD -- sent by remote host to originating site to indicate that the user has used go to return to originating site or has been kicked off the remote host. Usage: REMVD user\n (+) EXISTS? -- sent to request verification of a user before sending mail. Responses are EXISTS_YES and EXISTS_NO EXISTS_NO -- user does not exist EXISTS_YES -- user exists Usage: EXISTS? to from\n, where "to" is verified, and returned to from. Returns: EXISTS_* to from\n, in a like fashion (+) MAIL -- indicates start of a mail message for remote delivery Usage: MAIL to from\n (+) ENDMAIL -- indicates end of a mail message Usage: ENDMAIL\n (+) MAILERROR -- indicates an error occurred in mail delivery Usage: MAILERROR to from\n (*) KA -- keepalive message -- may be ignored when received or used to determine whether a netlink is working or not, but must be sent every so often, which may depend on the remote host -- the remote host can't disconnect in less than 300 seconds, according to the comments in the sources. Dunno why. I'd say doing it in an alarm-based signal handler every 30 seconds or so should pretty much keep other talkers happy. :-) Usage: KA\n (-) RSTAT -- remote statistics - if not supported, it should at least send a response along the lines of "MSG username\n Not supported\nEMSG\n" since it's assumed that any 3.3.3 or newer talker supports this. Usage: RSTAT username\n NOTES AND CHANGES: 1. In the current implementation, if I read this correctly, a user cannot be moved into a netlink. I'm not sure why. This should be easily changable. 2. In the current implementation, a user can only navigate to a host, not through it to another one, simply because the same pointer is used for a user's incoming and outgoing netlink pointers. This can and should be changed in the new implementation, especially if it is coded from scratch. 3. Some commands ending in look(u) might require code added to send "ACT username look" along the line if that user were not local. Since this should only be move commands, in all likelihood, this is irrelevant. 4. Someone needs to look into the prompt command and find out why the source says that line eds and stuff can't be used over the link and fix the problem, if possible (and if it still exists). This is, however, trivial, and changes to this would not have a significant effect on this RFC, except insofar as they add additional things to negotiate. 5. Given that NUTS 3.x uses version numbers to determine the features supported by a remote host's netlink system, care should be taken to preserve compatibility with older versions by keeping the same basic checks. However, this superset would denote a newer version. Since there is a possibility that, at some point in the future, the author of NUTS might release a NUTS 4, and since other talkers on the net use version numbers in different ways, care should also be taken to _not_ use a version number for determining compatibility with the extended feature set proposed in this pseudo-RFC. The easiest way to get around the version problem without creating an unusual version number (i.e. 3.3.36 or 90.3.3) is to use the version number "3.3.3+". This will be interpreted by the standard implementation as 3.3.3, while the + would still be part of the same %s in an sscanf instruction, making it easily identifiable in this new RFC implementation. 6. The MAILERROR command should be expanded for systems with extended feature support, to return a short message telling the nature of the error. Thus, the new usage would be "MAILERROR to from # string\n", where # would be an error number that could be converted into a standard message by the sending mail progrm, and string could be additional details about why this differs from the normal meaning of the standard message, if any, otherwise, the string would end after the number. Older implementations _should_ ignore the rest of the string anyway, but only outputting the extra stuff for the hacked versions wouldn't be a bad idea.... 7. The current NUTS 3.3.3 implementation appears to leave the possibility of referencing a destroyed netlink object by using a for loop. While not necessarily life-threatening, if this possibility indeed exists, this should be avoided in in this implementation and corrected in the NUTS 3.3.3 implementation. 8A. This implementation will include a telnet-like negotiation system, used only when receiving a connection from a compatible system. Upon detection of a NUTS version ending in a '+' (i.e. extended feature support), the following negotiation is suggested: After receiving NUTS 3.3.3+ ...\n send: NEGOTIATE option1 option2 option3 option4 option5\n and as many sets as necessary of: expect: NEGOTIATE counteroption1 counteroption2\n send: NEGOTIATE counteroption1 counteroption2\n until you receive one of the following: A. NEGOTIATE OK\n B. a set of options you can live with send: VERIFICATION password version\n The idea is to do something along the lines of the telnet protocol, in which one computer says will_ansi and the other system either says do_ansi or wont_ansi. Alternately, the computer may not respond to one of the protocol requests, instead asking, say, will_vt100 and if the other one says wont_vt100, then responds wont_ansi. Chances are, the negotiation will be fairly simple. It should remain short enough that the other users on either talker don't notice the delay. 8B. Mandatory negotiation capabilities: any unknown capability requests should return a wont_*. Some capabilities should be handled, and are thus listed as required capabilities in this RFC. In the interest of readability, the initial WILL/WONT/DO prefix is left off. TERMINAL=* -- if nothing else, TERMINAL=tty must be accepted. Other terminal types may be negotiated if your implementation supports something other than tty (i.e. vt100, vt100-ansi) Note that typically, this transaction is as simple as S: WILL_TERMINAL=vt100 R: DO_TERMINAL=vt100. If nothing else works, tty can always be used as a baseline. All terminal types should be in lowercase letters (although implementations can certainly check and correct this if they receive uppercase letters, this is left at the discretion of those creating the implementation). COLOR -- whether to support ANSI color. This is distinct from terminal, in that a terminal can technically support the b/w ansi extensions such as boldface, underline, and inverse without supporting foreground and background color modes. GRAPHICS -- if the user's terminal program supports ANSI graphics mode. If your talker has no support for ANSI graphics mode, it should always respond WONT_GRAPHICS. REMPROMPT -- if your talker supports remote prompt() extensions. This is subject to whether such extensions are necessary and non-backwardly-compatible. CHARMODE -- if your talker supports a direct character mode transfer of data to the remote talker. Again, support for this may be limited to WONT_CHARMODE. Additional required parameters not beginning with WILL/WONT/DO are: SET var=* -- assigns a particular variable a given value. Multiple word values must be enclosed in double quotes (""). Example: SET delete=255 sends the character code number for delete as used by the local talker. This is provided for CHARMODE, and the value may be ignored. SET may be used in both outgoing and incoming negotiation, however, it may not be challenged. Items requiring challenges should use the WILL/WONT/DO construct. Syntax requirements: numbers must be in base 10. Strings must be enclosed in double quotation marks ("") if they contain whitespace. Shorter strings *may* be enclosed in double quotation marks, at the discretion of the remote host, and the local host must handle this case properly. Numbers enclosed in double quotation marks will be treated as a string. Strings beginning with a number must be enclosed in double quotation marks. Any double quotation marks used within a string must be quoted by a backslash (\). A backslash used within a string must also be quoted by a second backslash, to prevent it from being interpreted as a quoting character (i.e. '\\' == '\' and '\"' = '"'.) Required variable support: SALT=* -- This will be sent by both hosts to the other, indicating the required SALT to be used in sending encrypted passwords over the link connection. A value of "**" means that the salt will be the first two characters of the user's login name, case sensitive. A value of "*!" means that the salt will be the first two characters of the user's login name, converted to upper case. A value of "*#" means that the salt will be the first two characters of the user's login name converted to lower case. All other values will be used as the salt for the crypt() function. 9. Implementation: if a given talker has no say or .say command, that must be gotten around. Beyond that, user commands preceded by "ACT username" should be treated as commands. Most other commands are self-explanatory. The means for handling unknown remote users without actually creating a local user with that name is left as an exercise for the implementing person within a given architecture, and is beyond the scope of this RFC. That having been said, the easiest solution would be to have a user type number, which if equal to NETLINK_USER or some such number, would not get saved. A similar type field exists within NUTS 3.3.3. 10. Finally, I'd like to propose that this superset be called Talker NetLink+, from the + used to denote compatibility. This pseudo-RFC was written by David A. Gatwood, a student at the University of Tennessee at Martin. For more information, comments, etc., send electronic mail to dgatwood@globegate.utm.edu. ----------------------- END OF pseudo-RFC ----------------------- Comments?