diff options
Diffstat (limited to 'doc/rfc/rfc655.txt')
| -rw-r--r-- | doc/rfc/rfc655.txt | 114 |
1 files changed, 114 insertions, 0 deletions
diff --git a/doc/rfc/rfc655.txt b/doc/rfc/rfc655.txt new file mode 100644 index 0000000..5b0b8ca --- /dev/null +++ b/doc/rfc/rfc655.txt @@ -0,0 +1,114 @@ +TELNET OUTPUT FORMFEED DISPOSITION OPTION +RFC 655, NIC 31158 (Oct. 25, 1974) +D. Crocker (UCLA-NMC) +Online file: [ISI]<DCROCKER>NAOFFD.TXT + + TELNET OUTPUT FORMFEED DISPOSITION OPTION + +1. Command name and code + NAOFFD - 13 + (Negotiate About Output Formfeed Disposition) + +2. Command meanings + In the following, we are discussing a simplex connection, as described in + the NAOL and NAOP Telnet Options specifications. + IAC DO NAOFFD + The data sender requests or agrees to negotiate about output + formfeed disposition with the data receiver. In the case + where agreement has been reached and in the absence of + further subnegotiations, the data receiver is assumed to be + handling output formfeeds. + IAC DON'T NAOFFD + The data sender refuses to negotiate about output formfeed + disposition with the data receiver, or demands a return to + the unnegotiated default mode. + IAC WILL NAOFFD + The data receiver requests or agrees to negotiate about + output formfeed disposition with the sender. In the case + where agreement has been reached and in the absence of + further subnegotiations, the data receiver alone is assumed + to be handling output formfeeds. + IAC WON'T NAOFFD + The data receiver refuses to negotiate about output formfeed + disposition, or demands a return to the unnegotiated default + mode. + IAC SB NAOFFD DS <8-bit value> IAC SE + The data sender specifies, with the 8-bit value, which party + should handle formfeeds and what their disposition should be. + The code for DS is 1. + IAC SB NAOFFD DR <8-bit value> IAC SE + The data receiver specifies, with the 8-bit value, which + party should handle formfeeds and what their disposition + should be. The code for DR is 0. + +3. Default + DON'T NAOFFD/WON'T NAOFFD + In the default absence of negotiations concerning which party, data + sender or data receiver, is handling output formfeeds, neither party + is required to handle formfeeds and neither party is prohibited from + handling them; but it is appropriate if at least the data receiver + handles formfeed considerations, albeit primitively. + +4. Motivation for the Option + Please refer to section 4 of the NAOL and of the NAOFFD Telnet option + descriptions. + +5. Description of the Option + The data sender and the data receiver use the 8-bit value along with the + DS and DR SB commands as follows: + + 8-bit value Meaning + + 0 Command sender suggests that he alone will handle + formfeeds, for the connection. + 1 to 250 Command sender suggests that the other party alone + should handle formfeeds, but suggests that the + indicated value be used. The value is the number + of character-times to wait or number of NULs to + insert in the data stream before sending the next + data character. + 251 Command sender suggests that the other party alone + handle formfeeds, but suggests that each + occurrence of the character be replaced by + carriage-return/line-feed. + 252 Command sender suggests that the other party alone + handle formfeeds, but suggests that they be + discarded. + 253 Command sender suggests that the other party alone + should handle formfeeds, but suggests that + formfeeds be simulated. + 254 Command sender suggests that the other party alone + should handle output formfeeds but suggests + waiting for a character to be transmitted (on the + other simplex connection) before sending more + data. Note that, due to the assynchrony of the two + simplex connections, phase problems can occur with + this option. + 255 Command sender suggests that the other party alone + should handle output formfeeds and suggests + nothing about how it should be done. + + The guiding rules are that: + + 1) if neither data receiver nor data sender wants to handle output + formfeeds, the data receiver must do it, and + 2) if both data receiver and data sender want to handle output + formfeeds, the data sender gets to do it. + + The reasoning for the former rule is that if neither wants to do + it, then the default in the NAOFFD option dominates. If both want + to do it, the sender, who is presumed to have special knowledge + about the data, should be allowed to do it, taking into account any + suggestions the receiver may make. Simulation is defined as the + replacement of the formfeed character by enough line-feeds (only) + to advance the paper (or line-pointer) to the top of the next page + (or to the top of the terminal screen). Note that delays, + controlled by the data sender, must consist of NUL characters + inserted immediately after the formfeed character. This is + necessary due to the assynchrony of network transmission. As with + all option negotiations, neither party should suggest a state + already in effect except to refuse to negotiate; changes should be + acknowledged; and once refused, an option should not be resuggested + until "something changes" (e.g., another process starts). At any + time, either party can disable further negotiation by giving the + appropriate WON'T NAOFFD or DON'T NAOFFD command. |