RFC657 - Telnet output vertical tab disposition option

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

D. Crocker (UCLA-NMC)

RFC657, 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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航