Telnet Data Entry Terminal option(8)

　　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.

　　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　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 and give the screen coordinates of　the beginning of the transmission. must be less than or equal to　M-1 and 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.