diff options
Diffstat (limited to 'doc/rfc/rfc657.txt')
| -rw-r--r-- | doc/rfc/rfc657.txt | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/doc/rfc/rfc657.txt b/doc/rfc/rfc657.txt new file mode 100644 index 0000000..5a1ff0f --- /dev/null +++ b/doc/rfc/rfc657.txt @@ -0,0 +1,112 @@ +D. Crocker (UCLA-NMC) +RFC 657, NIC 31160 (Oct. 25, 1974) +Online file: [ISI]<DCROCKER>NAOVTD.TXT + + TELNET OUTPUT VERTICAL TAB DISPOSITION OPTION + +1. Command name and code + NAOVTD 15 + (Negotiate About Output Vertcial Tab 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 NAOVTD + The data sender requests or agrees to negotiate about output + vertical tab character 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 vertical tab character considerations. + IAC DON'T NAOVTD + The data sender refuses to negotiate about output vertical tab + character disposition with the data receiver, or demands a + return to the unnegotiated default mode. + IAC WILL NAOVTD + The data receiver requests or agrees to negotiate about output + vertical tab character 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 vertical tab character considerations. + IAC WON'T NAOVTD + The data receiver refuses to negotiate about output vertical + tab character disposition, or demands a return to the unnegotiated + default mode. + IAC SB NAOVTD DS <8-bit value> IAC SE + The data sender specifies, with the 8-bit value, which party + should handle output vertical tab characters and what their + disposition should be. The code for DS is 1. + IAC SB NAOVTD DR <8-bit value> IAC SE + The data receiver specifies, with the 8-bit value, which party + should handle output vertical tab characters and what their + disposition should be. The code for DR is 0. + +3. Default + DON'T NAOVTD/WON'T NAOVTD + In the default absence of negotiations concerning which party, + data sender or data receiver, is handling output vertical tab character + considerations, neither party is required to handle vertical tab + characters and neither party is prohibited from handling them; but + it is appropriate if at least the data receiver handles vertical tab + character considerations, albeit primitively. + +4. Motivation for the Option + Please refer to section 4 of the NAOL and of the NAOVTD 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 + vertical tab characters, for the connection. + 1 to 250 Command sender suggests that the other party alone + should handle tab characters, but suggests that a + delay of 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 vertical tabs, but suggests that each + occurrence of the character be replaced by + carriage-return/linefeed. + 252 Command sender suggests that the other party alone + handle vertical tabs, but suggests that they be discarded. + 253 Command sender suggests that the other party alone + should handle tab characters, but suggests that + tabbing be simulated. + 254 Command sender suggests that the other party alone + should handle the output disposition 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 the output disposition 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 the + output vertical tab characters, the data receiver must do it, and + 2. if both data receiver and data sender want to handle the output + vertical tab characters, the data sender gets to do it. + + The reasoning for the former rule is that if neither want to do it, then + the default in the NAOVTD 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 character by + enough line-feeds (only) to advance the paper (or line-pointer) to the + next vertical tab stop. + Note that delays, controlled by the data sender, must consist of NUL + characters, inserted immediately after the line-feed character. This is + necessary due to the assynchrony of network transmissions. 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 NAOVTD or + DON'T NAOVTD command. |