rfc1043.txt

中、英文RFC文档大全打包下载完全版 .

         feed characters) and should be displayed in a timely and
         non-destructive fashion.

      IAC SB DET END-OUT-OF-CONTEXT-DATA IAC SE

         subcommand code: 43

         This subcommand indicates the end of the out-of-context data.

      IAC SB DET ENABLE-FUNCTION-KEYS <key-map>IAC SE

         subcommand code: 44

         This subcommand enables (or disables) virtual function keys and
         indicates the application's data requirements on function key
         selection.  The <key-map> parameter is a variable length byte
         string.  Each byte contains four bit-pairs and each bit-pair
         represents a single function key.  The first byte represents
         function keys zero (0) through three (3); the second byte,
         function keys four (4) through seven (7); and so on.  Bit-pair
         values and there meanings are as follows:

             0  The virtual function key is disabled (i.e., locked).

             1  The virtual function key is enabled.  Only the FUNCTION-
                KEY subcommand is returned on function key selection.

             2  The  virtual  function  key  is  enabled.  All requested
                screen data and/or cursor position, as well as, the
                FUNCTION-KEY subcommand are returned on function key
                selection.

             3  Undefined.

         Function keys not explicitly represented in the bitmap are
         disabled (i.e., they are assumed to have a bit-pair value of
         zero (0)).

         Use of this subcommand requires facility negotiation; see the
         FORMAT-FACILITIES subcommand; Function-Key bit.

      IAC SB DET SELECTED-FIELD <x><y> IAC SE

         subcommand code: 45

         This subcommand identifies a user selected field.  The <x> and
         <y> parameters are the cursor position of the character
         selected from within a selectable field (see the FORMAT-DATA



Yasuda & Thompson                                              [Page 14]

RFC 1043              Data Entry Terminal - DODIIS         February 1988


         subcommand, Selectable attribute.)  Use of this subcommand
         requires negotiation; see the FORMAT-FACILITIES subcommand,
         Field-Selection bit.

3. Default and Minimal Implementation


      Default.

         WONT DET -- DONT DET

         If the DET option cannot be negotiated, the connection is
         not operated in DET mode.

      Minimal DET Implementation.

         The minimal DET implementation consists of all DET subcommands
         that may be used without prior negotiation.  These subcommands
         are as follows:

             EDIT-FACILITIES
             ERASE-FACILITIES
             TRANSMIT-FACILITIES
             FORMAT-FACILITIES
             MOVE-CURSOR
             HOME-CURSOR
             ERASE-SCREEN
             TRANSMIT-SCREEN
             FORMAT-DATA
             ERROR
             START-OUT-OF-CONTEXT-DATA
             END-OUT-OF-CONTEXT-DATA

      DODIIS DET implementation requirements.

         The minimal DET implementation set of subcommands is not broad
         enough to support forms interactions between DODIIS terminals
         and DODIIS applications.  Therefore, DODIIS implementations of
         the DET option must support additional DET subcommands.

         DODIIS terminal (User Host) implementations must implement and
         support all of the DET subcommands contained in Section 2, as
         well as those DET attributes supported by the terminal hardware
         and any DET attributes easily emulated in software.  DODIIS
         application (Server Host) implementations must implement and
         support those DET subcommands and attributes required by its
         applications.




Yasuda & Thompson                                              [Page 15]

RFC 1043              Data Entry Terminal - DODIIS         February 1988


         DODIIS implementation recommendations are contained in the
         table that follows.  DODIIS implementors are cautioned that
         failure to provide recommended support may limit
         interoperability.

         Recommended DET support levels for DODIIS implementations

                                      USER HOST           SERVER HOST
      DET SUBCOMMANDS                 SUPPORT LEVEL       SUPPORT LEVEL
      ---------------                 -------------       -------------
      EDIT-FACILITIES                 send & receive      send & receive
      ERASE-FACILITIES                send & receive      send & receive
      TRANSMIT-FACILITIES             send & receive      send & receive
      FORMAT-FACILITIES               send & receive      send & receive
      REPEAT                          send & receive      send & receive
      ERROR                           send & receive      send & receive
      MOVE-CURSOR                     receive only        send only
      HOME-CURSOR                     receive only        send only
      READ-CURSOR                     receive only        send only
      TRANSMIT-SCREEN                 receive only        send only
      TRANSMIT-UNPROTECTED            receive only        send only
      TRANSMIT-MODIFIED               receive only        send only
      ERASE-SCREEN                    receive only        send only
      ERASE-UNPROTECTED               receive only        send only
      FORMAT-DATA                     receive only        send only
      START-OUT-OF-CONTEXT-DATA       receive only        send only
      END-OUT-OF-CONTEXT-DATA         receive only        send only
      ENABLE-FUNCTION-KEYS            receive only        send only
      CURSOR-POSITION                 send only           receive only
      DATA-TRANSMIT                   send only           receive only
      FIELD-SEPARATOR                 send only           receive only
      FUNCTION-KEY                    send only           receive only
      SELECTED-FIELD                  send only           receive only

      DET ATTRIBUTES
      --------------
      Blinking                        (1)                 (2)
      Reverse video                   (1)                 (2)
      Right justification             (1)                 (2)
      Protection                      required            (2)
      Alphabetic-only protection      (1)                 (2)
      Numeric-only protection         (1)                 (2)
      Intensity level > 1             (1)                 (2)

      OTHER
      -----
      Page size (lines)               24-48
      Line size (characters)          80



Yasuda & Thompson                                              [Page 16]

RFC 1043              Data Entry Terminal - DODIIS         February 1988


      Function keys (number)          64


         (1)   Implement if supported by terminal hardware.
         (2)   Implement if required by the application.

4.  Motivation for the option

   In 1981, the TELNET DET option (RFC 732) was selected as the protocol
   to support interactions between DODIIS forms applications and DODIIS
   forms terminals.  The intent was to foster a high degree of
   interoperability between DODIIS hosts with forms applications and
   terminals.  Since that time, the DET option has been and is being
   implemented by several independent organizations within the DODIIS
   community.

   Motivated by concern that the independently developed implementations
   of the DET option may not interoperate with one another, DODIIS
   implementors met to identify DODIIS implementation requirements and
   to resolve implementation issues that affect interoperability.

   This document attempts to present the agreements and recommendations
   of the DODIIS implementors.

5.  Description and Implementation Rules

   The DODIIS DET model.

   The conceptual model of the DODIIS DET is that of a half-duplex,
   forms oriented device with the following:

      a.  A rectangular screen for displaying protected and unprotected
         data (a form) and optional capability to support blinking,
         reverse video, and up to seven display intensity levels.

      b.  A keyboard and onboard mechanisms for editing unprotected
         fields of a form and returning the modified fields.

      c.  Function keys that may be enabled and disabled on a key-by-key
         basis by the application.

      d.  A field selection device, similar to a light pen, that permits
         user selection of characters within appropriately identified
         "selectable" fields.

   The DODIIS DET screen has default sizes of 80 characters and 24
   lines.  These defaults may be changed through negotiation using the
   Output Line Width and the Output Page Size options.  When the parties



Yasuda & Thompson                                              [Page 17]

RFC 1043              Data Entry Terminal - DODIIS         February 1988


   cannot agree on screen size through negotiation, the default values
   will be used.  By agreement, DODIIS terminal (User Host)
   implementations of DET will support page sizes of 24 to 48 lines.

   The next writing position (x,y) on the DET screen is indicated by a
   special display character called the cursor, where x is the position
   of a character on a line and y is the line position on the DET
   screen.  Values of x range from 0 (the left most character position
   on the line) to M-1, where M is the line length.  Values of y range
   from 0 (the top most line on the screen) to N-1, where N is the page
   length.  The cursor may be moved to any position on the DET screen
   without disturbing the characters already displayed.

   Valid field data for DET forms are the displayable ASCII character
   codes in the range 32 through 126 decimal and character 7 "BELL".

   Negotiating the DET option

      The DET option is negotiated when either party REQUESTS use of the
      DET option and the other party AGREES to its use.  The DET option
      is requested by sending a DO DET and WILL DET and is accepted by
      sending a WILL DET and DO DET.  (In the spirit of TELNET
      negotiation, the DET option must be negotiated for both directions
      on the connection.)

      Several TELNET options conflict with the DET option.  Therefore,
      when the DET option is negotiated, the following TELNET options
      should be refused (or explicitly terminated):  Echo, Suppress Go-
      Ahead, and Binary.  (The Suppress Go-Ahead is the default state of
      DODIIS TELNET connections when they are first established.)

   DET facilities negotiation

      All implementations of the DET option are required to support the
      minimal DET implementation described in Section 3.  In addition,
      DODIIS implementations are required to support subcommands and
      attributes that are consistent with DODIIS implementation
      requirements.  Before any of these additional DET facilities may
      be used, an implementation must negotiate with its correspondent
      for permission to use them.

      The four facility subcommands (EDIT-FACILITIES, ERASE-FACILITIES,
      TRANSMIT-FACILITIES, and FORMAT-FACILITIES) are used to negotiate
      DET subcommands and attributes.  This negotiation consists of an
      exchange of facility subcommands and may be viewed as the terminal
      (User Host) indicating the facilities it provides and the
      application program (Server Host) indicating the facilities it
      desires.  The facilities that are jointly supported (and may be



Yasuda & Thompson                                              [Page 18]

RFC 1043              Data Entry Terminal - DODIIS         February 1988


      used) are arrived at by forming the logical intersection of the
      facility map that was sent with the facility map that was
      received.  (For the intensity attribute, the lesser of the number
      of intensity levels sent and the number of intensity levels
      received will be used.)  An implementation must record the
      currently agreed upon set of subcommands and attributes.  Only
      subcommands and attributes reflected in that set may be used
      without further exchange of facility subcommands.

      Either party or both parties may initiate facilities negotiation
      without confusion as long as care is taken to avoid non-
      terminating negotiation loops.  In particular, if you initiate
      negotiation by sending a facility subcommand, you must remember
      that you did initiate the negotiation.  On receipt of a facility
      subcommand; if you initiated the negotiation, no response is
      required and the negotiation is complete; if you did not initiate
      the negotiation, you must respond by sending the appropriate
      facility subcommand to the requester.  (Note that there is no
      requirement to negotiate facilities one class at a time and that
      the awareness of who initiated the negotiation must be maintained
      for each of the facility subcommands.)

      A TELNET implementation responding to a facility subcommand is not
      required to compute the logical intersection of the maps before
      responding.  It should respond as quickly as possible with a
      facility map indicating all facilities of that class that it
      supports.  There is no confusion since both parties compute the
      set of supported subcommands and attributes in the same fashion.
      Note that while both parties must agree to the use of the optional
      subcommands and attributes, either party may disable use at any
      time by merely sending the appropriate facility subcommand.
      Further, there are no restrictions on when facilities may be sent.

                                   CAUTION:

                 All facilities maps contain reserved bits.
                 These reserved bits must be zeroed when
                 facility maps are sent to indicate non
                 support and/or ignorance of the associated
                 facility.  The reserved bits may be defined
                 in the future.

   General DET Interaction

      In the general interaction, the application implementation
      constructs a form, negotiates the desired options, indicates the
      required responses, and sends the TELNET GO-AHEAD.  The GO-AHEAD
      signals that the form construction is complete and that the DET



Yasuda & Thompson                                              [Page 19]

RFC 1043              Data Entry Terminal - DODIIS         February 1988


      keyboard may be unlocked to permit a user response.

      The user normally responds by editing the unprotected areas of the
      form and signaling "form-complete", entering a function key,
      electing a field, or performing a combination of the preceding.
      In each case, the terminal implementation sends the DET
      subcommands indicating the user's response and returns the GO-
      AHEAD.  The GO-AHEAD signals the end of the user response.

      The form, as edited by the user, remains on the virtual screen so
      the application may continue the interaction by altering the form.

   Form construction

      The application implementation constructs a form on an erased
      screen by defining each of the fields in the form.  The DET fields
      are defined by their starting cursor position, size, attributes,
      and contents (data).

      A field's starting cursor position is the cursor position of the
      first character in the field.  The cursor may be positioned
      explicitly by the MOVE-CURSOR subcommand or it may be positioned
      implicitly by field data or other DET subcommands (e.g.,
      ERASESCREEN and ERASE-UNPROTECTED).

      Field size, attributes, and contents may be defined using the
      FORMAT-DATA subcommand followed by field data.  Alternatively, a
      field with default attributes may be defined using only the field