rfc357.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

            is or is not a member of that class.  The server sends a
            "Set Break Classes" command (1st byte) followed by a
            formatted control word (2nd byte) to the TIP with bit
            positions set for those equivalence classes which represent
            break classes for the server process.

            When a (virtual) character is taken from the input buffer
            the TIP does a table look-up indexed by the character.  If a
            simple ANDing of the table entry with the terminal's control
            word yields a non-zero result, a break was received.
            (Receipt of a break character enables the OUTPUT path.)

        (4) Move to Break (MTB).  This command directs the TIP to move
            characters in sequence from the input buffer to the print
            buffer until a break character is encountered.  The break
            character will be moved or discarded depending on the
            previously-specified break action.  (Essentially, MTB
            enables the ECHO path.)

        (5) Delete to Break (DTB).  This command directs the TIP to move
            characters in sequence from the input buffer and discard
            them until a break character is encountered.  The break
            character will also be discarded.  This provides a
            convenient mechanism for hiding a user's input.  (DTB



Davidson                                                        [Page 7]

RFC 357         An Echoing Strategy For Satellite Links        June 1972


            enables the DISCARD path.)

   Commands: User to Server

            The USER may send (via TIP) a request to the server process
            requesting that it "Use Remote Controlled Echoing" to which
            the server must respond "YES" or "NO".

   General Operation

      Very simply, the Remote Controlled Echoing strategy works as
      follows: The Server TELNET will tell the TIP to (essentially)

         (1) echo a message,
         (2) print the process' response to that message,
         (3) echo the next message
         (4) print the response to that message
                      . . .

      etc., to effect an orderly listing of inputs and responses much as
      would be imposed when using a half-duplex device.

      The actual interaction depends on the control commands.  When a
      terminal-serving process is invoked on behalf of a TIP user, the
      Server TELNET will send the "Use RCE" command; the TIP will
      respond "YES".  Then the Server TELNET will send the "Set Break
      Action" and "Set Break Classes" commands to properly reflect the
      break strategy requested by the terminal-serving process.  Lastly
      the Server TELNET will send an MTB command.  This enables the ECHO
      path.

      The TIP removes characters from the input buffer and places them
      in the print buffer.  When it encounters a break character, it
      performs the break action specified, and enables the OUTPUT path.

      Characters are then moved in sequence from the output buffer to
      the print buffer.  When an MTB (or, DTB) is encountered, it is
      discarded and the ECHO (DISCARD) path is enabled.

      Etcetera.

      The Server TELNET may change the break action or break classes
      after an interaction, but should normally do so prior to sending
      the MTB or DTB commands.  It should only send an MTB (DTB) after
      all process output from the previous message has been sent.






Davidson                                                        [Page 8]

RFC 357         An Echoing Strategy For Satellite Links        June 1972


   Why Does This Work?

      The RCE strategy described above produces the correct result at
      the user's terminal because it is in essence the same scheme used
      by the Terminal Handler which normally provides the echoing at the
      serving site.  Initially, the characters are echoed as they are
      typed; then a break character is keyed, echoing is suspended.  If
      the process produces any output response, it is printed before
      echoing of subsequent input.

      Echoing of the next command begins, if there is type-ahead, with
      the characters in the input buffer, and even if the input buffer
      is emptied immediate echoing of keyed input from the terminal is
      provided since the ECHO path remains enabled up to a break.

   An Example

      (In the following, we assume all break characters are also wakeup
      characters and (carelessly) treat the two interchangeably.)

      Suppose a TIP user attempts to login to a remote server with the
      properly formatted message

            LOG NAME PASSWORD [CR]

      and that the Server TELNET has requested the use of RCE.
      Presuming that the break (and wakeup) characters sets are
      appropriately defined to include space and CR (and that the break
      action specifies they should be echoed), the primary sequence of
      RCE commands which will drive the TIP to produce the correct
      printout at the user's terminal is:

         (1) MTB (to print "LOG "), and since the space is a break
            character,
         (2) MTB (to print "NAME "),
         (3) DTB (to delete "PASSWORD [CR]" (See section VI, number
            11)), and perhaps a message followed by
         (4) MTB (to reenable the echo path).

      We investigate in some detail how interaction at the
      process/Server TELNET interface causes these commands to be send
      to the TIP.

      When the EXEC is invoked, it issues a system call to set its break
      classes.  The Server TELNET interprets the system call in terms of
      the classes supported by RCE, and sends the appropriate two-byte
      "Set Break Classes" (SBC) command to the TIP.  A space is among
      the characters of the break set.



Davidson                                                        [Page 9]

RFC 357         An Echoing Strategy For Satellite Links        June 1972


      The EXEC asks for input, so the Server TELNET send MTB ((1)
      above).  We presume the EXEC blocks until some input is available.

      The EXEC is awakened when the first space arrives; it recognizes
      the LOG command to be a call upon the LOGIN subsystem which it
      (promptly!) invokes.

      The LOGIN process issues a system call to set its break classes
      (this time both space and CR are included, and, as before, the
      Server TELNET forwards the command as an SBC).  Then it asks for
      input (so the Server TELNET sends MTB ((2) above)), and blocks
      until the second space arrives.

      When the LOGIN process has verified the existence of a user with
      name NAME, it issues a system call to suppress printing of the
      next parameter (the password).  In compliance, the Server TELNET
      sends DTB ((3) above).

      Once the password has been examined and verified, a message like

            [CR][LF] LOGIN COMPLETED [CR][LF]

      can be sent, followed by a request for input.  The Server TELNET
      thus forwards an MTB ((4) above) and the sequence is completed.

   Another example

      Suppose in the above example the user had typed

            LOG NAME[CR]

      When the LOGIN process regained control, it would have noted that
      the break was a CR instead of a space.  It then could have issued

            [LF]password =

      which the Server TELNET would follow (when LOGIN requests print
      suppression) with DTB.  When the TIP had finished its output, the
      DISCARD path would be enabled and the user's terminal would have
      printed:

            LOG NAME[CR]
            password =
                       ^

      with the cursor positioned just after the =.  The TIP will hide
      the characters of the password.




Davidson                                                       [Page 10]

RFC 357         An Echoing Strategy For Satellite Links        June 1972


   Another Example

      Suppose a user were using a text editor, TEXT, to create a source
      file of English sentences.  The TEXT subprocess might allow only
      non-formatting control characters (e.g., "Control-C") as break
      characters.  The RCE strategy would allow the user to receive
      immediate echoing for all his input until he typed such a control
      character.

V. Discussion

   The Remote Controlled Echoing Strategy is designed to provide echoing
   for a full-duplex terminal as if it were locally connected to its
   server.  The effect of the long transmission delays will only be
   evident as an increase in the processing performed at a break.  Only
   in the most interactive systems will such a delay be consistently
   noticeable.  For example if a user invokes a long FORTRAN
   compilation, the fact that its start is delayed for half a second
   will not normally be evident.

   Furthermore, users who are able to type several messages ahead may
   only notice a processing delay as a result of the first break-
   interaction; both transmission and processing of successive messages
   may occur during the printing of "echoes" and responses to previous
   messages.

   Transmission considerations:

      In the standard echoing scheme, characters are buffered at the
      same server as they are keyed.  But the user process does not see
      them until a wakeup character has been typed.  This means a TIP
      using RCE could buffer characters in the transmission buffer until
      a wakeup occurs and then send off the whole bunch.  Unfortunately
      we have chosen, for simplicity, to keep all knowledge of wakeup
      characters at the serving site.  This means that the TIP may
      buffer beyond a wakeup (if it is not also a break) and delay the
      process from doing some useful work.  However, since in this case
      no output is expected from the process, no noticeable delay is
      visible to the user, except that the next break interaction may
      take a little longer.

      If the TIP chooses to buffer input before transmission, it will
      transmit AT LEAST at every break character.  The SERVER should be
      able to instruct the TIP to transmit more often if it is
      appropriate.






Davidson                                                       [Page 11]

RFC 357         An Echoing Strategy For Satellite Links        June 1972


   An Example:

      Conversational output LINKING is an example where transmission
      strategy is separate from the break and wakeup strategies.
      Transmission should occur on every character so that the character
      can be promptly printed at each linked terminal, but no break or
      wakeup need occur until a special escape character is typed (this
      reawakens the EXEC, for example).

      Conversational output linking also introduces another funny:

   Unsolicited Output:

      What happens when the ECHO (or DISCARD) path is enabled, but the
      input buffer is empty (i.e. immediate echoing is occurring) and
      something arrives in the output buffer? This "something" cannot be
      a response to a previously keyed command, or the ECHO path would
      be disabled. (This proof is left to the reader!) It is most likely
      a system message like


         [CR][LF]SYSTEM WILL GO DOWN IN 5 MINUTES[CR][LF]

      or, a character arriving from another linked terminal.

      Since such output does not fit neatly into our RCE scheme, the
      following kludge is proposed.  Unsolicited output should cause the
      OUTPUT path to be enabled.  The occurrence of either an MTB (DTB)
      Or Empty Output Buffer will reenable the ECHO (DISCARD) path.

IV.  Orthogonal Issues

   Several other mechanisms may reasonably be incorporated within this
   proposed addition to TELNET.  The problems which need some further
   discussion include:

         1)  Some means should be provided for the server to clear the
             input, transmission, print and output buffers.
         2)  Some means should be provided for the user to immediately
             clear the output buffer (i.e. suppress printing of lengthy
             output).
         3)  The server may want to ask about the number of characters
             remaining to be printed.
         4)  A special tag character may be required to note where
             clearing of the input buffer occurred.
         5)  The TIP's transmission strategy should be specifiable by
             the server; perhaps a "Set Wakeup Classes" command should
             be implemented.



Davidson                                                       [Page 12]

RFC 357         An Echoing Strategy For Satellite Links        June 1972


         6)  The server should be able to cause the TIP to break on the
             n-th input character regardless of whatever a break
             character has been encountered.
         7)  Should the TIP or the server be responsible for properly
             echoing a formatting control character such as a TAB?
         8)  The proper equivalence classes of ASCII characters have to
             be finalized.
         9)  How should a CR be echoed?
         10) Should one-for-one echo replacement (e.g. "$" for ESC) or
             multi-character substitution (e.g. "^A" for Control-A) be
             provided by the TIP?
         11) The proposed DTB command directs the TIP to also discard
             the delimiting break character.  Should the break character
             discard rather be dependent on setting the Break Action to
             "don't echo" before sending the DTB?

   Several of these issues will be addressed in RFC 358.

VII.  Conclusion

   This document has presented a proposed optional addition to the User
   TELNET.  The next step is to perform some simulations and to
   incorporate RCE into an experimental version of TELNET.

   No recommendation is made that the current TELNET be discarded.  For
   example RCE should not be used for those half-duplex devices which
   perform their own "echoing".  If RCE is adopted as an alternate means
   of echoing, changes to those TELNETs choosing not to implement it
   should be minimal.  Switching from RCE to the current echo mechanism
   is an immediate result of either user or server sending a "You Echo"
   (or "I'll Echo").

   Much of the machinery required to implement RCE already exists at the
   interface between the server process and its Terminal Handler or
   Server TELNET.  This means that no server process need be changed,
   but that the process' means of specifying break classes, break
   actions and echoing conventions must be interpreted by the Terminal
   Handler and reissued to the TIP in terms of the corresponding RCE
   commands.





         [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Erik J. Verbruggen 12/97 ]





Davidson                                                       [Page 13]