rfc732.txt

RFC 相关的技术文档

NWG/RFC# 732                                  DAY 13-Sep-77 18:38  41762
Data Entry Terminal Option



3. Default and Minimal Implementation Specifications

  Default

    WON'T DET -- DON'T DET

    Neither host wishes to use the Data Entry Terminal option.

  Minimal Implementation

    DET EDIT FACILITIES
    DET ERASE FACILITIES
    DET TRANSMIT FACILITIES
    DET FORMAT FACILITIES
    DET MOVE CURSOR <x><y>
    DET HOME
    DET ERASE SCREEN
    DET TRANSMIT SCREEN
    DET FORMAT DATA
    DET ERROR <cmd> <error code>

    In the case of formatting the data, the minimal implementation
    should be able to support a low and high level of intensity and
    protection for all or no characters in a field. These functions,
    however, are not required.

    The minimal implementation also requires that the Output Line Width
    and Output Page Size Telnet options be supported.
























John Day                                                       [page 16]

NWG/RFC# 732                                  DAY 13-Sep-77 18:38  41762
Data Entry Terminal Option



4. Motivation

  The Telnet protocol was originally designed to provide a means for
  scroll-mode terminals, such as the standard teletype, to communicate
  with processes through the network. This was suitable for the vast
  majority of terminals and users at that time. However, as use of the
  network has increased into other areas, especially areas where the
  network is considered to provide a production environment for other
  work, the desires and requirements of the user community have changed.
  Therefore, it is necessary to consider supporting facilities that were
  not initially supported. This Telnet option attempts to do that for
  applications that require data entry terminals.

  This option in effect defines the Network Virtual Data Entry Terminal.
  Although the description of this option is quite long, this does not
  imply that the Telnet protocol is a poor vehicle for this facility.
  Data Entry Terminals are rather complex and varied in their abilities.
  This option attempts to support both the minimal set of useful
  functions that are either common to all or can be easily simulated and
  the more sophisticated functions supplied in some terminals.

  Unlike most real data entry terminals where the terminal functions are
  encoded into one or more characters of the native character set, this
  option performs all such controls within the Telnet subnegotiation
  mechanism. This allows programs that are intimately familiar with the
  kind of terminal they are communicating with to send commands that may
  not be supported by either the option or the implementation. In other
  words, it is possible to operate in a "raw" or at least "rare" mode
  using as much of the option as necessary.

  Although many data entry terminals support a variety of peripheral
  devices such as printers, cassettes, etc. it is beyond the scope of
  this option to entertain such considerations. A separate option should
  be defined to handle this aspect of these devices.


















John Day                                                       [page 17]

NWG/RFC# 732                                  DAY 13-Sep-77 18:38  41762
Data Entry Terminal Option



5. Description

  General Notes

    All implementations of this option are required to support a certain
    minimal set of the subcommands for this option. Section 3 contains a
    complete list of the subcommands in this minimal set. In keeping
    with the Telnet protocol philosophy that an implementation should
    not have to be able to parse commands it does not implement, every
    subcommand of this option is either in the minimal set or is covered
    by one of the facility subcommands. An implementation must
    "negotiate" with its correspondent for permission to use subcommands
    not in the minimal set before using them. For details of this
    negotiation process see the section below on facility subcommands.

    Most data entry terminals are used in a half duplex mode. (Although
    most DET's on the market can be used either as data entry terminals
    or as standard interactive terminals, we are only concerned here
    with their use as DET's.) When this option is used, it is suggested
    that the following Telnet options be refused: Echo, Remote
    Controlled Transmission and Echoing, and Suppress Go-Ahead. However,
    this option could be used to support a simple full duplex CRT based
    application using the basic cursor control functions provided here.
    For these cases, one or more of the above list of options might be
    required. (Support of sophisticated interactive calligraphic
    applications is beyond the scope of this option and should be done
    by another option or the Network Graphics Protocol.)

    In RFC 728, it was noted that a synch sequence can cause undesired
    interactions between Telnet Control functions and the data stream. A
    synch sequence causes data but not control functions to be flushed.
    If a control function which has an effect on the data immediately
    following it is present in the data stream when a synch sequence
    occurs, the control function will have its effect not on the
    intended data but on the data immediately following the Data Mark.
    The following DET subcommands are susceptible to this pitfall:

      CHAR INSERT
      DATA TRANSMIT
      FORMAT DATA

    The undesired interactions are best avoided by the receiver

    of the synch sequence deleting these subcommands and all data
    associated with them before continuing to process the control
    functions. This implies that the Data Mark should not occur in the
    middle of the data associated with these subcommands.





John Day                                                       [page 18]

NWG/RFC# 732                                  DAY 13-Sep-77 18:38  41762
Data Entry Terminal Option



  Facility Subcommands

    These four subcommands are used by the User and Server
    implementations to negotiate the subcommands and attributes of the
    terminal that may be utilized. This negotiation can be viewed as the
    terminal (User Host) indicating what facilities are provided and the
    Server Host (or application program) indicating what facilities are
    desired.

    When Sent: A Server Telnet implementation using the DET option must
    send a facility subcommand requesting the use of a particular
    subcommand or terminal attribute not in the minimal implementation
    before the first use of that subcommand or attribute. The User
    Telnet implementation should respond as quickly as possible with its
    reply. Neither the User nor Server are required to negotiate one
    subcommand at a time. Also, a Telnet implementation responding to a
    facility subcommand is not required to give permission only for that
    subcommand. It may send a format map indicating all facilities of
    that class which it supports. However, a Telnet implementation
    requesting facilities must send a facility subcommand before its
    first use of the subcommand regardless of whether earlier
    negotiations have indicated the facility is provided. The facility
    cannot be used until a corresponding facility subcommand has been
    received. There are no other constraints on when the facility
    subcommands may be sent. In particular, it is not necessary for an
    application to know at the beginning of a session all facilities
    that it will use.

    Action When Recieved: There are two possible actions that may be
    taken when a facility subcommand is received depending on whether
    the receiver is a requestor or a provider (User).

    Requestor: When a facility subcommand is received by a requestor and
    it is in the state of Waiting for a Reply, it should go into the
    state of Not Waiting. It should then take the facility map it had
    sent and form the logical intersection with the facility map
    received. (For the Intensity attribute, one should take the minimum
    of the number received and the number requested.) The result
    indicates the facilities successfully negotiated. Note: if

    the receiver is not in the Waiting for Reply state, then this is the
    provider case described next.

    Provider: When a facility subcommand is received, it should send a
    facility subcommand with a facility map of the facilities it
    provides as soon as possible. It should then determine what new






John Day                                                       [page 19]

NWG/RFC# 732                                  DAY 13-Sep-77 18:38  41762
Data Entry Terminal Option



    facilities it is providing for the Requestor by forming the logical
    intersection of the facility map received and the one sent.

    Note: Although in most cases the requestor will be the Server Host
    and the provider will be the User Host supporting the terminal, this
    distinction may not always be true.

  Transmit Subcommands

    There are two kinds of transmit subcommands: those used to request
    that data be sent to the requestor, and one to preface data sent to
    the requestor. The first kind allow the requestor to control when,
    from where and to some degree how much data is transmitted from the
    terminal. Their explanation is straightforward and may be found in
    Section 2.

    Data may be sent from the terminal as a result of two events: the
    user of the terminal caused the transmission or in response to a
    transmit subcommand. Some programs may wish to know from where on
    the screen the transmission began. (This is reasonable, since the
    terminal user may move the cursor around considerably before
    transmitting.) Other programs may not need such information. The
    DATA TRANSMIT subcommand is provided in case this function is
    needed. When used this subcommand prefaces data coming from the
    terminal. The parameters <x> and <y> give the screen coordinates of
    the beginning of the transmission. <x> must be less than or equal to
    M-1 and <y> must be less than or equal to N-1. It is assumed that
    all data between this DATA TRANSMIT and the next one starts at the
    coordinates given by the first subcommand and continues filling each
    line thereafter according to the constraints of the screen and the
    format effectors in the data. Thus an intelligent or sloppy
    user-host DET implementation (depending on your point of view) need
    only include a DATA TRANSMIT subcommand when the new starting point
    is different from the last ending point.


















John Day                                                       [page 20]

NWG/RFC# 732                                  DAY 13-Sep-77 18:38  41762
Data Entry Terminal Option



6.  Sample Interaction

  The nomenclature of RFC 726 will be used to describe this example.  To
  quote that RFC:

    "S:"  is sent from serving host to using host.
    "U:"  is sent from using host to serving host.
    "T:"  is entered by the terminal user.
    "P:"  is printed on the terminal.

    Text surrounded by square brackets([]) is commentary. Text
    surrounded by angle brackets (<>) is to be taken as a single unit.
    E.g, carriage return is <cr>, and the decimal value 27 is
    represented <27>.

    We assume that the user has established the Telnet connection,
    logged on, and an application program has just been started either
    by the user directly or through a canned start up  procedure. The
    presentation on the page is meant to merely group entities together
    and does not imply the position of message boundaries. One should
    assume that any part of the dialogue may be sent as one or many
    messages. The first action of the program  or Telnet is to negotiate
    the DET option:

  S: <IAC><DO><DET>

  U: <IAC><WILL><DET>

  S:<IAC><DO><OUTPUT PAGE SIZE>              [First negotiate the screen
                                             size.  In this case we are
                                             asking the user the size of
                                             the terminal.  This could
                                             have been done before the
                                             DET option was negotiated.]

  U:<IAC><WILL><NAOP>

  U:<IAC><SB><NAOP><DR><25><IAC><SE>

  S:<IAC><SB><NAOP><DS><0><IAC><SE>

  S:<IAC><DO><OUTPUT LINE WIDTH>










John Day                                                       [page 21]

NWG/RFC# 732                                  DAY 13-Sep-77 18:38  41762
Data Entry Terminal Option



  U:<IAC><SB><NAOL><DR><80><IAC><SE>         [Defines the screen to be
                                             25 lines by 80 characters.
                                             The server may use this
                                             information when formatting
                                             the screen.]

  S:<IAC><SB><NAOL><DS><0><IAC><SE>

  S:<IAC><SB><DET><FORMAT FACILITIES>
  <Repeat><Protection, 3 Levels
  Intensity><IAC><SE>                        [Now set the terminal
                                             attributes.]

  U:<IAC><SB><DET><FORMAT FACILITIES>
  <Repeat, Blinking><Protection, 3
  Levels Intensity><IAC><SE>

  S:<IAC><SB><DET><ERASE SCREEN><IAC><SE>    [Erase the screen and start
                                             sending the form.]

    <IAC><SB><DET><FORMAT DATA>
    <Protection=1, Intensity=1><0>
    <5><IAC><SE>Name:

    <IAC><SB><DET><MOVE CURSOR><0><1><IAC><SE>

    <IAC><SB><DET><FORMAT DATA>
    <Protection=1, Intensity=1><0>
    <8><IAC><SE>Address:

    <IAC><SB><MOVE CURSOR><0><4><IAC><SE>

    <IAC><SB><DET><FORMAT DATA>
    <Protection=1, Intensity=1><0>
    <17><IAC><SE>Telephone number:

    <IAC><SB><DET><MOVE CURSOR><32><4><IAC><SE>

    <IAC><SB><DET><FORMAT DATA>
    <Protection=1, Intensity=1><0>
    <24><IAC><SE>Social Security Number:

    <IAC><SB><DET><FORMAT DATA>
    <Protection=1, Intensity=7>
    <0><11><IAC><SE>                         [Establish a field that
                                             doesn't display what is
                                             typed into it.]





John Day                                                       [page 22]

NWG/RFC# 732                                  DAY 13-Sep-77 18:38  41762
Data Entry Terminal Option



    <IAC><SB><DET><MOVE CURSOR><32><5><IAC><SE>

    <IAC><SB><DET><FORMAT FACILITIES>
    <Blinking><0><IAC><SE>                   [Get permission to use
                                             Blinking Attribute.]

  U:<IAC><SB><DET><FORMAT FACILITIES>
  <Repeat, Blinking><Protection,
  3 Levels Intensity><IAC><SE>

  S:<IAC><SB><DET><FORMAT DATA>
  <Blinking=1, Protection=1,
  Intensity=1><0><29><IAC><SE>

    Your SSN will not be printed.

    <IAC><SB><DET><HOME><IAC><SE>
    <IAC><GA>

  The previous exchange has placed a form on the screen that looks like:

  Name:
  Address:
  Telephone Number:                       Social Security Number:
                                     "Your SSN will not be printed."