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. **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** of Addendum 1