idnits 2.17.1 draft-barnes-telnet-rsp-opt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 4, 1997) is 9728 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 364, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. '1') (Obsoleted by RFC 3232) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Barnes 3 File: draft-barnes-telnet-rsp-opt-01.txt Stallion Technologies 4 Expiration: March, 1998 M. Bennett 5 Revision: 002 Stallion Technologies 6 September 4, 1997 8 Telnet Remote Serial Port (RSP) Option 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 Many (if not all) terminal servers support the ability to set up a 33 telnet listener on a serial port. This allows a connection to a port 34 to be made via the network, however only (two way) data can be 35 transferred between the client and the port. 37 By using the Remote Serial Port (RSP) telnet option, the client is 38 able to control non-data aspects of the port such as baud rate and 39 modem signals. This is especially important where the port is 40 attached to a modem and modem signals are required to hangup the 41 modem. 43 This document defines a simple protocol which allows terminal servers 44 (and other systems which provide access to serial ports via a network 45 connection) to provide access to these features. 47 1. Command Name and Code 49 RSP 43 51 2. Command Meanings 53 IAC WILL RSP 55 Sender is willing to send RSP information in a subsequent sub- 56 negotiation. 58 IAC WON'T RSP 60 Sender refuses to send RSP information. 62 IAC DO RSP 64 Sender is willing to receive RSP information in a subsequent sub- 65 negotiation. 67 IAC DON'T RSP 69 Sender refuses to accept RSP information. 71 IAC SB RSP SEND IAC SE IAC SB RSP SEND item1 item2 ... IAC SE 73 Client requests server to transmit the current state of the given 74 item(s). The code for SEND is 1. If no items are given, the 75 server is requested to return all known items. 76 (See below for valid 'item's) 78 IAC SB RSP IS item1 value1 item2 value2 ... IAC SE 80 Server states the current value of the given items. May be in 81 response to SEND, or may be due to a change in the value of the 82 items. The code for IS is 0. 83 (See below for valid 'item's) 85 IAC SB RSP SET item1 value1 item2 value2 IAC SE 87 Client requests that the server sets the value of 'item1' to 88 'value1' etc. The code for SET is 2. 89 (See below for valid 'item's) 91 2.1. Valid RSP items 93 MSR 0 95 8250-compatible modem status register 96 Value is 32 bit value in network byte order, with msr in the least 97 significant 8 bits. 99 Bit 0 Delta Clear to Send 100 Indicates the -CTS input signal has changed state since the 101 last time it was read. 103 Bit 1 Delta Data Set Ready 104 Indicates the -DSR input signal has changed state since the 105 last time it was read. 107 Bit 2 Trailing Edge Ring Indicator 108 Indicates the -RI input signal has changed from an active 109 condition to an inactive condition. 111 Bit 3 Delta Data Carrier Detect 112 Indicates the -DCD input signal has changed state since the 113 last time it was read. 115 Bit 4 Clear to Send 116 Current state of the CTS input signal. 118 Bit 5 Data Set Ready 119 Current state of the DSR input signal. 121 Bit 6 Ring Indicator 122 Current state of the RI input signal. 124 Bit 7 Data Carrier Detect 125 Current state of the DCD input signal. 127 BAUD-RATE 1 129 Baud rate Value is 32 bit number in network byte order. The value 130 0 is used to represent "unknown". 132 STOP-BITS 2 134 Stop bits 135 Value is 32 bit number in network byte order, where 0 represents 136 1 1/2. 138 DATA-BITS 3 140 Data bits in a character 141 Value is 32 bit number in network byte order. 143 PARITY 4 145 Parity of characters 146 Value is 32 bit number in network byte order with one of the 147 following values. 148 NONE 0 149 ODD 1 150 EVEN 2 151 MARK 3 152 SPACE 4 154 DTR 5 156 State of DTR 157 Value is a 32 bit number in network byte order with one of the 158 following values. 159 OFF 0 160 ON 1 162 RTS 6 164 State of RTS 165 Value is a 32 bit number in network byte order with one of the 166 following values. 167 OFF 0 168 ON 1 170 TXBUFFER 7 172 Characters in the the transmit buffer 173 Value is a 32 bit number in network byte order which is the 174 current number of characters in the transmit buffer, 0 implies the 175 buffer is empty. 177 FLOW-CONTROL 8 179 Input and output flow control setting. 180 Value is a 32 bit number in network byte order which represents a 181 bit mask. The bitmask may contain any combination of the 182 following values. 184 RTSFLOW 1 (Input flow control - drop RTS to stop 185 receiving) 187 CTSFLOW 2 (Output flow control - stop transmitting when 188 CTS drops) 189 IXON 4 (Output flow control - start/stop sending on 190 XON/XOFF) 191 IXOFF 8 (Input flow control - send XON/XOFF to 192 start/stop receiving) 193 DCDFLOW 16 (Output flow control - stop transmitting when 194 DCD drops) 195 DTRFLOW 32 (Input flow control - drop DTR to stop 196 receiving) 197 DSRFLOW 64 (Output flow control - stop transmitting when 198 DSR drops) 200 TXBREAK 9 202 State of TX Break 203 Value is a 32 bit number in network byte order with one of the 204 following values. 205 OFF 0 (Normal state) 206 ON 1 (Transmit Break) 208 RXBREAK 10 210 State of RX Break 211 Value is a 32 bit number in network byte order with one of the 212 following values. 213 OFF 0 (Normal state - not receiving break) 214 ON 1 (Currently receiving Break) 216 SEND-CHANGED 32 218 Specifies which items, if any, for which the server should send 219 values when the value of the item changes. 220 Value is a 32 bit number in network byte order which represents a 221 bit mask. If a bit is 1, then the server should send the value 222 for that item immediately and any time it subsequently changes, 223 and if it is a 0, it should send the value only upon request. For 224 example, if 0x00000001 is set as a value for SEND-CHANGED, then 225 the server should send the value for MSR immediately and then 226 whenever that value changes. 228 PURGE 33 230 Purges receive and/or transmit queues. 231 Value is a 32 bit number in network byte order with one of the 232 following values. 233 RX-QUEUE 1 234 TX-QUEUE 2 235 RXTX-QUEUE 3 (Purge both the RX and TX queues) 237 3. Default Specification 239 WON'T RSP 240 DON'T RSP 242 RSP information will not be exchanged. 244 SEND-CHANGED 0 246 Server only sends updated information as requested. 248 4. Motivation 250 The Remote Serial Port telnet option allows a telnet client of a 251 physical serial port to control non-data attributes of the port, such 252 as baud rate, parity and output modem signal state. 254 5. Description of the Option 256 Willingness to exchange RSP information is agreed upon via 257 conventional Telnet option negotiation. WILL and DO are used only to 258 obtain and grant permission for future discussion. The actual 259 exchange of status information occurs within option subcommands (IAC 260 SB RSP...). 262 Once the two hosts have exchanged a WILL and a DO, the sender of the 263 DO RSP (the client) is free to request and set RSP information. A 264 successful DO RSP is required before SEND and SET requests can be 265 used by the client and IS responses can be sent by the server. The 266 negotiation indicates acceptance in one direction only. (It would 267 generally not be appropriate to negotiate the RSP option in both 268 directions). 270 All RSP items are 1 octet in length and all RSP values are 32 bit 271 values in network byte order. This allows multiple items or multiple 272 {item, value} pairs to be specified in a single request or response 273 without requiring that all items be understood by the recipient. 275 Note that any occurrence of the octet IAC within an RSP item must be 276 escaped. 278 6. Implementation Issues 280 This specification allows for various items to be set or requested by 281 a client. Support for all items is optional. Also it may be 282 inappropriate to set or send a given item at any time. Thus, a 283 server responds to requests as follows. 285 When a server receives a SET request, it should immediately make the 286 change for each item in the list. If any item is not supported, not 287 understood or not appropriate (doesn't make sense or the value is 288 inappropriate), that item is ignored. All items in a request are 289 independent. That is, if one item fails, then the remaining items in 290 the request should continue to be processed. 292 Similarly, when a server receives a SEND request, it should respond 293 with an IS request for each item in the SEND request which is 294 understood and makes sense. Other items are ignored. 296 No response is sent by the server as a result of a SET request. It 297 is the responsibility of the client to issue a SEND request if it 298 wishes to determine whether a SET request has succeeded. 300 SEND-CHANGED is an item like any other including the fact that 301 support for it is optional. If it is supported, an IS request is 302 sent by the server to the client whenever the value for an item 303 changes value spontaneously (that is, other than in response to a SET 304 request) for which a 1 bit is set in the SEND-CHANGED value. 306 Note: No requirements are placed on the server in determining how 307 soon after the change occurs that the IS request should be 308 sent. This allows a server to combine multiple changes into a 309 single request if multiple changes occur within a short time of 310 one another. Also, a server may choose to delay sending of an 311 IS request if the value of an item changes very quickly to 312 avoid flooding the connection. Every change of an item need 313 not be (and should not be) sent in these circumstances. 314 Rather, only the "last" change should be sent. 316 Note: Only changes to the first 32 RSP items are supported by SEND- 317 CHANGED. This should be sufficient for all realistic 318 implementations of remote serial ports. 320 7. Examples 322 Note: In these examples, the C notation, 0x, is used to denote a 323 hexadecimal number. 325 In this example, the client gets the current values for all items 326 known by the server. 328 Client: IAC DO RSP 330 Server: IAC WILL RSP 332 (Client may now request or set RSP information at any time. 333 Server is SEND-CHANGED 0) 335 Client: IAC SB RSP SEND IAC SE 337 Server: IAC SB RSP IS SEND-CHANGED 0 MSR 0x00 DTR ON BAUD-RATE 338 9600 IAC SE 340 In this example, the client turns on SEND-CHANGED and checks to 341 see if it is supported by the server. The server sends change 342 notifications. 344 Client: IAC DO RSP 346 Server: IAC WILL RSP 348 Client: IAC SB RSP SET SEND-CHANGED 0x0000000F IAC SE 350 Client: IAC SB RSP SEND SEND-CHANGED IAC SE 352 Server: IAC SB RSP IS SEND-CHANGED 0x0000000F IAC SE 354 Server: IAC SB RSP IS MSR 0x33 IAC SE 356 Server: IAC SB RSP IS MSR 0x03 BAUD-RATE 38400 IAC SE 358 Security Considerations 360 Security issues are not discussed in this document. 362 References 364 [1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 365 1700, USC/Information Sciences Institute, October 1994. 367 Author's Addresses: 369 Robert Barnes and Murray Bennett 370 Stallion Technologies 371 33 Woodstock Road 372 Toowong, QLD 4066 373 Australia 374 rab@stallion.oz.au