NUTS NetLINK Extended Prototol Pseudo-RFC #1
David A. Gatwood
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 dgat...@globegate.utm.edu.
----------------------- END OF pseudo-RFC -----------------------
Comments?
David
David A. Gatwood
The following realizations hit me a few hours after sending the initial
RFC:
1. The prompt problem, as far as I can tell, is due to the inability
of the protocol to handle netlink commands unless they are
preceded by newlines. (Correct me if there are other reasons.)
2. The proposed protocol has no means for sending user options other
than level (such as terminal type).
3. I mistakenly left off the syntax for TRANS (when I moved the
pseudo-RFC to a separate message).
The following are proposed changes to the RFC to correct these
oversights. A version of the RFC with these changes already made
is available on the web at:
http://globegate.utm.edu/~davagatw/nutsrfc
and will be maintained (possibly with some additional related pages) as
suggestions and changes are made. Any major changes will also reflected
here on a.t.p, in the form of addenda like this one, provided there are no
radical changes.
-------------------- BEGIN ADDENDUM #1 --------------------
A. **REPLACE** item "TRANS" in section "Commands and basic function" with:
(+) 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
B. **REPLACE** item 4 in NOTES AND CHANGES with:
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.
C. **ADD* to item 8B in NOTES AND CHANGES (additional mandatory negotiation
capabilties based on WILL/WONT/DO
construct):
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).
D. **ADD** to end of item 8B in NOTES AND CHANGES:
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.
E. **REPLACE** item 10 in NOTES AND CHANGES with:
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.
F. **ADD* the following items after item 10:
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.
-------------------- END ADDENDUM #1 --------------------
David
dgat...@globegate.utm.edu
neil_at_ogham_dot_demon_dot_co_dot_uk
"David A. Gatwood" <dava...@globegate.utm.edu> wrote:
>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.
Moved *into* a netlink? Huh?
>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.
Allowing multiple traversals is far from being as simple as doing that
quick change. If it was I'd have done it myself. Once you allow multiple
traversals you have to start worrying about how to route mail through
intermediate systems (and how to route the status replies or errors back) how
to deal with a system somewhere along the chain going down and how to deal
with the inevitable lag which will occur if someone has hopped across quite a
few systems. Not worth the effort IMHO.
>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
Good idea.
>COLOR -- whether to support ANSI color. This is distinct from
How about allowing COLOUR too? Being english I prefer the english spelling :)
>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
Not that simple. See my other post.
>10. Finally, I'd like to propose that this superset be called Talker
>NetLink+, from the + used to denote compatibility.
Bit uninspired. How about a competition for something better?
Heres some of my ideas (I like acronyms Btw :):
TALIP (TAlker LInk Protocol)
GALLUP (Generic/General tAlker Live Link Up Protocol)
EXNET (EXtended NETlink)
NU-NET+ (NUTS NETlink)
Any other offers?
NJR