This page has been accessed 442 times.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. A. Version 3.3.0 and earlier: TRANS username password description B. Version 3.3.1 and later: TRANS username password level description (+) 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. Because prompts require a line to be sent without a newline, and because the current netlink protocol requires commands to be preceded by a newline, including the EMSG command, such prompts cannot be supported under NUTS 3.x without modifications to the code. This can be solved simply and maintain backwards compatibility by adding a hidden character in the output of functions that actually send prompts, and modifying the code that sends the text to users in such a way so as to intercept that, and do one of three things: A. If the user is a local user, since the hidden character is at the end of the line, replace it with a NULL (or possibly a space, at the discretion of the person implementing this RFC). B. If the user is a remote user via a link from a NUTS 3.3.3 talker, replace it with a newline. C. If the user is a user of the extended implementation, leave it as-is. In cases B and C, the string would obviously be followed by EMSG\n. This also requires an addition to the basic code for intercepting commands. In addition to checking for these commands after newlines, it must check for them after the hidden character. Due to possible differences in implementation, the hidden character (most likely a control character) is not specified in this RFC. However, the method for exchanging this information is explicitly stated in section 7, and must be followed. 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. 8. Negotiation of options: A. 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. B. 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. EXTCMDMODE=* -- Specify the maximum extended command mode level supported. Level 1 indicates control code support before commands. Additional levels may be proposed and defined in future RFCs. WONT_EXTCMDMODE is undefined. Proper procedure is to send the highest mode supported. A typical exchange is T1: WILL_EXTCMDMODE=9 T2: DO_EXTCMDMODE=4 (this means that the second talker requests a lower mode. The DO request from the second talker must be honored and the first talker must limit itself to the lower level of EXTCMDMODE. While this is irrelevant with only one mode defined, it will provide a means for defining levels of general link commands in future RFCs other than requesting each one individually with WILL/WONT/DO. Compliance with a level is defined as complete compliance with all features of that level. No partial compliance is defined in this RFC. Unmodified NUTS 3.3.3 talkers (i.e. talkers without these RFC extensions) may either be treated as non-compliant (EXTCMDMODE=0) or may be treated as Level 1 compliant, but with \n as the control code (see recommended variable support below). Note however, that additional steps should probably be taken if they are treated as level 1 compliant in this manner to avoid allowing users to use commands that require *true* level 1 compliance. SENDUSERINFO -- This indicates compliance with the user info information that may be sent when a user logs in. The format for this information is described in item 10 (below). 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. Recommended variable support: ATTNCHR=## -- This is required for support of all EXTCMDMODE levels >=1. If EXTCMDMODE=0 (unlikely), this can be ignored, or may optionally be assigned the ASCII value of \n for safety reasons. Note that this value is expected to be an unsigned integer representing the ASCII value of the desired character on data coming into a talker. Each talker must respect the desire of the other talker in this manner. If a talker does not send this value, it may be assumed to be control-a (ASCII 01). However, to be fully RFC-compliant, a talker *must* send a request for this variable assignment. 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. In the current implementation, user information cannot be exchanged. This capability is optional, but is highly recommended, as it is the final key to the flexibility of the extended netlink protocol. To recap, in the original netlink protocol, the syntax was TRANS username password [level] description. The proposed extension involves removal of all information except username and password from the command, and adding an additional command, TRANSEND. Syntax is: TRANS username password\n variable1=value\n variable2=value\n . . TRANSEND\n where the periods represent any number of variables. When multiple variable definitions are placed on a single line, then must be separated by a space. Like SET-style options in the initial connection negotiation, strings containing spaces must be enclosed in double quotation marks (""), and numbers should only be enclosed in double quotation marks if they are to be interpreted as strings. Single- word strings may be enclosed in double quotation marks, but this is not required. Caveats: TRANSEND must be on a separate line unless the system supports EXTCMDMODE >=1, in which case, it may be preceded by the appropriate attention character as defined in the variable ATTNCHR above. 11. A word on capitalization: *ALL* commands in the netlink protocol must be capitalized. The same goes for any extended commands. This practice should continue. However, it is suggested that you allow commands of any case (through judicious use of toupper() in a loop), especially if you are writing an implementation of this RFC from scratch, as opposed to basing it on NUTS 3.3.3's existing code. *ALL* terminal types should be in lowercase. Any implementation of this code should be able to handle terminal type names regardless of their case, however. 12. A formal name for this protocol is needed. Until a better name is suggested, the working name is Talker NetLink+. A better name would use a more generic term than talker, however, as this protocol could be added to other multi-user server programs, such as MUDs, etc. 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 and suggestions? Send mail to dgatwood@globegate.utm.edu.