doc: Add RFC documents

1 files changed, 3192 insertions, 0 deletions

diff --git a/doc/rfc/rfc929.txt b/doc/rfc/rfc929.txt
new file mode 100644
index 0000000..b1bde75
--- /dev/null
+++ b/doc/rfc/rfc929.txt
@@ -0,0 +1,3192 @@
+
+
+Network Working Group                              Joel Lilienkamp (SDC)
+Request for Comments: 929                          Richard Mandell (SDC)
+                                         Michael Padlipsky (Mitre Corp.)
+                                                           December 1984
+
+                    PROPOSED HOST-FRONT END PROTOCOL
+
+
+Status Of This Memo
+
+   The reader should be aware of several things in regard to what the
+   present document is up to.  First and foremost, IT IS A PROPOSAL FOR
+   A STANDARD, NOT A STANDARD ITSELF.  Next, it assumes that the
+   separate document, RFC 928, which is an introduction to the present
+   document, has been read before it is. Next, it should be understood
+   that "final cut" over this version of the document has been exercised
+   by the author of RFC 928, not by the primary author of the present
+   document, so any readers bothered by style considerations should feel
+   free to blame the former, who's used to it, rather than the latter,
+   who may well be guiltless.  (Editing at a distance finally become too
+   hard to manage, so if I'm typing it myself I'm going to fiddle with
+   it myself too, including, but not limited to, sticking my own section
+   on the Conceptual Model in before Joel's words start, rather than
+   leaving it in the Introduction.  MAP)
+
+   Finally, it should be noted that this is not a finished document.
+   That is, the intent is eventually to supply appendices for all of the
+   protocol offloadings, describing their uses of protocol idiosyncratic
+   parameters and even their interpretations of the standard per-command
+   parameters, but in order to get what we've got into circulation we
+   haven't waited until all such appendices have been written up.  (We
+   do have notes on how to handle FTP, e.g., and UDP will be pretty
+   straightforward, but getting them ready would have delayed things
+   into still another calendar year, which would have been very annoying
+   ... not to say embarrassing.) For that matter, it's not even a
+   finished document with respect to what is here. Not only is it our
+   stated intention to revise the protocol based upon implementation
+   experience gained from volunteer test implementations, but it's also
+   the case that it hasn't proven feasible to iron out all known
+   wrinkles in what is being presented.  For example, the response codes
+   almost certainly need clarification and expansion, and at least one
+   of us doesn't think mandatory initial parameters need control flags.
+   However, to try too hard for polish would be to stay in subcommittee
+   for the better part of forever, so what you see is what we've got,
+   but certainly isn't meant to be what you or we are stuck with.
+
+   This RFC suggests a proposed protocol for the ARPA-Internet
+   community, and requests discussion and suggestions for improvements.
+   Distribution of this memo is unlimited.
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                                [Page 1]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+Conceptual Model
+
+   There are two fundamental motivations for doing outboard processing.
+   One is to conserve the Hosts' resources (CPU cycles and memory) in a
+   resource sharing intercomputer network, by offloading as much of the
+   required networking software from the Hosts to Outboard Processing
+   Environments (or "Network Front-Ends") as possible. The other is to
+   facilitate procurement of implementations of the various
+   intercomputer networking protocols for the several types of Host in
+   play in a typical heterogeneous intercomputer network, by employing
+   common implementations in the OPE.  A third motivation, of basing a
+   network security approach on trusted mandatory OPEs, will not be
+   dealt with here, but is at least worthy of mention.
+
+   Neither motivation should be allowed to detract from the underlying,
+   assumed desire to perform true intercomputer networking, however.
+   Therefore, it is further assumed that OPEs will be attached to Hosts
+   via a flexible attachment strategy, as described in [1]. That is, at
+   the software level an explicit Host-Front End Protocol (H-FP) will be
+   employed between Hosts and OPEs, rather than having OPEs emulate
+   devices or device controllers already "known" to Host operating
+   systems (in order to avoid introducing new code into the Host).
+
+   For reasons discussed in the Introduction, an H-FP resolves into
+   three layers.  The Link layer enables the exchange of bits between
+   Host and OPE.  The Channel layer enables the bit streams to be
+   demultiplexed and flow controlled  (both the Channel and Link layers
+   may use preexisting per-Host mechanizations, it should be recalled).
+   The Command (or "Service Access") layer is our primary concern at
+   present. It serves as the distributed processing mechanism which
+   allows processes on Hosts to manipulate protocol interpreters (PIs)
+   in OPEs on their behalf; for convenience, it will be referred to as
+   "the H-FP" here.  (It should be noted that the Link and Channel
+   layers may be viewed as roughly equivalent to the inboard processing
+   investment for a Host-comm subnet processor PI and device driver, so
+   in practical terms the savings of resources achieved by outboard
+   processing come from making the H-FP "smaller" than the inboard
+   implementations of the protocols it allows to be offloaded.)
+
+   The crucial property of the H-FP conceptually is that it stands as
+   the interface between a (Host) process and a PI (which is actually
+   outboard).  Usually, the model is that of a closed subroutine
+   interface, although in some cases an interprocess communication
+   mechanism model must be appealed to.  That is, the interactions
+   between cooperating H-FP PIs in some sense mimic subroutine or IPC
+   calls, from the perspective of Host processes calling upon their own
+   H-FP PIs, which in turn are of course interfacing via just such
+
+
+Lilienkamp & Mandell & Padlipsky                                [Page 2]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+   mechanisms themselves. Another way of putting it is that "if the
+   protocols were inboard," the processes invoking H-FP wouldn't know
+   the difference.  H-FP, then, may be viewed as a roundabout way of
+   letting Host processes "get at" various PIs.
+
+   Naturally, the mechanization of the desired concept cannot be
+   particularly literal.  After all, the Hosts and the OPEs are
+   different processors, so we're not envisioning a passing through of
+   parameters in an exact fashion.  However, in broad terms the model is
+   just that of a somewhat funny interface between a process and a PI.
+   (This should not be construed as ruling out the occurrence of events
+   which prompt the OPE to initiate an exchange of commands with the
+   Host, though; see the Introduction for more on the topic of
+   "Symmetric Begins.")
+
+Interaction Discipline
+
+   The interaction between the Host and the OPE must be capable of
+   providing a suitable interface between processes (or protocol
+   interpreters) in the Host and the off-loaded protocol interpreters in
+   the OPE.  This interaction must not, however, burden the Host more
+   heavily than would have resulted from supporting the protocols
+   inboard, lest the advantage of using an OPE be overridden.
+
+   Channel Level Interaction
+
+   As stated elsewhere, the Channel level protocol (implicitly in
+   conjunction with the Link level) provides two major functions. These
+   are demultiplexing the traffic from the Link level into distinct data
+   streams, and providing flow control between the Host and the OPE on a
+   per stream basis.  These hold even if the Host-OPE attachment is DMA.
+
+   The data streams between the Host and the OPE are bidirectional. In
+   this document, the basic unit of data transferred by the Channel
+   level is referred to as a "chunk".  The primary motivation for this
+   terminology is that the H-FP permits the Channel level to be one of
+   several possible protocols, each with its own terminology.  For
+   example, a chunk on an X.25 Channel would be a packet, while a chunk
+   on the DTI H-FP channel would be a message.  While the Command level
+   is, in a sense, "more efficient" when the chunk size is permitted to
+   be large, the flexibility permitted in the choice of protocols at the
+   Channel level precludes any assumptions about the chunk size.
+
+   Each data stream is fully asynchronous.  A Channel protocol user can
+   send data at any time, once the channel has been properly opened.
+   (The Command level's logic may render some actions meaningless,
+   however.) The data transfer service provided by the Channel protocol
+
+
+Lilienkamp & Mandell & Padlipsky                                [Page 3]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+   is reliable;  this entails delivery in the correct order, without
+   duplication, and checked for bit errors.  All retransmission, error
+   checking, and duplicate detection is provided by this protocol in a
+   way that is transparent to the user.  (If the attachment is DMA,
+   stream identification and chunk length must still be provided for.)
+
+   The flow control at the Channel level is provided to prevent the OPE
+   and the Host from overloading each other's resources by excessive
+   transmissions.  In general, this flow control should not directly
+   affect the outboard protocol interpreters' operation.  On the other
+   had, this flow control has the same effect as explicit interface
+   events that provide flow control between the user and the protocol
+   interpreter (e.g., the Allocate event of the interface specification
+   for TCP found in MIL-STD 1778).  Hence, such events do not need to be
+   communicated explicitly at the Command level.  (If the attachment is
+   DMA, flow control must still be provided for.)
+
+   Should Hosts require an OPE to be attached via a Link Level that
+   furnishes physical demultiplexing (e.g., a group of RS232 ports), any
+   attempt to avoid furnishing reliability and explicit flow control, is
+   done at their peril;  we have not chosen to assist such an
+   enterprise, but neither have we precluded it.  (It would certainly
+   violate the spirit of the thing, however.)
+
+   Command Level Interaction
+
+   The approach chosen for this H-FP is to base the interaction on a
+   small set of commands, separately applicable to a given Channel Level
+   channel. The commands are simple, but sufficiently flexible to permit
+   the off-loading of the interpreters of the large number of protocols
+   at various levels in the hierarchy.  This flexibility is made
+   possible in part by the similar nature of the interfaces to most
+   protocols, combined with the provision of "protocol idiosyncratic
+   parameters". These parameters are defined for each offloaded protocol
+   interpreter in the OPE.  The use of such parameters does not
+   complicate the basic design of the OPE, since it must be customized
+   for each off-loaded protocol anyway, and all that is required of the
+   OPE for those parameters is to pass them to the off-loaded protocol
+   interpreter.  Hence, an interface tailored to a particular protocol
+   can be created in a straightforward and cost-effective way.
+
+   The command dialog is more or less asynchronous.  Commands can be
+   issued at any particular time (except when there is a pending
+   command, which will be discussed below), and there is no need for
+   dummy traffic on a channel when no commands are issued.
+
+   Associated with each command is a response.  The purpose of this
+
+
+Lilienkamp & Mandell & Padlipsky                                [Page 4]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+   response is to indicate, at some level that depends in part on the
+   particular protocol interpreter that is offloaded to the OPE, whether
+   the command was successfully executed, and if unsuccessful, the
+   reason.  Often, generating the response involves interaction with the
+   protocol interpreter before a response can be generated.
+
+   When a command is issued, the issuer must wait for a response before
+   another command is issued.  The nature of the communication between
+   the Host and the OPE is thus a lock step command/response dialog.
+   There are two major exceptions to this principle, however. One
+   exception is the abrupt form of the End command, which can be issued
+   at any time to cancel any previously issued commands, and indicate
+   that services are no longer desired.  The other exception is the
+   Signal command.  Since a Signal is out-of-band and usually of high
+   importance, forcing it to wait on a response would be undesirable.
+   Hence, a Signal command can be issued while commands (other than
+   Signal) are pending.  However, a Signal command should not be issued
+   before a successful response to the Begin command has been received.
+   Since it is possible for more than one command of different types to
+   be pending at one time, a mechanism to distinguish responses is
+   needed.  Since there are never two commands of the same type pending,
+   including the command name in the response is sufficient to make this
+   distinction.
+
+   A special case command is the Transmit command.  Details of the
+   Transmit command are provided in the next section. Essentially, the
+   Transmit command is used to invoke the data transfer services of the
+   off-loaded protocol (when issued by the Host) or to indicate the
+   arrival of new data from the network (when issued by the OPE).  The
+   nature of specific protocol interfaces for these events varies widely
+   between protocols.  Some may block until the data is accepted by the
+   remote counterpart (or "peer") protocol interpreter, while others may
+   not.  Hence, there is a special parameter which indicates the nature
+   of the Transmit command interface.  It can either require that the
+   response should be generated immediately after determining the
+   Transmit command is complete and formed properly, or can indicate
+   that the response should not be generated until the appropriate
+   interface event is given by the remote protocol interpreter.  The
+   default action for all Transmit commands can be initialized using the
+   Begin command and changed using the Condition command.  Also, the
+   default action can be temporarily overridden by specifying a
+   parameter with the Transmit command. The net result of this mechanism
+   is to allow the Host to determine within reason just how lock-stepped
+   transmissions are to be.  (It is assumed that the usual case will be
+   to transfer the burden of buffering to the OPE by taking immediate
+   responses, provided that doing so "makes sense" with the particular
+   offloaded protocol in play.)
+
+
+Lilienkamp & Mandell & Padlipsky                                [Page 5]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+   Some protocols provide a block-oriented data transfer service rather
+   than a stream-oriented one.  With such a service, the data associated
+   with a transfer request is viewed as an integral unit.  For actual
+   network transmission, the protocol may permit these units to be
+   grouped or fragmented. However, the receiving end must deliver the
+   data in the original, integral units. Protocols that conform to this
+   model include some datagram protocols such as IP and UDP, and also
+   some connection protocols such as NBS TP.
+
+   To cater to these types of protocols, it is a convention that
+   commands, their parameters, and any associated data be transferred
+   between the Host and the OPE in a single chunk. Any data associated
+   with an H-FP command is viewed as an integral unit which is used in
+   the corresponding service request given to the outboard protocol
+   interpreter or delivered as a complete unit to the process in the
+   Host. Operation of stream-oriented protocols such as TCP will not be
+   adversely affected by this convention.
+
+   To accommodate Channel protocols that do not provide for arbitrarily
+   large chunks, a mechanism at the Command level is required to permit
+   the linking of multiple chunks into a single command, in order to
+   transfer the burden of buffering as much as possible from the Host to
+   the OPE.  The facility proposed here would consist of an indication
+   at the beginning of each chunk which would distinguish integral
+   commands, fragments of a command for which more fragments are yet to
+   arrive, and the final fragment of a command.  The details of this
+   mechanism are discussed in the section on the syntax of commands and
+   responses.
+
+   It is a convention for this H-FP that any data associated with a
+   command must start on a word boundary (as defined by the local
+   system).  Consequently, there is a need to provide padding within the
+   commands.  Such padding is used only to fill to the next appropriate
+   boundary, and has no semantic significance to the command interpreter
+   (i.e., two commands that are identical except for the amount of
+   padding should behave identically).  The details of this padding are
+   discussed in the section on the syntax of commands and responses.
+
+
+
+
+
+
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                                [Page 6]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+Syntax Rules
+
+   At the Command Level, communication between the Host and the OPE
+   takes the form of commands and responses.  A command is a request for
+   some particular action, and the response indicates the success or
+   failure of performing the requested action.
+
+   All commands and responses are coded in ASCII characters. (Nothing
+   precludes OPEs from accepting EBCDIC from Hosts that use it in native
+   mode, but that is not required.) These characters are sent in some
+   way convenient for the Host, and the OPE is sufficiently flexible to
+   interpret them.  (i.e., OPEs are expected to accommodate Host
+   idiosyncracies in regard to such things as use of 7-bit ASCII in a
+   9-bit field.) This approach offers several advantages:
+
+   Adaptabilities in most Hosts:  Most Hosts have the ability to
+   generate and interpret ASCII character streams.  Hence, integrating
+   H-FP into a Host will not require difficult software.
+
+   Script generation:  Generation of test and operational command
+   scripts will be simplified, since they will not need to contain
+   special characters.
+
+   Terminal Operation:  Using simple command streams simplifies the
+   conversion of an OPE to a generic virtual terminal support machine.
+   This is particularly useful during development and testing.
+
+   Testing:  Testing will not require special hardware to interpret
+   commands and responses.  A terminal or data line analyzer would be
+   adequate.
+
+   The specific format for the commands and responses will be discussed
+   in the sections that follow. In those sections, the quote character
+   is used to indicate strings.  The symbols "<" and ">" (referred to as
+   angle brackets) are used as meta-characters.
+
+   Syntax of Commands
+
+   As alluded to in the section discussing the interaction discipline
+   between the Host and the OPE, a function is provided by which a chunk
+   can be used to carry either a complete command or a fragment of a
+   command.  The mechanism chosen to provide this function entails use
+   of the first character position in the chunk as a chunk usage
+   identifier.  The character "C" in the first position indicates a
+   chunk containing a single, complete command.  "F" in the first
+   position indicates a chunk which is the first part of a multichunk
+   command. "M" in the first position indicates the chunk is a middle
+
+
+Lilienkamp & Mandell & Padlipsky                                [Page 7]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+   part (neither the first nor the last chunk) of a command.  Finally,
+   "L" indicates the chunk is the last chunk of a multi-chunk command.
+   Hence, the following sequences of chunks (the letter corresponds to
+   the chunk usage identifier in each chunk, and the angle brackets
+   enclose a chunk) are legal:
+
+      <C>
+      <F><L>
+      <F><M><M><L>
+
+   while the following are not legal:
+
+      <L>
+      <M><L>
+      <F><C>
+
+   Tactics for handling multiple chunks with regard to OPE buffering
+   limits are left to the ingenuity of OPE builders. The spirit is to
+   take as much as you can, in order to relieve the Host of the
+   necessity of buffering itself.
+
+   A command always begins immediately following the indicator
+   character, with possible intervening spaces.  This implies a chunk
+   can contain at most one complete command.  The end of the command
+   (not including the data) is signified by a newline (denoted as <nl>
+   in this document) that does not appear inside a quoted string (see
+   below).  The end of the data is designated by the end of the last
+   chunk.
+
+   Commands take the form of an ASCII string.  The command identifier is
+   the first word of the chunk.  It consists of at least the first two
+   letters of the command, in either upper or lower case (e.g., the
+   sequences "BE", "Be", "bE", and "be" all identify the Begin command).
+   Additional letters of the command name can be included if desired to
+   aid readability of the command stream.
+
+   Following the command identifier is a list of parameters. These
+   parameters are also represented as ASCII strings, although the
+   specific format will depend on the particular parameter.  The data to
+   be transmitted is not considered a control parameter, however, and
+   need not be ASCII data.
+
+   Parameters are separated by one or more spaces.  Tabs, newlines, and
+   other white space are not legal parameter separators.
+
+   Parameter strings may be quoted, using the character <">. Any
+
+
+
+Lilienkamp & Mandell & Padlipsky                                [Page 8]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+   characters between the <"> characters are a part of the parameter,
+   including spaces and newlines.  The character <"> that is part of the
+   parameter is represented inside a quoted string as <"">.
+
+   The order in which the parameters appear within the command is
+   significant to their interpretation by the Host and by the OPE.
+   Optional parameters may be skipped by using the characters ",," to
+   indicate a NULL parameter.  Such a NULL parameter takes its default
+   value.  Alternatively, each parameter has a MULTICS/UNIX style
+   Control Argument/Flag associated with it that can be used to identify
+   the parameter, without placing NULL parameters for each parameter
+   skipped.  This flag consists of one or two ASCII characters, and
+   either upper or lower case may be used.  For example, if the fourth
+   parameter of a command had a flag of "-p" and the user wished the
+   first three parameters to be null, he could use:
+
+      command -p value
+
+   or
+
+      command -P value
+
+   instead of
+
+      command ,, ,, ,, value
+
+   if it were more convenient for the Host to do so.  Flagged parameters
+   must still appear in the correct sequence within the command,
+   however.
+
+   There may be data associated with some of the commands.  Any such
+   data is placed into the chunk following all the parameters and the
+   unquoted newline. Padding can be provided by placing spaces between
+   the end of the final parameter string and the newline, so that data
+   begins on a word boundary. The OPE will always pad to a host word
+   boundary.  Padding by hosts is optional.
+
+   Syntax of Responses
+
+   Responses are actually just a special form of a command.  It is
+   anticipated that all responses would fit into a single channel chunk,
+   although the mechanisms described for multichunk commands can
+   certainly be used in responses.  The ASCII string used to uniquely
+   identify the response command is "RE" ("Re", "rE", and "re" are also
+   permitted).
+
+   After the response command identifier is the original command
+
+
+Lilienkamp & Mandell & Padlipsky                                [Page 9]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+   identifier, so the response can be associated with the proper
+   command.  Following this identifier is a three ASCII digit response
+   code, a set of protocol idiosyncratic parameters, and a textual
+   message.  The protocol idiosyncratic parameters are used to transfer
+   interface information between the Host and the OPE, and may not be
+   needed when off-loading some protocol interpreters.  The textual
+   message is intended for human interpretation of the response codes,
+   and is not required by the protocol.  The three digits uniquely
+   identify the semantics of the response, at least within the context
+   of a particular command and particular outboarded protocol
+   interpreter.
+
+   Responses are numerically grouped by the type of information they
+   convey.  The first digit identifies this group, and the last two
+   digits further qualify the reply.  The following list illustrates
+   this grouping.
+
+      0XX Successful:  The command was executed successfully. The
+          response code may contain further information.
+
+      1XX Conditional Success:  The command was executed successfully,
+          but not exactly according to the service and flow control
+          suggestions.  If those suggestions were particularly important
+          to the requester, he may wish to issue an End command.  The
+          response code contains information on what suggestion or
+          suggestions could not be followed.
+
+      2XX Command Level Error:  An error at the command level has
+          occurred.  This could include requesting services of a
+          protocol not supported, or a problem in the way those services
+          were requested.  This level does not include problems with the
+          syntax of the command or its parameters.
+
+      3XX Syntax and Parameter Errors:  An error in the syntax of the
+          command or a problem with one of its parameters has occurred.
+          A problem with a parameter may be other than syntactical, such
+          as illegal address.
+
+      4XX Off-loaded Protocol Interpreter Problems:  Some problem with
+          the particular off-loaded protocol has occurred.
+
+      5XX Local OPE Internal Problems:  Problems, such as insufficient
+          OPE resources, or problems with OPE to subnet interface.
+
+      6XX Security Problem:  Some problem with Host, network, or OPE
+          security has occurred.  The response code indicates the
+          problem.
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 10]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+      7XX Reserved for Future Expansion
+
+      8XX Reserved for Future Expansion
+
+      9XX Protocol Idiosyncratic Errors:  Some error occurred that is
+          idiosyncratic to the particular off-loaded protocol being
+          used.  The response code indicates the error.
+
+Description of the Commands
+
+   As stated above, communication between the Host and the OPE at the
+   Command Level is accomplished using commands and responses.  Commands
+   may be issued by either the Host or the OPE, and are used to
+   stimulate activity in the other entity. Some commands may only have a
+   meaningful interpretation in one direction, however.  A response
+   indicates that the activity started by the command was completed, and
+   a code indicates success or failure of the command, and perhaps other
+   information related to the command as well.
+
+   Associated with each command is a set of parameters.  The order in
+   which the parameters appear is significant to the correct operation
+   of the protocols.  More information on the syntax of command
+   parameters can be found in the syntax descriptions.
+
+   The commands are:
+
+      - Begin: initiate communication between a process in the Host and
+      an off-loaded protocol interpreter in the OPE.  (A Channel level
+      stream/connection will typically have been opened as a prior step.
+      All other commands, except No-op, apply to a stream on which a
+      successful Begin has been done.)
+
+      - Transmit: transmit data between a process in the Host and an
+      off-loaded protocol interpreter in the OPE.
+
+      - Signal:  cause an out-of-band signal to be sent by the
+      off-loaded protocol interpreter to its peer, or indicate the
+      arrival of such a signal from the remote side.
+
+      - Condition: alter the off-loaded protocol interpreter's
+      operational characteristics.
+
+      - Status: transfer status requests or information between a
+      process in the Host and an off-loaded protocol interpreter in the
+      OPE.
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 11]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+      - End: indicate that services from the off-loaded protocol
+      interpreter are no longer required, or will no longer be provided.
+
+      - No-op:  performs no operation, but facilitates testing.
+
+   These commands will be discussed in the following sections. Each of
+   these sections includes a discussion of the purpose of the command, a
+   description of each of the parameters used with the command, a list
+   of responses for the command, an example of the command, and a set of
+   notes for the implementor.  (An appendix will eventually be furnished
+   for each protocol offloading, showing the use of its protocol
+   idiosyncratic parameters as well as of the general parameters on a
+   per-command basis.  Initially, only representative offloadings will
+   be treated in appendices, with others to be added after the protocol
+   gains acceptance.)
+
+   Begin
+
+      Purpose of the Begin Command
+
+         The purpose of a Begin command is to initiate communication
+         between the Host and the OPE on a particular stream or channel
+         (the channel is opened as a separate step, of course). The
+         interpretation of the command is somewhat dependent upon
+         whether it was issued by the Host of the OPE.
+
+         - If the command was issued by the Host, it means some process
+         in the Host is requesting services of a protocol that was
+         off-loaded to the OPE.  The user request results in the
+         establishment of a channel connection between the Host and the
+         OPE, and a Begin command to the Command interpreter in the OPE.
+
+         - If the command was issued by the OPE, it means some protocol
+         interpreter in the OPE has data for some process in the Host
+         which is not currently known by the OPE.  An example would be
+         an incoming UDP datagram on a new port, or if no Begin for UDP
+         had been issued at all by the Host.  (An incoming TCP
+         connection request could be handled by a response to the user's
+         Passive Open request, which had previously caused a Begin
+         request from the Host; an incoming TCP connection request to a
+         port on which no Listen had been issued would cause an OPE
+         generated Begin, however.)
+
+         As indicated earlier, any particular Host is not required to
+         support two-way Begins.
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 12]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+      Parameters of the Begin Command
+
+         The Begin command has several parameters associated with it.
+         These parameters contain information needed by the offloaded
+         protocol to provide an adequate level of network service.  This
+         information includes protocol, source and destination
+         addresses, and also type of service and flow control advice.
+         These parameters are discussed in detail below.
+
+      Protocol
+
+         The protocol parameter identifies that off-loaded protocol in
+         the OPE to which Begin is directed, or which issued the Begin
+         to the Host.  For example, if the user wished to utilize TCP
+         services, and the TCP software was off-loaded into the OPE,
+         then the Protocol parameter for the Begin command would be TCP.
+
+         There are two categories of protocol parameters -- generic and
+         specific.  A generic parameter identifies a type of protocol
+         service required, but does not identify the actual protocol.
+         Use of generic protocols allows a Host process to obtain
+         network services without specific knowledge of what protocol is
+         being used; this could be appropriate for use in situations
+         where no specific aspect(s) of a specific protocol is/are
+         required.  For example, the user may select a generic
+         Host-to-Host connection protocol, and (at some point in the
+         future) may actually receive services from either TCP or the
+         NBS Transport Protocol, depending on the network (or even the
+         foreign Host) in question.  A specific protocol parameter
+         identifies some particular protocol, e.g., TCP, whose use is
+         required for the given channel.
+
+         The valid entries for the protocol field include:
+
+            Generic   Specific  Comment
+
+            GIP       IP        Datagram Internetwork Protocol
+            HHP       TCP       Connection Transport/Host-Host Protocol
+            GDP       UDP       Datagram Transport/Host-Host Protocol
+            VTP       TEL       Virtual Terminal (Telnet) Protocol
+            GFP       FTP       File Transfer Protocol
+            MAIL      SMTP      Mail Transfer Protocol
+            PROX      PROX      Proximate Net Interface Protocol
+
+         (Note that the final line is meant to allow for a process in an
+         OPE'd Host's getting at the PI of the Network Interface
+         Protocol for whatever the proximate network is.  Of course, so
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 13]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         doing only makes sense in specialized contexts.  We conceive of
+         the desirability of "pumping bits at a peripheral" on a LAN,
+         though, and don't want to preclude it, even if it would be
+         impossible on many LAN's to deal with the problem of
+         distinguishing traffic coming back on the LAN in this "raw"
+         mode from normal, IP traffic.  Indeed, in some contexts it is
+         likely that administrative considerations would preclude
+         avoidance of IP even if technical considerations allowed it,
+         but it's still the case that "the protocol" should provide a
+         hook for going directly to the L I protocol in play.)
+
+         There is no default value for this parameter.  If it is not
+         present, the Begin command is in error.  The control flag for
+         this parameter is -pr.
+
+      Active/Passive
+
+         The Active/Passive parameter indicates whether the issuer of
+         the Begin command desires to be the Active or Passive user of
+         the protocol.  This parameter is particularly relevant to
+         connection-oriented protocols such as TCP, where the user may
+         actively pursue connection establishment, or else may passively
+         wait for the remote entity to actively establish the
+         connection; it also allows some process to establish itself as
+         the Host "fielder" of incoming traffic for a connectionless
+         protocol such as IP.
+
+         Active is requested using the single character "A".  Passive is
+         indicated using the character "P".  The default value of this
+         parameter is "A". Also, when the OPE issues the Begin command,
+         the value must be "A".  The control flag for this parameter is
+         -ap.
+
+      Foreign Address Primary Component
+
+         The addressing structure supported by H-FP is two level. Each
+         address has two components, the primary and the secondary.  The
+         exact interpretation of these two components is protocol
+         specific, but some generalities do apply.  The primary
+         component of the address identifies where the protocol is to
+         deliver the information. The secondary component identifies
+         which recipient at that location is to receive the information.
+         For example, the TCP primary address component is the Host's
+         Internet Address, while the secondary address component is the
+         TCP port.  Similarly, IP's primary address component is the
+         Host's Internet Address, and the secondary address component is
+         the IP ULP field.  Some protocols provide only a single level
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 14]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         of addressing, or the secondary level can be deduced from some
+         other information (e.g., Telnet).  In these cases, only the
+         primary component is used.  To cater to such cases, the
+         secondary component parameter comes later in the parameter
+         list.
+
+         The Foreign Address Primary Component parameter contains the
+         primary component of the destination address.  It may be in
+         either a numeric or symbolic form.  (Note that this allows for
+         the OPE to exercise a Name Server type of protocol if
+         appropriate, as well as freeing the Host from the necessity of
+         maintaining an in-board name to address table.) The default
+         value for this parameter, although it only makes sense for
+         Passive Begins, is "Any Host".  The control flag for this
+         parameter is -fp.
+
+      Mediation Level
+
+         The mediation level parameter is an indication of the role the
+         Host wishes the OPE to play in the operation of the protocol.
+         The extreme ranges of this mediation would be the case where
+         the Host wished to remain completely uninvolved, and the case
+         where the Host wished to make every possible decision.  The
+         specific interpretation of this parameter is dependent upon the
+         particular off-loaded protocol.
+
+         The concept of mediation level can best be clarified by means
+         of example.  A full inboard implementation of the Telnet
+         protocol places several responsibilities on the Host. These
+         responsibilities include negotiation and provision of protocol
+         options, translation between local and network character codes
+         and formats, and monitoring the well-known socket for incoming
+         connection requests.  The mediation level indicates whether
+         these responsibilities are assigned to the Host or to the OPE
+         when the Telnet implementation is outboard.  If no OPE
+         mediation is selected, the Host is involved with all
+         negotiation of the Telnet options, and all format conversions.
+         With full OPE mediation, all option negotiation and all format
+         conversions are performed by the OPE.  An intermediate level of
+         mediation might have ordinary option negotiation, format
+         conversion, and socket monitoring done in the OPE, while
+         options not known to the OPE are handled by the Host.
+
+         The parameter is represented with a single ASCII digit.  The
+         value 9 represents full OPE mediation, and the value 0
+         represents no OPE mediation.  Other values may be defined for
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 15]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         some protocols (e.g., the intermediate mediation level
+         discussed above for Telnet).  The default value for this
+         parameter is 9.  The control flag for this parameter is -m.
+
+      Transmit Response Discipline
+
+         The Transmit Response Discipline parameter is used to set the
+         desired action on the OPE's part for generating responses to
+         Transmit commands.  Essentially the parameter determines when
+         the OPE's response to the transmit command occurs (i.e.,
+         immediately or delayed).
+
+         The Transmit Response Discipline value is represented by a
+         single ASCII character.  The character "N" is used for
+         nonblocking Transmit commands, which implies that responses for
+         Transmit commands should be generated as soon as the command
+         has been examined for correctness (i.e., that the syntax is
+         good and the parameters appear reasonable).  In other words,
+         the outboard protocol interpreter has the data in its queue,
+         but hasn't necessarily transmitted it to the net.  The
+         character "B" is used for blocking Transmit commands, which
+         requests that the response not be generated until the protocol
+         interpreter has successfully transmitted the data (unless, of
+         course, the Transmit command was badly formed). The default
+         value for this parameter is "N", or a nonblocking Transmit
+         command.  The control flag for this parameter is -tr.
+         (Depending on the protocol in play, "successfully transmitted"
+         might well imply that an acknowledgment of some sort has been
+         received from the foreign Host, but for other protocols it
+         might only mean that the given collection of bits has been
+         passed from the OPE to the proximate net.)
+
+      Foreign Address Secondary Component
+
+         The addressing mechanisms supported by this level of H-FP are
+         discussed above.  The Foreign Address Secondary Component
+         parameter contains the value of the destination address's
+         secondary component.  Some protocols do not require this
+         parameter, or can obtain it from other information.  Therefore,
+         the default value for this parameter is NULL.  A NULL secondary
+         component might be an error for some protocols, however.  The
+         secondary component can be expressed either numerically or
+         symbolically.  The control flag for this parameter is -fs.
+         (Note that it is intended to be "legal" to specify a Secondary
+         Component other than the Well-Known Socket for the protocol in
+         play; in such cases, the result should be that the virtualizing
+         of the given protocol be applied to the stream, in the
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 16]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         expectation that that's what the other side is expecting.  This
+         is to cater to, for example, a Terminal-Terminal protocol that
+         merely "does Telnet" to a socket other than the usual Logger.)
+
+      Local Address Secondary Component
+
+         The Local Address Secondary Component parameter contains the
+         value of the local address's secondary component.  (The primary
+         component is assumed to be the default for the Host, but can be
+         altered as well; see below.) Some protocols do not require this
+         parameter, or can obtain it from other information.  In some
+         cases, the OPE may already know the value for this parameter
+         and therefore not require it. The default value of this
+         parameter is NULL.  The local address secondary component can
+         be expressed either numerically or symbolically.  The control
+         flag for this parameter is -ls.
+
+      Begin Timeout Interval
+
+         After a Begin command is issued, a timer can be started.  If
+         the activity requested cannot be performed within some timed
+         interval, then the Begin command may expire.  An expired Begin
+         command returns a response code indicating a Begin timeout
+         occurred.  The Begin Timeout Interval parameter contains the
+         length of time the timer will run before the Begin timeout
+         occurs.
+
+         The parameter is represented as a string of ASCII digits
+         indicating the time interval in seconds.  The default value of
+         this parameter is infinity (i.e., the Begin command will never
+         timeout).  The control flag for this parameter is -bt.
+
+      Type of Service Advice
+
+         The Type of Service Advice parameter contains information on
+         the service characteristics the user desires from the offloaded
+         protocol.  Included in this parameter is the precedence of the
+         data transfer, and also indication of whether high throughput,
+         fast response time, or low error rate is the primary goal.
+
+         The format of this parameter is a letter immediately (i.e. no
+         intervening spaces) followed by a digit.  The letter "T"
+         indicates that high throughput is desired.  The letter "R"
+         indicates minimal response time is the goal.  The letter "E"
+         indicates that low error rates are the goal.  The letter "N"
+         indicates there are no special service requirements to be
+         conveyed.  The digit immediately following the character
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 17]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         indicates the desired precedence level, with zero being the
+         lowest, and nine being the highest.  The specific
+         interpretation of this parameter is dependent on what service
+         options are provided by the protocol.  The default value of
+         this parameter is the lowest precedence (ROUTINE), and no
+         special service requests.  The control flag for this parameter
+         is -ts.
+
+      Flow Control Advice
+
+         The Flow Control Advice parameter contains information on the
+         flow characteristics desired by the user.  Some applications
+         such as file transfer operate more efficiently if the data is
+         transferred in large pieces, while other, more interactive
+         applications are more efficiently served if smaller pieces are
+         used.  This parameter then indicates whether large or small
+         data blocks should be used.  It is only relevant in stream or
+         connection-oriented protocols, where the user sends more than a
+         single piece of data.
+
+         This parameter is represented by a single ASCII digit. A value
+         0 means the data should be sent in relatively small blocks
+         (e.g., character or line oriented applications), while a value
+         9 means the data should be sent in relatively large blocks
+         (e.g., block or file oriented applications). Other values
+         represent sizes between those extremes.  The character "N"
+         indicates that no special flow control advice is provided.  The
+         actual interpretation of this parameter is dependent on the
+         particular protocol in the OPE.  The default value of this
+         parameter is no flow control advice. In this case, the protocol
+         in the OPE will operate based only on information available in
+         the OPE.  The control flag for this parameter is -fc.
+
+      Local Address Primary Component
+
+         This parameter contains the local address primary component. It
+         is anticipated that under most circumstances, this component is
+         known to both the Host and the OPE.  Consequently, this
+         parameter is seldom required.  It would be useful if the Host
+         desired to select one of several valid addresses, however.  The
+         control flag for this parameter is -lp.
+
+      Security
+
+         The security parameters contain a set of security level,
+         compartment, community of interest, and handling restriction
+         information.  Currently, security is provided by performing all
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 18]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         processing at system high level or at a single level.
+         Consequently, these parameters are probably redundant, since
+         the security information is known.  In the future, however,
+         these parameters may be required.  Therefore a field is
+         provided. The control flag for this parameter is -s.
+
+      Protcol Idiosyncratic Parameters
+
+         The remaining parameters are protocol idiosyncratic.  That is,
+         each protocol that is off-loaded may have a set of these
+         parameters, which are documented with a description of the
+         off-loaded protocol.  The default value for these parameters is
+         NULL, unless otherwise specified by a particular offloaded
+         protocol.  The control flag for this set of parameters is -pi,
+         which identifies the first protocol idiosyncratic parameters.
+         Control flags for other protocol idiosyncratic parameters must
+         be defined for each off-loaded protocol.
+
+      Data
+
+         After the Protocol Idiosyncratic Parameters, if any, and the
+         required <nl>, if the protocol in play allows for it at this
+         juncture the rest of the chunk will be interpreted as data to
+         be transmitted.  That is, in connection oriented protocols data
+         may or may not be permitted at connection initiation time, but
+         in connectionless protocols it certainly makes sense to allow
+         the H-FP Begin command to convey data. (This will also be
+         useful when we get to the Condition command.)
+
+      Responses
+
+         The following responses have been identified for the Begin
+         command:
+
+            000    Command completed successfully
+            101    Throughput not available; using maximum
+            102    Reliability not available; using maximum
+            103    Delay not available; using minimum
+            110    Flow Control advice not followed; smaller blocks used
+            111    Flow Control advice not followed; larger blocks used
+            201    Failed; Begin not implemented in this direction
+            202    Failed; timeout
+            203    Failed; Begin command on already active channel
+            300    Problem with multiple chunks
+            301    Syntax problem with Begin command
+            302    Protocol not supported in OPE/Host
+            303    Active service not available
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 19]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            304    Passive service not available
+            305    Invalid Foreign Address Primary Component
+            306    Invalid Transmit Discipline
+            307    Invalid Foreign Address Secondary Component
+            308    Invalid Local Address Secondary Component
+            309    Invalid Timeout Interval
+            310    Invalid Type of Service Advice
+            311    Invalid Flow control Advice
+            312    Invalid Local Address Primary Component
+            401    Protocol Interpreter in OPE not responding
+            402    Remote Protocol Interpreter not available
+            403    Failed; insufficient protocol interpreter resources
+            501    Failed; insufficient OPE resources
+            601    Request violates security policy
+            602    Security parameter problem
+
+         Additionally, protocol idiosyncratic responses will be defined
+         for each off-loaded protocol.
+
+      Example of Begin Command
+
+         The Begin command is the most complex of the H-FP Command
+         Level. When the off-loaded protocol is TCP, the Begin command
+         is used to open TCP connections.  One possible example of a
+         Begin command issued by an inboard Telnet interpreter to open a
+         TCP connection to ISIA, with no begin timeout interval, is:
+
+            C BE TCP A ISIA 9 N 23 ,, ,, N0 S <nl>
+
+         Where:
+
+            TCP    The code for the protocol TCP
+            A      Indicates Active Begin
+            ISIA   The name of a Host at USC-ISI
+            9      Mediation Level 9:  Full OPE mediation
+            N      Non-blocking transmit
+            23     Destination Telnet Port
+            ,,     skip  over parameters  (Local Address Secondary,
+                   Begin Timeout Interval)
+            N0     Type of Service Advice:  No special Advice,
+                   Normal Precedence
+            S      Flow Control Advice: use small blocks
+
+         This command will cause the OPE to invoke the TCP interpreter
+         to generate the initial SYN packet to the well-known Telnet
+         socket on Host ISIA.  It also informs the OPE to do all TCP
+         related processing via the Mediation Level, accepts default
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 20]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         Local Address parameters, and sets the Begin Timeout Interval
+         to infinity.  The precedence of the TCP connection is Normal,
+         and the TCP interpreter is informed that the data stream will
+         consist of primarily small blocks.
+
+      Notes to the Implementor
+
+         Response 203 might seem silly to some readers, but it's there
+         in case somebody goofed in using the Channel Layer.
+
+   Transmit
+
+      Purpose of the Transmit Command
+
+         The purpose of the Transmit command is to permit the process in
+         the Host to send data using an off-loaded protocol interpreter
+         in the OPE, and also to permit the OPE to deliver data received
+         from the network destined for the process in the Host.  The
+         Transmit command is particularly relevant to connection and
+         stream type protocols, although it has applications for
+         connectionless protocols as well.  After the Begin command is
+         issued successfully and the proper Response received, Transmit
+         commands can be issued on the given channel.  The semantics of
+         the Transmit command depend on whether it was issued by the
+         Host or the OPE.
+
+         - If the Host issues the Transmit command, a process in the
+         Host wishes to send the data to the destination specified to
+         the off-loaded protocol interpreter that was established
+         (typically) by a previous Begin command on the given H-FP
+         channel.
+
+         - If the OPE issues the command, the OPE has received data
+         destined for a process in the Host from a connection or stream
+         supported by the off-loaded protocol that was established by a
+         previous Begin command on the given H-FP channel.
+
+      Parameters of the Transmit Command
+
+         The Transmit command has one parameter associated with it. It
+         is an optional parameter, to temporarily override the response
+         discipline for this particular transmit command. Some protocols
+         may have protocol-idiosyncratic parameters as well.  The
+         transmit command also has data associated with it.  All
+         parameters must precede the data to be transmitted.
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 21]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+      Response Discipline Override
+
+         The Response Discipline Override parameter indicates the
+         desired response discipline for that individual Transmit
+         Command, overriding the default response discipline.  A single
+         ASCII character is used to indicate the desired discipline.
+         The character "N" indicates that this Transmit command should
+         not block, and should return a response as soon as the data is
+         given to the protocol interpreter in the OPE. The character "B"
+         indicates that this Transmit command should block, meaning that
+         a response should not be generated until the data has been sent
+         to the destination.  The default value of this parameter is the
+         currently defined Transmit Command response discipline.  The
+         use of this parameter does not alter the currently defined
+         Transmit command response discipline; the default is changed
+         with the Condition command.  The control flag for this
+         parameter is -rd.
+
+      Protocol-Idiosyncratic Parameters
+
+         Any other parameters to the Transmit command are
+         protocol-idiosyncratic. That is, each protocol that is
+         off-loaded has a set of these parameters, which are documented
+         with a description of the off-loaded protocol.  The default
+         value for these parameters is NULL, unless otherwise specified
+         by a particular off-loaded protocol.  The control flag for this
+         set of parameters is -pi, which identifies the first
+         protocol-idiosyncratic parameters.  Control flags for other
+         protocol-idiosyncratic parameters must be defined for each
+         off-loaded protocol.
+
+      Responses
+
+         The following responses for the Transmit command have been
+         identified:
+
+            000    Transmit Command completed successfully
+            201    Transmit Command not appropriate
+            300    Problem with multiple chunks
+            301    Syntax problem with Transmit Command
+            302    Invalid Transmit Command Response Discipline
+            401    Protocol Interpreter in OPE not responding
+            402    Failure in remote protocol interpreter
+            403    Failed; insufficient protocol interpreter resources
+            501    Failed; insufficient OPE resources
+            601    Request violates security policy
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 22]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         Additionally, protocol-idiosyncratic responses will be defined
+         for each off-loaded protocol.
+
+      Example of Transmit Command
+
+         The transmit command is used in TCP to provide the TCP write
+         call.  An example of such a transmit command would be:
+
+            C TR N <nl> <DATA>
+
+         Where N indicates non-blocking transmission discipline, <nl> is
+         the required command-ending newline, and <DATA> is presumed to
+         be the user's data that is to be transmitted.
+
+      Notes to the Implementor
+
+         If you get a 403 or a 501 response and have sent a multiple
+         chunk it probably makes sense to try a single chunk; if you've
+         sent a single chunk, it makes sense to wait a while and try
+         again a few times before giving up on the stream/channel.
+
+   Condition
+
+      Purpose of the Condition Command
+
+         The primary purpose of the Condition command is to permit a
+         process to alter the characteristics that were originally set
+         up with the Begin command. (That is, "condition" is a verb.)
+         These characteristics include the addresses, the mediation
+         level, the type of service, and the flow control parameters
+         from Begin. They may also include protocol-idiosyncratic
+         characteristics. (Although Condition is usually thought of as a
+         Host->OPE command, it may also be used OPE->Host in some
+         contexts.)
+
+         Condition is a generic command that may find little use in some
+         off-loaded protocols.  In others, only some of the parameters
+         identified may make sense.  For example, changing the
+         destination address of a TCP connection involves closing one
+         connection and opening another.  Consequently, in may make more
+         sense to first issue an End command, and then a Begin with the
+         new address.  In other protocols, such as IP or UDP, changing
+         the address on each datagram would be a perfectly reasonable
+         thing to do.
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 23]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+      Parameters of the Condition Command
+
+         The Condition command has the same parameters as the Begin
+         command.  Any parameters expressed in a Condition command
+         indicate the new values of the characteristics to be altered;
+         all parameters not expressed retain the current value.
+
+         Although it is possible to express the change of any of the
+         characteristics originally set up in the Begin command using
+         the Condition command, there are some characteristics that do
+         not make sense to alter, at least for some protocols. For
+         example, once a connection is opened, it does not make much
+         sense to change the Foreign Address Primary or Secondary
+         Components.  Doing so is inconsistent with current versions of
+         TCP, and would require the closing of the existing connection
+         and opening a new one to another address.  Earlier versions of
+         TCP did permit connections to be moved.  If a protocol that
+         provided such a feature was implemented in the OPE, the
+         changing the Secondary Address Components would be a reasonable
+         thing to do.
+
+      Responses
+
+         The responses to the Condition command are the same as those to
+         the Begin command.
+
+      Example of Condition Command
+
+         The Condition Command can be quite complex, and can be used for
+         many purposes.  One conceived use of the condition command
+         would be to change the type of service advice associated with
+         the channel. An example of this (which also demonstrates the
+         ability to skip parameters) is:
+
+            C -ts T <nl>
+
+         which causes the offloaded PI associated with the current
+         channel to attempt to achieve high throughput (in its use of
+         the comm subnet(s) in play).
+
+      Notes to the Implementor
+
+
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 24]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+   Signal
+
+      Purpose of Signal Command
+
+         The purpose of the Signal Command (implicitly at least) is to
+         permit the transfer of out-of-band signals or information
+         between the Host and the OPE, in order to utilize (explicitly)
+         out-of-band signaling services of the off-loaded protocol. The
+         semantics of the Signal command depend upon whether it was
+         issued by the Host or the OPE.
+
+         - If the Signal command was issued by the Host, it means a
+         process in the Host desires to send out-of-band data or an
+         out-of-band signal.
+
+         - If the Signal command was issued by the OPE, it means
+         out-of-band data or an out-of-band signal arrived for the
+         process associated with the channel in the Host.
+
+      Parameters of the Signal Command
+
+         The basic usage of the Signal command is with no parameters,
+         which sends or reports the receipt of an out-of-band signal.
+         Some protocols, such as the NBS Transport Protocol, permit the
+         user to send data with the out-of-band signal.  Hence, data is
+         permitted to accompany the Signal command.  There may also be
+         protocol-idiosyncratic parameters for the Signal command.  If
+         this is the case, these parameters would come before the data.
+
+      Protocol-Idiosyncratic Parameters
+
+         The parameters for the Signal command are protocol
+         idiosyncratic.  That is, each protocol off-loaded has a set of
+         these parameters.  The default value for these parameters is
+         their previous values. Control flags for multiple
+         protocol-idiosyncratic parameters must be defined for each
+         off-loaded protocol.
+
+      Responses
+
+         The following responses have been identified for the Signal
+         command:
+
+            000    Command completed successfully
+            201    Command not appropriate
+            300    Problem with multiple chunks
+            301    Syntax problem with Command
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 25]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            401    Protocol Interpreter in OPE not responding
+            402    Failure in remote protocol interpreter
+            403    Failed; insufficient protocol interpreter resources
+            501    Failed; insufficient OPE resources
+            601    Request violates security policy
+
+         Additionally, protocol-idiosyncratic responses will be defined
+         for each off-loaded protocol.
+
+      Example of Signal Command
+
+         The major perceived use for the Signal command when offloading
+         a connection protocol is sending an out-of-band signal with no
+         data.  In such a case, the appropriate signal command would be:
+
+            C SI <nl>
+
+      Notes to the Implementor
+
+         Some protocols may allow only only one outstanding signal at a
+         time.  For these protocols, it is an implementation issue
+         whether the OPE will buffer several signals, but a good case
+         could be made for the position that a scrupulous OPE would
+         reflect a 202 response back to the Host in such cases.
+
+         There is some question as to the proper handling of the
+         "expedited data" notion of some (particularly ISO) protocols.
+         It might be more appropriate to deal with such a thing as a
+         protocol idiosyncratic parameter on the Transmit command
+         instead of using the Signal command (even if it's the closest
+         approximation to an out-of-band signal in the given protocol).
+         If it's provided using the Signal command, the expedited data
+         should not be passed as ASCII, and should appear after the
+         command-terminating newline character (and appropriate padding
+         with space characters).
+
+   Status
+
+      Purpose of Status Command
+
+         The purpose of the Status command is to permit the Host to
+         request and obtain status information from the OPE, and vice
+         versa. This includes status request of a conventional protocol
+         interface (e.g., in TCP, there is a request to determine the
+         state of a particular connection).
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 26]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+      Parameters of the Status Command
+
+         The parameters for the Status command indicate whether it is a
+         request or a response, and contain the status information.
+
+         Request/Report
+
+            This parameter indicates whether the command is a Status
+            request or a Status report.  It consists of a single ASCII
+            character.  Q indicates a request (query), and R indicates a
+            report.  It should be noted that a report may be generated
+            as the result of a query, or may be generated as the result
+            of specific protocol mechanisms.
+
+      Protocol-Idiosyncratic Parameters
+
+         The parameters to the status command are
+         protocol-idiosyncratic. That is, each protocol off-loaded has a
+         set of these parameters.  The default value for these
+         parameters is their previous values.  Among these parameters is
+         an identifier of the type of status information contained or
+         requested, and a value or set of values that contain the
+         particular status information. The status information itself
+         should be the last item in the command. The control flag for
+         this set of parameters is -pi, which identifies the first
+         protocol-idiosyncratic parameters.  Control flags for other
+         protocol-idiosyncratic parameters must be defined for each
+         off-loaded protocol.
+
+      Responses
+
+         The following responses have been identified for the Status
+         command:
+
+            000    Command completed successfully
+            201    Command not appropriate
+            300    Problem with multiple chunks
+            301    Syntax problem with Command
+            302    Inappropriate status request
+            303    Inappropriate status response
+            401    Protocol Interpreter in OPE not responding
+            402    Failure in remote protocol interpreter
+            403    Failed; insufficient protocol interpreter resources
+            501    Failed; insufficient OPE resources
+            601    Request violates security policy
+            9xx    Protocol Idiosyncratic status responses
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 27]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+      Example of Status Command
+
+         The status command can be particularly complex, depending on
+         the protocol and particular type of status information.  One
+         possible use of the status command when off-loading TCP is to
+         communicate the status service request.  For performing this
+         operation the status command would be:
+
+            C ST Q <nl>
+
+      Notes to the Implementor
+
+   End
+
+      Purpose of the End Command
+
+         The purpose of the End command is to communicate that services
+         of the off-loaded protocol are not required.  The semantics of
+         the End command depends upon whether it was issued by the Host
+         or the OPE.
+
+         - If the Host issues the End command, it means the process in
+         the Host no longer requires the services of the offloaded
+         protocol.
+
+         - If the OPE issues the End command, it means the remote entity
+         has no more data to send (e.g., the off-loaded protocol is TCP
+         and the remote user has issued a TCP close).
+
+      Parameters of the End Command
+
+         One parameter is associated with the End Command.  It indicates
+         whether the termination should be "graceful" or "abrupt" (see
+         below).
+
+         Graceful/Abrupt
+
+            The Graceful/Abrupt parameter indicates whether the End
+            should be handled gracefully or abruptly.  If it is handled
+            gracefully, then data in transit is allowed to reach its
+            destination before service is actually terminated.  An
+            abrupt End occurs immediately; all data transmitted from the
+            Host but still pending in the OPE is discarded, and no new
+            incoming data is sent to the Host from the OPE.
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 28]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            The parameter is indicated by a single ASCII character.  The
+            character "G" denotes graceful, and "A" denotes abrupt.  The
+            default value for this parameter is graceful.
+
+      Responses
+
+         The following responses have been identified for the End
+         command:
+
+            000    Command completed successfully
+            201    Command not appropriate
+            300    Problem with multiple chunks
+            301    Syntax problem with Command
+            302    Illegal Type of End Command
+            401    Protocol Interpreter in OPE not responding
+            402    Failure in remote protocol interpreter
+            403    Failed; insufficient protocol interpreter resources
+            501    Failed; insufficient OPE resources
+            601    Request violates security policy
+
+         Additionally, protocol idiosyncratic responses will be defined
+         for each off-loaded protocol.
+
+      Example of End Command
+
+         The syntax of the End command is relatively straightforward. It
+         consists of a chunk that contains only a chunk usage
+         identifier, the end command string, and the parameter
+         indicating whether the end should be graceful or abrupt.  A
+         possible valid (abrupt) End command would be:
+
+            C EN A <nl>
+
+      Notes to the Implementor
+
+         Once an End has been issued in a given direction any other
+         commands on the channel in the same direction are in error and
+         should be responded to appropriately.
+
+
+
+
+
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 29]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+   No-op
+
+      Purpose of the No-op Command
+
+         The No-op command performs no operation.  Its purpose is to
+         permit the Host and OPE to participate in a dialog which does
+         not alter the state of communication activities, both for
+         debugging purposes and to support features of certain protocols
+         (e.g., Telnet's Are You There command).
+
+      Parameters of the No-op Command
+
+         There are no parameters associated with the No-op command.
+
+      Responses
+
+         There are only two possible legal responses to the No-op
+         command.  They are:
+
+            000    No-op Command Completed Correctly
+            300    Problem with multiple chunks
+
+      Example of No-op Command
+
+         Syntactically the No-op command is quite simple.  It consists
+         of a chunk that contains only the chunk usage identifier and
+         the string for the command, and the newline.  One possible
+         valid No-op command is:
+
+            C NO <nl>
+
+      Notes to the Implementor
+
+         No-ops are included for use in testing and initial
+         synchronization.  (The latter use is not mandatory, however.
+         That is, no exchange of No-ops is required at start-up time,
+         but it is conceivable that some implementations might want to
+         do it just for exercise.) They are also traditional.
+
+
+
+
+
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 30]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+References
+
+   (References [1]-[3] will be available in M. A. Padlipsky's "The
+   Elements of Networking Style", Prentice Hall, 1985.)
+
+   [1] Padlipsky, M. A., "The Host-Front End Protocol Approach",
+   MTR-3996, Vol. III, MITRE Corp., 1980.
+
+   [2] Padlipsky, M. A., "The Elements of Networking Style", M81-41,
+   MITRE Corp., 1981.
+
+   [3] Padlipsky, M. A., "A Perspective on the ARPANET Reference Model",
+   M82-47, MITRE Corp., 1982.
+
+   [4] Bailey, G., "Network Access Protocol", S-216,718, National
+   Security Agency Central Security Service, 1982.
+
+   [5] Day, J. D., G. R. Grossman, and R. H. Howe, "WWMCCS Host to Front
+   End Protocol", 78012.C-INFE.14, Digital Technology Incorporated,
+   1979.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 31]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+APPENDIX
+
+   Per-Protocol Offloading Descriptions
+
+   1.  Command Level Interface to an Off-loaded TCP
+
+      This appendix discusses the use of the commands described in the
+      body of this document to provide an interface between a Host
+      process and an off-loaded interpreter of the DoD's Transmission
+      Control Protocol (TCP).  The interface described here is
+      functionally equivalent to the interface found in the MIL-STD 1778
+      specification of TCP.  It is not, however, identical, in that some
+      features of the interface are particularly relevant only in an
+      inboard implementation.
+
+      The first section describes the mapping between the interface
+      events of MIL-STD 1778 and the commands and responses of this
+      H-FP, and highlights the unique features of the interface.  The
+      next sections discuss the details of each command.  These details
+      include the specialized usages of the command and the
+      protocol-idiosyncratic parameters for that command.
+
+      1.1.  Relation to MIL-STD 1778 Interface
+
+         Most of the requests and responses of the TCP interface
+         specified in MIL-STD 1778 are mapped directly to H-FP Commands
+         and responses.  The exceptions are noted in the following
+         descriptions.
+
+         1.1.1. Requests
+
+            Unspecified Passive Open, Fully Specified Passive Open,
+            Active Open, and Active Open with Data requests are all
+            implemented using variations of the Begin command.  The
+            distinction between Passive and Active Open is made using
+            the Active/Passive parameter of Begin.  The distinction
+            between unspecified and fully specified lies in the presence
+            or absence of the destination address fields.  An active
+            open with data is identical to a normal active open, except
+            for the presence of data following the command.
+
+            The Send Service Request is implemented using the Transmit
+            command.  Special protocol idiosyncratic parameters are
+            provided for Urgent, Push, and changing the ULP timeout
+            action and values.  The response to the Transmit command
+            indicates that the appropriate Send call has been made.
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 32]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            There is no corresponding response in the specified TCP
+            interface; its only significance is that the Host can issue
+            another Transmit command.
+
+            The Allocate event is a specification feature of MIL-STD
+            1778 to indicate the willingness of the user to accept
+            incoming data across the interface.  However, because this
+            is precisely the type of flow control provided by the
+            Channel level, the Allocate event would be a superfluous
+            mechanism.  Thus, there is no direct analogy to that event
+            in the H-FP interface. A Host process indicates its
+            willingness to accept new data by informing the channel via
+            its flow control interface (if it has an explicit one).
+
+            Close and Abort are provided by the End command.  Close uses
+            the graceful version of the End command, while Abort uses
+            the abrupt version.  The response indicates that the End
+            command has been received and the corresponding Close or
+            Abort was issued.  There is no corresponding response in the
+            specified TCP interface.
+
+            Status is provided by using the query form of the Status
+            command.  The response to the Status command contains the
+            information (see below).
+
+         1.1.2. Responses
+
+            The Open Id response is provided so that the user has a
+            shorthand name by which to refer to the connection.  With an
+            outboarded TCP interpreter, there is a one-to-one mapping
+            between TCP connections and H-FP channels.  Hence, the Open
+            Id event is not needed, since the channel ID is sufficient
+            to indicate the desired connection.
+
+            The Open Failure and Open Success responses are provided
+            using OPE-generated responses to Begin commands (which
+            provide the Active and Passive Service response primitives)
+            issued by the Host.  The value of the response code
+            indicates whether the Begin command succeeded or failed, and
+            can be mapped to the appropriate Open Failure or Open
+            Success indication by the Host.
+
+            Deliver is provided by having the OPE issue a Transmit
+            command.  As mentioned above, the "flow control" between the
+            TCP interpreter and the Host is provided by the Channel
+            layer, so no explicit interface events are needed.  The
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 33]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            response to the Transmit command indicates the data was
+            received by the Host process.  There is no corresponding
+            response in the specified TCP interface.
+
+            The Closing and Terminate service responses are provided
+            using the End command. Closing is indicated using the
+            graceful version of the command, while terminate is provided
+            using the abrupt version.  The response indicates the End
+            command was received by the Host process.  There is no
+            corresponding response in the specified TCP interface.
+
+            Status Response is provided by a response to the query
+            version of the Status command.  The status information is
+            communicated via protocol-idiosyncratic parameters following
+            the Response code.
+
+            Error messages are reported using the spontaneously
+            generated version of the Status command issued by the OPE.
+            The error message is provided in a parameter.  The response
+            indicates the error message was received by the Host
+            process.  There is no corresponding event in the specified
+            TCP interface.
+
+      1.2.  The Begin Command
+
+         The Begin command is used in TCP in three major ways:
+
+            1. To inform the OPE that a process in the Host wishes to
+            open a connection to a particular port on a internet
+            address.
+
+            2. To inform the OPE that a process in the Host wishes to be
+            informed when a connection attempt is made to any or to a
+            specific port at this Host's internet address.
+
+            3. To inform the Host that a connection attempt to the OPE
+            has arrived, and there was no Begin of the second type
+            (passive open) issued by the Host relevant to that
+            particular port.
+
+         1.2.1. Specialized Usage
+
+            There are four major aspects to the specialized usage of the
+            Begin command and its parameters.  These parameters are:
+
+               1. The meaning of the Mediation Level parameter
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 34]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+               2. The selection of blocking treatment of Transmit
+                  command
+
+               3. The meaning of the address components
+
+               4. The selection of the TCP Active Open with Data
+                  primitive.
+
+            The Mediation Level parameter has only two possible values
+            when offloading TCP.  These are "9" and "0".  The normal
+            usage of an off-loaded TCP uses the value "9", which means
+            the Host is in no way involved in the operation of TCP.  The
+            value "0" indicates the Host wishes to negotiate with the
+            TCP options.
+
+            The normal TCP Send event is non-blocking.  That is, when a
+            user issues the send command, it counts on the reliability
+            services of TCP, and is not explicitly notified when the
+            data has reached the other end of the connection and been
+            properly acknowledged. Hence, the default value for this
+            parameter with TCP is "N".  There are some applications
+            where the user may not wish to receive a response to a
+            Transmit command until the data has been acknowledged by the
+            other end of the connection.  In these cases, the value "B"
+            should be used for this parameter.  If such a feature is not
+            supported by the offloaded TCP interpreter, then it is
+            acceptable to issue a 100 level Conditional acceptance
+            indicating that blocking is not supported, but the Begin
+            command will proceed using non-blocking Transmits.
+
+            The primary address components of the local and remote
+            addresses refer to the internet addresses of (or a symbolic
+            Host name for) the respective Hosts.  The secondary
+            components refer to the particular sockets at those internet
+            addresses.  Normally, the secondary components (ports) are
+            specified numerically. They may, however, be specified by
+            name if the port is a well-known service port. In an Active
+            Begin command, the remote addresses primary and secondary
+            components must be specified.  The local address components
+            need not be specified, unless the user wishes to indicate
+            that the connection should be from a particular port or a
+            particular internet address of a multi-homed Host.  In a
+            Passive Begin command, the remote addresses are specified
+            only if connection attempts from one particular Host are of
+            interest.  The local address secondary component must be
+            used to indicate on which port to perform the Listen.
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 35]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            The way the TCP Active Open with data is provided is by
+            including the data with the Begin Command.  This data is
+            included in the same Channel level chunk, immediately
+            following the newline.  If the data is more than a single
+            chunk can hold, then the multi-chunk command feature of the
+            H-FP must be used.
+
+         1.2.2. Protocol-Idiosyncratic Parameters
+
+            The protocol-idiosyncratic parameter identified for the TCP
+            interface is the "ULP timeout" information.  This
+            information includes whether the offloaded interpreter
+            should abort the connection on a ULP timeout or report it to
+            the inboard user, and also the numerical value of the
+            timeout interval. The format chosen for this parameter is a
+            single letter followed immediately (with no spaces) by an
+            ASCII number. The letter can be either "R" or "A", and
+            indicates that the ULP timeout should cause a report or an
+            abort, respectively. The number is interpreted to be the
+            timeout interval in seconds.
+
+         1.2.3. Examples of the Command
+
+            An example of an Active Begin command that might be issued
+            by an inboard user Telnet is:
+
+               C BE TCP A ISIA 9 N 23 ,, 60 R 0 -pi R120 <nl>
+
+            ISIA is the destination Host, 23 is the well-known port
+            number for Telnet connections, a Begin timeout of 60 seconds
+            was chosen.  The desired type of service is to strive for
+            good response time, the transmissions are expected to be in
+            small units, and protocol-idiosyncratic parameter R120
+            implies that a ULP timeout of 120 seconds should be
+            reported.
+
+            An example of a Passive Begin Command that might be issued
+            by an inboard server Telnet is:
+
+               C BE TCP P ,, 9 N ,, 23 ,, R 0 -pi R120 <nl>
+
+            The major differences are that no remote address components
+            are specified, and the local secondary address component is
+            identified as the socket on which the Listen is being
+            performed.  Also, the default ("infinite") timeout is taken.
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 36]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+      1.3.  The Transmit Command
+
+         The Transmit command is used by the Host process to instruct
+         the off-loaded TCP interpreter to send data to a remote site
+         via the TCP connection associated with the command's channel.
+         It is used by the OPE to deliver incoming data from the
+         connection to the process in the Host.
+
+         1.3.1. Specialized Usage
+
+            The Transmit command must be capable of providing all the
+            specialized features of the Send and Deliver Event.  These
+            special features are Urgent, Push, and modification of the
+            ULP Timeout action and/or interval.
+
+            Urgent is a means to communicate that some point upcoming in
+            the data stream has been marked as URGENT by the sender.
+            While the actual Urgent bit travels through the connection
+            out-of-band, it carries a pointer that is related to the
+            sequence numbers of the in-band communication. Hence, the
+            urgency must be indicated in the Transmit command rather
+            than the Signal command.
+
+            Push is a feature of the TCP Send Event that is used to
+            indicate that the data in the Transmit command should be
+            sent immediately (within the flow control constraints),
+            rather than waiting for additional send commands or a
+            timeout.  Push is indicated in the Transmit Command. The
+            push feature has the same meaning when sent from the OPE to
+            the Host.  If the Host implementation does no internal
+            queuing, the flag has no meaning.
+
+            The TCP Send event permits the user to modify the "ULP
+            timeout action" and/or the "ULP timeout interval" associated
+            with that connection.  When changed, the new values take
+            effect for the remainder of the connection, unless changed
+            later with another Send.  This feature is provided in this
+            H-FP using the Transmit Command.
+
+         1.3.2. Protocol-Idiosyncratic Parameters
+
+            The three features identified above are provided using
+            protocol-idiosyncratic parameters.
+
+            The first such parameter is the Urgent parameter.  From the
+            point of view of the interface, it is just a flag that
+            indicates the data is urgent (the actual Urgent pointer is a
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 37]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            concern of the off-loaded TCP interpreter, which is keeping
+            track of the sequence numbers).  When issued by the Host
+            process, the Urgent flag means the stream should be marked.
+            When issued by the OPE, it means the receiver should go to
+            (or remain in) the Urgent receive mode.  If the flag is not
+            set in the Transmit issued by the OPE, then the receiver
+            should remain in (or return to) the non-urgent receive mode.
+            The value of this protocol-idiosyncratic parameter is "U" if
+            the Urgent is set, or "N" if it is not set.  The default
+            value for this parameter is "N".  Since this parameter is
+            the first protocol-idiosyncratic parameter for the Transmit
+            command, it requires no special flag, and can be indicated
+            using the flag -pi.
+
+            The second protocol-idiosyncratic parameter is the Push
+            flag.  This parameter is only issued by the Host, since
+            there is no Push in the TCP Deliver event.  Its value is "P"
+            for push, or "N" for normal.  The default value of this
+            parameter is "N".  Its control flag is -pu.
+
+            The third protocol-idiosyncratic parameter is the ULP
+            timeout action and value parameter.  The action part
+            indicates whether the offloaded interpreter should abort the
+            connection on a timeout or report it to the inboard user.
+            The value part is the numerical value of the timeout
+            interval.  The format used for this parameter is the same as
+            in the Begin command, which is a single letter followed
+            immediately (with no spaces) by an ASCII number.  The letter
+            can be either "R" or "A", and indicates that the ULP timeout
+            should cause a report or an abort, respectively.  The number
+            is interpreted to be the timeout interval in seconds.  The
+            default interpretation for this parameter is its previous
+            value. The control flag for this parameter is -ul.
+
+         1.3.3. Examples of the Command
+
+            An example of a Transmit command issued by a Host process is
+
+               C TR -pi N P R160 <nl> <DATA>
+
+            where <DATA> is the data contained within the chunk.  This
+            command is for a non-urgent but pushed TCP Send event, that
+            also resets the timeout action and interval to Report with a
+            value of 160 seconds. The response mode (i.e., nonblocking)
+            is derived from the Begin command and not effected by
+            transmit.
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 38]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            An example of a Transmit command issued by the OPE is
+
+               C TR -pi N <nl> <DATA>
+
+            where <DATA> is the data contained within the chunk.  This
+            command is for a non-urgent delivery (presumably, after a
+            previous Urgent delivery).
+
+      1.4.  The Condition Command
+
+         The Condition command is used to modify the transmission
+         characteristics of the connection.  The parameters that make
+         sense to modify with TCP are the Transmit Response discipline,
+         the Type of Service, and the Flow Control Advice.
+
+         1.4.1. Specialized Usage
+
+            There is no usage of the Condition command with an offloaded
+            TCP interpreter that is particularly specialized.
+
+         1.4.2. Protocol-Idiosyncratic Parameters
+
+            There are no protocol-idiosyncratic parameters for the
+            condition command for the off-loaded TCP. It would be
+            possible for the ULP timeout action values to be changed
+            with a condition command.  However, this is accomplished
+            with the Transmit command, which more closely models the
+            interface specified in MIL-STD 1778.  We propose that the
+            condition command not provide this capability.
+
+         1.4.3. Examples of the Command
+
+            An example of the Condition command to change the flow
+            control advice for a connection is
+
+               C CO -fc 1 <nl>
+
+            which indicates that relatively small transmission units are
+            now expected.
+
+
+
+
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 39]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+      1.5.  The Signal Command
+
+         As we currently understand it, TCP's URGENT feature provides an
+         INband signal rather than a true out-of-band signal (and at
+         least one of us deeply regrets this).  The actual URGENT bit is
+         sent out-of-band, but it contains an URGENT pointer which
+         relates the URGENT to its position in the data stream.  The
+         actual semantics of the URGENT is left to the higher level
+         protocol (e.g., Telnet says to discard all data up to the
+         URGENT pointer).  Since the Signal command is allowed to cross
+         a pending Transmit in the H-FP channel, it would be potentially
+         dangerous to implement the interface to TCP URGENT using the
+         Signal command since the wrong sequence number could be used as
+         the urgent pointer.  Barring persuasive arguments to the
+         contrary, it is proposed that Signal should not be used with
+         TCP.
+
+      1.6.  The Status Command
+
+         The Status command maps directly into the TCP Status event when
+         issued by a Host process. It is also used for the TCP error
+         event when issued by the OPE.  There is currently some question
+         as to how information from lower protocol levels (e.g., ICMP
+         error messages) should be reported to TCP users. When these
+         issues are resolved, there may be other uses for the Status
+         command.  We solicit other ideas for the Status command with
+         this report.
+
+         1.6.1. Specialized Usage
+
+            The major specialized usage of the Status command is to
+            provide the error reporting service.  This usage is a form
+            of the Status generated by the OPE.
+
+         1.6.2. Protocol-Idiosyncratic Parameters
+
+            When used as a TCP Status request (command issued by the
+            Host process), there are no protocol-idiosyncratic
+            parameters associated with the Status command.  The OPE
+            response codes the TCP status.
+
+            When used as a TCP error report (command issued by the OPE),
+            there is one protocol-idiosyncratic parameter associated
+            with the Status command.  It is an error description in the
+            form of a text string. It requires no special control flag
+            since the flag -pi is unambiguous and there are no other
+            protocol-idiosyncratic parameters.
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 40]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         1.6.3. Examples of the Command
+
+            An example of the Status command issued by the Host process
+            to request status information is
+
+               C ST Q <nl>
+
+            The status information is returned in the response to the
+            status command.
+
+            An example of the Status command issued by the OPE to report
+            an error from the TCP interpreter is
+
+               C ST R -pi "Connection already exists" <nl>
+
+            which is issued when a TCP open (HFP Begin) is issued to an
+            already opened (foreign) connection.
+
+      1.7.  The End Command
+
+         The End command is used to indicate that TCP services are no
+         longer required.  Thus, it can be mapped into either the TCP
+         Graceful Close or the TCP Abort events.  It is also used as the
+         TCP Closing response (as contrasted with the response by the
+         OPE to the close command), when issued by the OPE.
+
+         1.7.1. Specialized Usage
+
+            Because of the nature of the two-way close provided by TCP,
+            there is a possibility that the Host and the OPE wish to
+            gracefully terminate the connection at the same instant.  If
+            this happens, then both the Host and the OPE would issue End
+            commands at the same time.  To be prepared for this, it is
+            necessary to make this the normal graceful closing sequence.
+            In other words, both the Graceful Close request and the
+            Closing response are mapped to End commands, and the
+            response to one of those commands only indicates that the
+            command has been received and executed, but not that the
+            connection is actually fully closed.  The connection is
+            gracefully closed when both End commands have been issued,
+            and both successful responses have been received.
+
+            With an abrupt end, a two-way exchange is not necessary.
+            Only the Host or the OPE need issue it, for the connection
+            to be aborted.
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 41]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+         1.7.2. Protocol-Idiosyncratic Parameters
+
+            There are no protocol-idiosyncratic parameters for the End
+            command used with TCP.
+
+         1.7.3. Examples of the Command
+
+            An example of the End command used to indicate either a TCP
+            Close request (from the Host process) or TCP Closing
+            response (from the OPE) is
+
+               C EN G <nl>
+
+            An example of the End command used as an Abort request (from
+            the Host process) or as a Terminate response is
+
+               C EN A <nl>
+
+   2.  Command Level Interface to an Off-loaded Telnet
+
+      This appendix is provided to discuss the use of the commands
+      described in the body of this document to provide an interface
+      between a Host process and an off-loaded interpreter of the Telnet
+      protocol.
+
+      The interface described here is not based on a formal interface.
+      There are several reasons for this, including the lack of a widely
+      accepted standard interface to Telnet, and its headerless nature.
+      Consequently, the interface described here is very similar to the
+      actual Telnet data stream.
+
+      2.1.  The Begin Command
+
+         The Begin command is used with Telnet to initiate Telnet
+         connections.
+
+         2.1.1. Specialized Usage
+
+            There are three major specialized usages to the Begin
+            command.  They are the meaning of the Mediation Level
+            parameter, the way the number of incoming Telnet connections
+            are supported, and the meaning of the secondary address
+            components.
+
+            The mediation level is used in Telnet to control which of
+            the various Telnet activities are performed by the OPE, and
+            which are controlled by the Host.  It has been determined
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 42]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            that all monitoring of the Telnet Socket should be performed
+            by the OPE.  Mediation level 9, which is the default,
+            indicates the Host desires to play no role in Telnet
+            operation. Level 5 means that protocol-idiosyncratic
+            parameters to this Begin command indicate which incoming
+            options the Host wishes to handle; all other options, and
+            all NVT translations, are to be performed by the OPE. Level
+            0 indicates that the Host will handle all options, while all
+            NVT translations are to be performed in the OPE (see Section
+            B.1.3).
+
+            The Host can either accept the connections by fielding OPE
+            generated Begins, or by issuing passive Begins to the OPE.
+            The Host may wish to restrict the number of incoming Telnet
+            connections that it will handle at any particular time.  It
+            can do this by rejecting OPE-generated Begins above a
+            certain number, or by limiting the number of Host-issued
+            passive Begins.  However, precedence constraints dictate
+            that the Host actually issue additional passive Begins or
+            accept additional Begins from the OPE beyond the maximum
+            number it is normally willing to support, so that
+            high-priority service requests can be accommodated, possibly
+            by preempting lower priority activities.
+
+            The secondary address component is used to refer to specific
+            ports. Normally, they are used only when the standard or
+            default ports are not used, such as special purpose
+            applications or testing.
+
+         2.1.2. Protocol-Idiosyncratic Parameters
+
+            The protocol-idiosyncratic parameters to the Telnet Begin
+            command are the identifiers for the options which the host
+            wishes to negotiate when using mediation level 5.  On other
+            mediation levels, these parameters are not used.
+
+         2.1.3. Examples of the Command
+
+            An example of a passive Begin for an outboard Telnet
+            protocol is:
+
+               C BE TEL P ,, 5 N -fc 0 -pi 9 <nl>
+
+            Where the parameters are:
+
+               TEL   Code for the Telnet Protocol
+               P     Passive Begin
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 43]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+               ,,    Skip the Foreign Address Primary Component
+               5     Mediation Level is 5
+               N     Non Blocking Transmits
+               -fc   Skips over parameters up to Flow Control Advice
+               S     Small Blocks are appropriate for Telnet
+               -pi   Skips over parameters to the Protocol Idiosyncratic
+                     List of Options to be Handled by the Host.
+               9     Option Code for Line Length Option
+
+            Here, no remote address component was specified, since the
+            Host will accept connections from any Host.  Similarly, no
+            local addresses are specified, since the default well-known
+            socket for this Host is to be used.  In this example, the
+            Host specifies it will handle the line length option (number
+            9).  Other options are handled in the OPE.
+
+            An example of an active Begin for an outboard Telnet
+            protocol is:
+
+               C BE TEL A ISIA 5 N -fc 0 -pi 9 <nl>
+
+            This command is identical to the passive command, except
+            that a remote primary address component is specified to
+            identify the intended Host.  No remote secondary component
+            is specified, since the well-known socket at that Host is to
+            be used.  No local secondary address components are
+            specified, since the connection can originate from any
+            available socket of the appropriate type selected by the
+            OPE.
+
+      2.2.  The Transmit Command
+
+         The Transmit Command is used to send data across a Telnet
+         connection.
+
+         2.2.1. Specialized Usage
+
+            The Transmit command is used to transmit data over the
+            Telnet connection.  There is one specialized aspect of the
+            Transmit command used with an outboard Telnet interpreter.
+            This is the provision of the Go Ahead feature of Telnet that
+            supports half-duplex devices.
+
+            Go Ahead is provided as a protocol idiosyncratic parameter
+            to the Transmit.  It is only used if the Host will support
+            it, however.  It is our opinion that Go Ahead is probably
+            not a proper thing for the default case.
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 44]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            Go Aheads are a matter between the Host and the terminal. It
+            is difficult to offload the generation of Go Aheads to the
+            OPE, since the OPE is not really cognizant of the semantics
+            of the communication between the Host and the terminal.
+            Hence, the OPE does not know when the Host is done
+            transmitting and willing to pass "the turn" back to the
+            terminal. Similarly when the remote site relinquishes
+            control, the OPE includes Go Ahead in its TR.
+
+            We don't believe this Go Ahead problem to be an indictment
+            against outboard processing.  It merely illustrates that
+            functionality not found in a Host cannot necessarily be
+            provided by the OPE.  Hence, we provide this note to the
+            implementor:  if the Host cannot generate the
+            protocol-idiosyncratic Go Ahead parameter, then the DO
+            Suppress Go Ahead must be issued immediately after the
+            connection is established.
+
+         2.2.2. Protocol Idiosyncratic Parameters
+
+            The protocol idiosyncratic parameter is the Go Ahead
+            indicator.  When present, the character "G" is used to mean
+            the Go Ahead can be sent to the other end of the connection,
+            but only after the data associated with that Transmit
+            command is sent.  When the character is any other value, or
+            is absent, the Go Ahead should not be sent.
+
+         2.2.3. Examples of the Command
+
+            An example of the Transmit command is:
+
+               C TR -pi G <nl> <DATA>
+
+            With this command, the Go Ahead is passed to the other side
+            after the data is sent.
+
+      2.3.  The Condition Command
+
+         The Condition command is used with Telnet to modify the
+         Transmission characteristics and to enable or disable Telnet
+         options on a Telnet connection.
+
+         2.3.1. Specialized Usage
+
+            The Condition command takes on specialized usage with
+            Telnet, in addition to its normal usage.  It is used to
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 45]
+
+
+
+RFC 929                                                    December 1984
+Proposed Host-Front End Protocol
+
+
+            control the option selection and negotiation process, when
+            such selection is performed by the Host (currently, this is
+            done at mediation levels 5 and 1, but not at level 9).
+
+            A set of protocol-idiosyncratic parameters has been defined
+            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
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 46]
+
+
+
+RFC 929                                                    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
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 47]
+
+
+
+RFC 929                                                    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.
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 48]
+
+
+
+RFC 929                                                    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
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 49]
+
+
+
+RFC 929                                                    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
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 50]
+
+
+
+RFC 929                                                    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
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 51]
+
+
+
+RFC 929                                                    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
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 52]
+
+
+
+RFC 929                                                    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>
+
+
+
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 53]
+
+
+
+RFC 929                                                    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.
+
+
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 54]
+
+
+
+RFC 929                                                    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>
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 55]
+
+
+
+RFC 929                                                    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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lilienkamp & Mandell & Padlipsky                               [Page 56]
+