rfc929.txt

RFC 相关的技术文档

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