blob: 068572e20a0930968616e8f191e22088773812e9 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
Network Working Group J. Postel
Request for Comments: 859 J. Reynolds
ISI
Obsoletes: RFC 651 (NIC 31154) May 1983
TELNET STATUS OPTION
This RFC specifies a standard for the ARPA Internet community. Hosts on
the ARPA Internet are expected to adopt and implement this standard.
1. Command Name and Code
STATUS 5
2. Command Meanings
This option applies separately to each direction of data flow.
IAC DON'T STATUS
Sender refuses to carry on any further discussion of the current
status of options.
IAC WON'T STATUS
Sender refuses to carry on any further discussion of the current
status of options.
IAC SB STATUS SEND IAC SE
Sender requests receiver to transmit his (the receiver's)
perception of the current status of Telnet options. The code for
SEND is 1. (See below.)
IAC SB STATUS IS ... IAC SE
Sender is stating his perception of the current status of Telnet
options. The code for IS is 0. (See below.)
3. Default
DON'T STATUS, WON'T STATUS
The current status of options will not be discussed.
4. Motivation for the Option
This option allows a user/process to verify the current status of
TELNET options (e.g., echoing) as viewed by the person/process on the
other end of the TELNET connection. Simply renegotiating options
Postel & Reynolds [Page 1]
^L
RFC 859 May 1983
could lead to the nonterminating request loop problem discussed in
the General Consideration section of the TELNET Specification. This
option fits into the normal structure of TELNET options by deferring
the actual transfer of status information to the SB command.
5. Description of the Option
WILL and DO are used only to obtain and grant permission for future
discussion. The actual exchange of status information occurs within
option subcommands (IAC SB STATUS...).
Once the two hosts have exchanged a WILL and a DO, the sender of the
WILL STATUS is free to transmit status information, spontaneously or
in response to a request from the sender of the DO. At worst, this
may lead to transmitting the information twice. Only the sender of
the DO may send requests (IAC SB STATUS SEND IAC SE) and only the
sender of the WILL may transmit actual status information (within an
IAC SB STATUS IS ... IAC SE command).
IS has the subcommands WILL, DO and SB. They are used EXACTLY as used
during the actual negotiation of TELNET options, except that SB is
terminated with SE, rather than IAC SE. Transmission of SE, as a
regular data byte, is accomplished by doubling the byte (SE SE).
Options that are not explicitly described are assumed to be in their
default states. A single IAC SB STATUS IS ... IAC SE describes the
condition of ALL options.
Postel & Reynolds [Page 2]
^L
RFC 859 May 1983
The following is an example of use of the option:
Host1: IAC DO STATUS
Host2: IAC WILL STATUS
(Host2 is now free to send status information at any time.
Solicitations from Host1 are NOT necessary. This should not
produce any dangerous race conditions. At worst, two IS's will
be sent.)
Host1 (perhaps): IAC SB STATUS SEND IAC SE
Host2 (the following stream is broken into multiple lines only for
readability. No carriage returns are implied.):
IAC SB STATUS IS
WILL ECHO
DO SUPPRESS-GO-AHEAD
WILL STATUS
DO STATUS
IAC SE
Explanation of Host2's perceptions: It is responsible for echoing
back the data characters it receives over the TELNET connection;
it will not send Go-Ahead signals; it will both issue and request
Status information.
Postel & Reynolds [Page 3]
^L
|
