Skip to content

Negotiating Progressive Enhancements

Robin Verhagen-Guest edited this page Mar 17, 2019 · 37 revisions

Introduction

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.

Negotiation Commands

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.

NEW-ENVIRON Option

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.

Subcommand Escaping

  • If an IAC is contained between the IS and the IAC SE, it must be sent as IAC IAC.
  • If a variable or a value contains a VAR, it must be sent as ESC VAR.
  • If a variable or a value contains a USERVAR, it must be sent as ESC USERVAR.
  • If a variable or a value contains a VALUE, it must be sent as ESC VALUE.
  • If a variable or a value contains an ESC, it must be sent as ESC ESC.

Progressive Enhancement Commands

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.

Example of a Successful Negotiation

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  
Client: IAC WILL NEW-ENVIRON ; Express willingness to send vars to server

Server may ignore 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   
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  

If server sends 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  
    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  

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.

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  
    ; Client confirms newly issued GUID   
    USERVAR "GUID" VALUE "98897F57-4815-42D2-BAE5-39950D6A30BB"  
IAC SE  

If the client fails to confirm issued 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   
    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 

Then server sends page.

Later, server disables Date and Time:

Server: IAC SB NEW-ENVIRON INFO  
    USERVAR "Date" ; Stop displaying date until further notice   
    USERVAR "Time" ; Stop displaying time until further notice    
IAC SE  

Then server sends page.

You can’t perform that action at this time.