In its initial form, the NXtel server uses a standard legacy Prestel protocol, suitable for connecting to with legacy videotex programs, and modems running at 2400 baud.
However, some clients (including the NXtel Next client) may support more advanced features. This support is established with the server using the telnet option negotiation protocol, using out-of-band messaging. The benefit of using this protocol is that non-enhanced/legacy clients and servers still behave as expected if negotiations fail.
Telnet option negotiation is specified fully in RFC 855. For convenience, the option tokens described in the rest of this document are summarised here:
| Token | Value | Description |
| ----- | -----:| ------------------------------------------ |
| IAC | 255 | Marks the start of a negotiation sequence. |
| WILL | 251 | Confirm willingness to negotiate. |
| WONT | 252 | Confirm unwillingness to negotiate. |
| DO | 253 | Indicate willingness to negotiate. |
| DONT | 254 | Indicate unwillingness to negotiate. |
| NOP | 241 | No operation. |
| SB | 250 | The start of sub-negotiation options. |
| SE | 240 | The end of sub-negotiation options. |
| IS |0 | Sub-negotiation IS command. |
| SEND |1 | Sub-negotiation SEND command. |
Note that, unlike the 7-bit videotex protocol which escapes and encodes bytes larger than 127, telnet commands, options and subcommands are always sent as 8-bit values. However, telnet subcommands are separately escaped.
The NEW-ENVIRON telnet option is used to transmit arbitrary key/value data pairs. NXtel-compatible clients and servers use this option to negotiate progressive enhancements.
NEW-ENVIRON is specified fully in RFC 1572. For convenience, the option tokens described in the rest of this document are summarised here:
| Token | Value | Description | | ----------- | -----:| ----------------------------- | | NEW-ENVIRON | 39 | Environment variables. | | IS | 0 | Sub-negotiation IS command. | | SEND | 1 | Sub-negotiation SEND command. | | INFO | 2 | Sub-negotiation INFO command. | | VAR | 0 | NEW-ENVIRON command. | | VALUE | 1 | NEW-ENVIRON command. | | ESC | 2 | NEW-ENVIRON command. | | USERVAR | 3 | NEW-ENVIRON command. |
IAC is contained between the IS and the IAC SE, it must be sent as IAC IAC. VAR, it must be sent as ESC VAR. USERVAR, it must be sent as ESC USERVAR. VALUE, it must be sent as ESC VALUE. ESC, it must be sent as ESC ESC. The following NEW-ENVIRON USERVAR variables are used as progressive enhancement negotiation commands:
| Variable | Sent By Server | Sent By Client | Description |
| -------- |:--------------:|:--------------:| ---------------------------------------------------------- |
| RTC | | Yes | Enables date/time/year dynamic display from the client's Real Time Clock. |
| Date | Yes | | Tells RTC-enabled client where to display date. |
| Time | Yes | | Tells RTC-enabled client where to display time. |
| Year | Yes | | Tells RTC-enabled client where to display year. |
| DOM | | Yes | Tells server what the local Day Of Month is. |
| DOW | Yes | | Tells client what the Day Of Week is for the requested DOM. |
| GUID | Yes | Yes | Used to establish persistent anonymous client identification without storing IP addresses on the server. |
Upon initial connection, the server will never talk telnet protocol or initiate progressive enhancement negotation.
To initiate, the client may send this:
Client: IAC DO SUPPRESS-GO-AHEAD ; Tell server not to throttle replies for legacy modems
Client: IAC DO NEW-ENVIRON ; Express willingness to receive vars from server
Server may ignore
Client: IAC WILL NEW-ENVIRON ; Express willingness to send vars to server
SUPPRESS-GO-AHEAD, or choose to continue to throttle replies. Conversely, if the client doesn't send SUPPRESS-GO-AHEAD, replies still might not be throttled. Server may choose not reply with WILL or WONT even if acting on the command. This enhancement is specified in this loose form for TELSTAR compatibility.
In reply:
Server: IAC WILL NEW-ENVIRON ; Confirm willingness to send vars to client
If server sends
Server: IAC DO NEW-ENVIRON ; Confirm willingness to receive vars from client
Server: IAC SB NEW-ENVIRON SEND USERVAR IAC SE ; Request all uservars from client
WONT instead of WILL or fails to reply, client must send no further NEW-ENVIRON requests for variables.
If server sends DONT instead of DO or fails to reply, client must send no further NEW-ENVIRON variables.
In reply:
Client: IAC SB NEW-ENVIRON SEND USERVAR IAC SE ; request all uservars from server
Client: IAC SB NEW-ENVIRON IS
Note that delimiting quotes are used in this document to denote literal strings. However, ASCII quote characters are not sent by the server or client.
USERVAR "RTC" VALUE "1" ; Client has an RTC
USERVAR "DOM" VALUE "16" ; Today is 16th day of month
; Client has this stored GUID
USERVAR "GUID" VALUE "4FE6C154-2025-4E5B-8460-706C85CB7D33"
IAC SE
RTC=1 causes server to send Date, Time, Year changes as the page layout requires. All three are in zero-padded NNN format, where NNN equals X+(Y*40) and X and Y are the zero-based coordinates to display the variable at.
Client is expected to display Date in ddd dd MMM format, Time in HH:mm:ss format, and Year in yyyy format. Format variations may be made by the client provided the widths remain the same, with space padding if necessary.
Server will no longer pre-populate Date, Time or Year with server timezone values until RTC=0 is sent by the client.
When server sends Date, Time or Year with no VALUE, client is expected to suppress display until a VALUE is later sent.
DOM (day of month in NN format) causes server to immediately send the corresponding DOW (day of week Sun=0..Sat=6). If close to midnight in the client timezone, the client must adjust DOW based on the timestamp when DOM was sent. If server and client are more than 1 day apart, client may make best guess or suppress DOW display.
Client sends the stored GUID it has for this server (if it has one). Note that clients are never expected to generated GUIDs, this is always done by the server. The client may choose to store GUIDs sent by the server, or ignore them completely.
In reply, before Welcome page:
Server: IAC SB NEW-ENVIRON IS
USERVAR "Date" VALUE "864" ; Client should display date at coordinates 24,21
USERVAR "Time" VALUE "831" ; Display time at 31,20
USERVAR "Year" VALUE "875" ; Display year at 35,21
USERVAR "DOW" VALUE "7" ; DOW for DOM 16 is Saturday
; Server hasn't seen client GUID, issues this GUID instead
USERVAR "GUID" VALUE "98897F57-4815-42D2-BAE5-39950D6A30BB"
IAC SE
In reply:
Client: IAC SB NEW-ENVIRON IS
If the client fails to confirm issued
; Client confirms newly issued GUID
USERVAR "GUID" VALUE "98897F57-4815-42D2-BAE5-39950D6A30BB"
IAC SE
GUID, or confirms a different one, server may later prune the issued GUID.
If the client confirms the server GUID, server may mark it as used, which may prevent later pruning.
After waiting for a short timeout in which no further client IAC commands are received, the server sends the Welcome page (which includes date, time and year).
Norml non-enhanced communications proceed from here. The server will wait for keystrokes from the client, match them to routes from the current page, and send a new page when there is a match.
Later, server repositions Date and Time, and disables Year:
Server: IAC SB NEW-ENVIRON INFO
Then server sends page.
USERVAR "Date" VALUE "008" ; Display date at 0,8
USERVAR "Time" VALUE "033" ; Display time at 33,0
USERVAR "Year" ; Stop displaying year until further notice
IAC SE
Later, server disables Date and Time:
Server: IAC SB NEW-ENVIRON INFO
Then server sends page.
USERVAR "Date" ; Stop displaying date until further notice
USERVAR "Time" ; Stop displaying time until further notice
IAC SE