for this purpose. They are based heavily on the Telnet
negotiation and subnegotiation mechanisms. For simple
negotiations there are two parameters, a negotiation type
(from the set {DO, DONT, WILL, WONT}) followed by the code
(numeric) or name (symbolic) for the desired option. The
codes for the options are identified below. A basic
difference between the H-FP interface to Telnet and the
internal Telnet protocol is that additional parameters are
included with the request (DO or WILL). The Telnet protocol
subnegotiation is used internally to communicate that
information in the Telnet data stream. Option-specific,
protocol-idiosyncratic parameters are used for these
additional parameters.
Both the Host and the OPE can issue these Condition
commands. When issued by the Host, it means the user wishes
to enable or disable a particular option. The OPE proceeds
to issue the appropriate negotiation commands (i.e., IAC
<DO> <code>) in the Telnet data stream. When the results of
the option negotiation are available, a response is
generated by the OPE. For the types DO and WILL, a 000
Response indicates the appropriate acceptance (WILL or DO,
respectively). A nonzero Response code may indicate
negotiation failure or negotiation rejection (among other
things). For the types DONT and WONT, a 000 Response
indicates the option will be disabled. A negotiation
rejection should not be expected in those cases.
When the Condition command is issued by the OPE, it means
the other end of the connection is negotiating a change.
Here the response from the Host indicates the Host's desired
action for the option negotiation. Again, valid requests to
disable options (DONT and WONT requests) should always get a
000 Response.
2.3.2. Protocol-Idiosyncratic Parameters
There are two protocol-idiosyncratic parameters for primary
negotiation using the Condition command. These are the
negotiation type and the option code. The negotiation type
is one of the set of {DO, DONT, WILL, WONT}. The option
code is a numeric value used to identify the particular
RFC929 December 1984
Proposed Host-Front End Protocol
option being negotiated. The values for these codes are
indicated here, but are identical to the codes used in the
actual Telnet negotiation. The codes are:
Option Name Option Code Short Name
Transmit Binary 0 Binary
Echo 1 Echo
Suppress Go-Ahead 3 SuppressGA
Approximate Message Size 4 NAMS
Status 5 Status
Timing Mark 6 TimingMark
RCTE 7 RCTE
Line Length 8 LineLength
Page Size 9 PageSize
Carriage Return Disp 10 CRDisp
Horizontal Tabstops 11 HTabStops
Horizontal Tab Disp 12 HTabDisp
Formfeed Disposition 13 FFDisp
Vertical Tabstops 14 VTabStops
Vertical Tab Disposition 15 VTabDisp
Linefeed Disposition 16 LFDisp
Extended ASCII 17 ExASCII
Logout 18 Logout
Data Entry Terminal 20 DET
Terminal Type 24 TermType
Extended options list 255 ExOptions
Options not listed here may of course be used. The code
number should be the same as the option code used in Telnet
negotiation.
2.3.2.1. Simple Options
Options that do not require additional parameters use the
simple negotiation mechanisms described briefly above and
in greater detail in the Telnet documentation. No
additional parameters are required. These options
include the Transmit Binary, Echo, Suppress Go Ahead,
Status, Timing Mark, and Logout options.
2.3.2.2. Approximate Message Size Option
The Approximate Message Size option requires two
parameters. The first indicates whether the approximate
message size being negotiated applies to the local or the
remote end of the connection. DS means the size applies
RFC929 December 1984
Proposed Host-Front End Protocol
to the sender of the command (i.e., if the Host issues
the command, DS means the local end of the connection;
if issued by the OPE, DS means the remote end of the
connection). DR means the size applies to the receiver
of the command (i.e., if the Host issues the command, DR
means the remote end; if issued by the OPE, DR means the
local end of the connection). This convention is
consistent with the Telnet subnegotiation mechanisms.
The second character is an ASCII encoded numeric value,
which is a character count of the message size.
2.3.3. Line Width and Page Size Options
The Line Width and Page Size Options require two additional
parameters. The first indicates whether the line width or
page size being negotiated applies to the local or the
remote end of the connection, and uses the DS and DR
convention described above. The second parameter is an
ASCII encoded numeric value, which is interpreted as follows
(assuming the Condition command was issued by the Host):
0 The Host requests that it handle length or size
considerations for the direction indicated by
the first parameter.
1 to 253 The Host requests that the remote end handle
the size or length considerations for the
direction indicated by the first parameter, but
suggests that the value indicated be used as
the size or length.
254 The Host requests that the remote end handle
the size or length considerations for the
direction indicated by the first parameter, but
suggests that the size or length be considered
to be infinity.
255 The Host requests that the remote end handle
the tabstop considerations, and suggests
nothing about what the value should be.
If the Condition command is issued by the OPE, then the
roles of the Host and the remote end are reversed.
RFC929 December 1984
Proposed Host-Front End Protocol
2.3.4. Tabstop Options
The Horizontal and Vertical Tabstops options require two
option specific parameters. The first is either DR or DS,
as was described previously. The second is a list of one or
more ASCII encoded numeric values separated by spaces which,
assuming the Condition command is issued by the Host, are
individually interpreted as:
0 The Host requests that it handle tabstops for
the direction indicated by the first parameter.
1 to 250 The Host requests that the remote end handle
the tabstop considerations for the direction
indicated by the first parameter, but suggests
that the value(s) indicated should be used as
the tabstops.
255 The Host requests that the remote end handle
the tabstop considerations for the direction
indicated by the first parameter, and suggests
nothing about what the value should be.
If the Condition command is issued by the OPE, then the
roles of the Host and the remote end are reversed.
2.3.5. Character Disposition Options
The Carriage Return Disposition option, the Horizontal Tab
Disposition option, the Formfeed Disposition option, the
Vertical Tab Disposition option, and the Linefeed
Disposition option are all considered character disposition
options from the perspective of H-FP. Two option-specific
parameters are required for the character disposition
options. The first is the DR or DS code, which was
described previously. The second is a single ASCII encoded
numeric value, which is interpreted as (assuming that the
Host issued the Condition command):
0 The Host requests that it handle the character
disposition for this connection.
1 to 250 The Host suggests that the remote end handle
the character disposition considerations, but
suggests that the value indicated should be
taken as the number of nulls which should be
RFC929 December 1984
Proposed Host-Front End Protocol
inserted in the data stream following the
particular format character being
subnegotiated.
251 The Host suggests that the remote end handle
the character disposition considerations, but
recommends that it replace the character with
some simplified character similar to but not
identical with it (e.g., replace a tab with a
space, or a formfeed with a newline).
252 The Host suggests that the remote end handle
the character disposition considerations, but
recommends that it discard the character.
253 The Host suggests that the remote end handle
the character disposition, but recommends that
the effect of the character be simulated using
other characters such as spaces or linefeeds.
254 The Host suggests that the remote end handle
the character disposition considerations, but
recommends that it wait for additional data
before sending more data.
255 The Host suggests that the remote end handle
the tabstop considerations, and suggests
nothing about what the value should be.
Some of the codes between 251 and 254 are not used with some
character disposition options. Refer to the ARPANET
documentation for additional details.
If the Condition command is issued by the OPE, then the
roles of the Host and the remote end are reversed.
2.3.5.1. RCTE Option
The Remote Controlled Transmission and Echoing option
requires parameters to indicate the sets of break
characters and transmit characters. There are two
option-idiosyncratic parameters for RCTE. The first is a
list of the character classes that make up the set of
break characters, as defined in the RCTE documentation.
The second is a list of character classes that make up
the set of transmit characters, as defined in the RCTE
documentation. Since the two classes are optional and
RFC929 December 1984
Proposed Host-Front End Protocol
can be of arbitrary length, it is necessary to precede
each list with a -bc (break characters) or -tc (transmit
characters). The character classes are defined as
1 Upper Case Letters A through Z
2 Lower Case Letters a through z
3 Digits 0 through 9
4 Format effectors <BS> <CR> <LF> <FF> <HT> <VT>
5 Non-format control codes, plus <ESC> and <DEL>
6 Punctuation . , ; : ? !
7 Grouping { [ ( < > ) ] }
8 Misc ' ` " / \ % @ $ & + - * = ^ _ | ~
9 <space>
2.3.5.2. Extended Option List
The Extended Option List option requires a parameter to
carry the number of the option on the extended list.
There is thus one option specific parameter to the
Condition command when used for this purpose, which is
the number of the option on the extended option list. It
can be expressed in ASCII using an octal, decimal, or
hexadecimal format.
2.3.5.3. Terminal Extension Options
The Extended ASCII, SUPDUP, and Data Entry Terminal
options of Telnet were all attempts to extend the basic
capabilities of the Telnet data stream beyond the simple,
scroll mode terminal model that was the basis of the
original Telnet design.
All of these options have limitations to their
effectiveness. The Extended ASCII option lacks a
standardized interpretation of the bit patterns into
extended ASCII characters. The SUPDUP effort was
actually an independent mode where a different virtual
terminal protocol was used, and the option was there
merely to switch to and from this protocol. The Data
Entry Terminal option requires the excessive overhead of
subnegotiation for each use of extended features. All of
these options lack the more valuable asset of widespread
implementation and use.
The way these options should be handled is not detailed
in this appendix. It is clear that the Condition command
could be used for initiating and terminating the use of
RFC929 December 1984
Proposed Host-Front End Protocol
these options. The actual transmission of characters
related to the extended terminal features should be
provided by the Transmit command, either as part of the
normal Host-to-OPE data stream or by using
protocol-idiosyncratic parameters.
A more recent option, the Terminal Type option, should be
mentioned here. It permits one end of a connection to
request information about the terminal at the other end
or send information about the terminal at the local end.
This is convenient for systems that provide a wide
variety of terminal support, but it clearly does not
follow the model of reducing the MxN problem by use of a
virtual terminal. Its use is very straightforward in the
H-FP context. It only requires sending the terminal type
to the other end, and activating the Binary Transmission
Option.
2.3.5.4. Status Option
The Status option is enabled using the negotiation
mechanism of Telnet. However, the means to transfer
status information between OPE and the Host is provided
via the Status command. Therefore, details of status
negotiation are irrelevant to the interface to the
outboard Telnet.
2.3.6. Examples of the Command
The following example shows the command issued by a Host to
the OPE, requesting that the OPE negotiate with the other
side so that remote echo is performed.
C CO -pi DO 1 <nl>
The numeral 1 is the option code for ECHO from the table
above. All of the simple options listed above use this same
basic format.
The options with additional parameters use straightforward
extensions of this syntax. For example, a possible usage of
Condition by the Host to set the approximate message size
is:
C CO -pi DO 4 DS 1024
RFC929 December 1984
Proposed Host-Front End Protocol
The 4 is the Option Code for the Approximate Message Size
option, the DS indicates that Host's message size should be
set, and 1024 is the desired size.
2.4. The Signal Command
The Signal command is used with Telnet to provide the Telnet
Interrupt Process and Abort Output services.
2.4.1. Specialized Usage
The Signal command is used with an outboard Telnet
interpreter to interface to the Telnet synch mechanism.
This mechanism is used with a protocol-idiosyncratic
parameter, which indicates what particular command is being
"synched." It is expected that normally, this Signal
mechanism will only be used with the Interrupt Process and
Abort Output Telnet signals. When the Signal command is
issued by the Host, it goes through the Channel
(out-of-band) to the OPE, where the Telnet interpreter
issues the corresponding Telnet signal and synch sequence.
When such a sequence is received by the OPE, it immediately
issues a Signal to the Host. It is expected that a Host or
OPE would not, in general, reject the Signal command unless
it is badly formed.
2.4.2. Protocol-Idiosyncratic Parameters
The Telnet protocol-idiosyncratic parameter used with the
Signal command identifies which Telnet signal is begin
issued. Normally, it would have the value of either "IP" or
"AO", for Interrupt Process or Abort Output. If absent, the
default value is "IP".
2.4.3. Examples of the Command
An example of a Telnet Signal Command (in this case, to send
an Interrupt Process signal) is:
C SI IP <nl>
RFC929 December 1984
Proposed Host-Front End Protocol
2.5. The Status Command
The Status command is used with Telnet to obtain information
about the Telnet connection and the options in effect.
2.5.1. Specialized Usage
The Status command has one specialized aspect when used to
interface to an outboard Telnet interpreter. That is to
send and receive the Telnet Protocol status request
subnegotiation message to and from the data stream. In
order to invoke the status command for this purpose,
however, the user must have previously issued the Condition
Status command, which causes the ability to request status
to be negotiated. The OPE, when it receives a valid Status
request command, immediately responds to the user indicating
the status. The OPE can issue a status to request the
Host's negotiated positions.
2.5.2. Protocol-Idiosyncratic Parameters
There are no protocol-idiosyncratic parameters to the Status
query command. The Status Response command has a single
protocol-idiosyncratic parameter. It is an ASCII string
containing the status of the various options (not at their
default values).
2.5.3. Examples of the Command
An example of a Status Query command is:
C ST Q
An example of a Status Response command is:
F ST R "WILL ECHO DO SUPPRESS-GO-AHEAD
L WILL STATUS DO STATUS" <nl>
In the previous example, note the opening quote is in the
first chunk, and the closing quote is in the last chunk.
This technique permits parameters to span chunk boundaries.
RFC929 December 1984
Proposed Host-Front End Protocol
2.6. The End Command
The End command is used to terminate the Telnet connection,
either gracefully or abruptly.
2.6.1. Specialized Usage
The graceful termination of a Telnet requires End commands
to be issued by both the Host and the OPE. This specialized
usage is identical to that of the outboard TCP interface,
however.
2.6.2. Examples of the Command
An example of the graceful End command is:
C EN G <nl>
The abrupt End command is similar.
2.7. The No-op Command
The No-op command is used with Telnet so the Host can determine
if the OPE is active, and vice versa.
2.7.1. Specialized Usage
The No-op command has one specialized usage when offloading
Telnet. This is to provide the Telnet Are You There (AYT)
feature. When an (AYT) message is received by the OPE, it
issues a No-op command to the Host. Upon receiving the
response from the Host, the appropriate response is sent
back in the data stream.
2.7.2. Protocol Idiosyncratic Parameters
There are no protocol-idiosyncratic parameters to the No-op
command.
2.7.3. Examples of the Command
An example of the No-op command is:
C NO <nl>
RFC929 December 1984
Proposed Host-Front End Protocol
3. FTP Offloading
TBS
4. Mail Offloading
TBS
5. Whatever Offloading
TBS
Where TBS nominally = To Be Supplied, but really means: We'll argue
through these once we get sufficiently positive feedback on the
others (and on the H-FP as a whole).