summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2217.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2217.txt')
-rw-r--r--doc/rfc/rfc2217.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc2217.txt b/doc/rfc/rfc2217.txt
new file mode 100644
index 0000000..d99f688
--- /dev/null
+++ b/doc/rfc/rfc2217.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group G. Clark
+Request for Comments: 2217 Cisco Systems, Inc.
+Category: Experimental October 1997
+
+
+ Telnet Com Port Control Option
+
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. This memo does not specify an Internet standard of any
+ kind. Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Introduction
+
+ This memo proposes a protocol to allow greater use of modems attached
+ to a network for outbound dialing purposes.
+
+Table of Contents
+ 1. Negotiation of the Com Port
+ Control Option Protocol .................. 5
+ 2. Com Port Configuration Commands .................. 6
+ Version
+ Baud Rate
+ Data Bit Size
+ Parity
+ Stop Bit size
+ 3. Special Com Port Control Commands ................. 8
+ XON/XOFF Flow Control
+ HARDWARE Flow Control
+ BREAK Signal
+ DTR Signal
+ RTS Signal
+ 4. Notification of Com Port and .................. 12
+ Modem Line Changes
+ 5. Flow Control .................. 13
+ 6. Security Considerations .................. 13
+ 7. Author's Address .................. 14
+ 8. Reference Section .................. 14
+
+Discussion
+
+ The Telnet protocol defines an interactive, character-oriented
+ communications session. It was originally designed to establish a
+ session between a client and a remote login service running on a host
+ [5].
+
+
+
+Clark Experimental [Page 1]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+ Many new business functions require a person to connect to remote
+ services to retrieve or deposit information. By in large, these
+ remote services are accessed via an async dial up connection. This
+ new class of functions include:
+
+ - dial up connections to the Internet
+ - connecting to bulletin boards
+ - connecting to internal and external databases
+ - sending and receiving faxes.
+
+ The general nature of this new class of function requires an
+ interactive, character-oriented communications session via an async
+ modem. This is typically known as outbound modem dialing.
+
+ To help defer the cost of installing and maintaining additional phone
+ lines which may be used very little per person, many equipment
+ manufacturers have added the ability to establish a Telnet session
+ directly to the outbound ports on many of the most popular access
+ servers and routers, here after referred to as access servers.
+
+ However, the current Telnet protocol definitions are not sufficient
+ to fully support this new use. There are three new areas of
+ functionality which need to be added to the Telnet protocol to
+ successfully support the needs of outbound modem dialing. These are:
+
+ - The ability for the client to send com port configuration
+ information to the access server which is connected to the
+ outbound modem. This is needed to ensure the data being
+ transmitted and received by the modem is formatted correctly
+ at the byte level.
+
+ - The ability for the access server to inform the client of any
+ modem line or signal changes such as RLSD changes (carrier
+ detect). This information is vital, since many client software
+ packages use this information to determine if a session with the
+ remote service has been established. RLSD changes are also
+ used for signaling in Class I faxing [6].
+
+ - The ability to manage flow control between the client and
+ the access server which does not interfere with the flow
+ control mechanisms used by the session between the client and
+ the remote service. Unfortunately RFC 1372 "Telnet Remote
+ Flow Control Option" [2] can not be used for this purpose
+ because it relies on sending XON/XOFF style characters which
+ maybe transmitted or received as a normal course of the
+ client / remote service session.
+
+
+
+
+
+Clark Experimental [Page 2]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+ Though this discussion has focused on outbound modem dialing as the
+ primary use of this protocol, the protocol can also be used for any
+ serial device attached to an access server. Such devices could be:
+
+ - serial printers
+ - plotters
+ - monitoring devices such as pipe line monitors or medical
+ monitors
+ - general office equipment such as photo-copiers and cash
+ registers
+
+Definition of Terms
+
+ Access Server - Any network device which accepts Telnet sessions
+ and passes the data received to a com port, and
+ passes data received from the com port to the client
+ via the Telnet session.
+
+ Baud Rate - For the purposes of this document, baud rate will
+ mean the communications of data in bits per second.
+
+ Client - Any network device which initiates a Telnet session
+ to an access server.
+
+ Outbound - Transmission of data from the modem attached to the
+ access server to a remote service.
+
+ Inbound - Transmission of data from the remote service to the
+ modem attached to the access server.
+
+ Remove Service - Any service which accepts dial-up connections,
+ including fax machines.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark Experimental [Page 3]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+Illustration
+
+ =====================
+ | |
+ | CLIENT |\
+ | | \ < ---- Local Area /
+ ===================== \ Enterprise Network
+ \
+ \
+ =============================
+ | Telnet Interface |
+ | | |
+ | | |
+ | ACCESS SERVER | |
+ | | |
+ | | |
+ | Com Port Interface |
+ =============================
+ |
+ |
+ ==================
+ | |
+ | MODEM |
+ | |
+ ==================
+ |
+ Access to Remote Service |
+ most commonly Public Switched ----->|
+ Network |
+ |
+ |
+ ======================
+ Could be Internet Service | |
+ Provider, Bulletin Board | |
+ or FAX machine | REMOTE SERVICE |
+ | |
+ | |
+ ======================
+
+
+ Command Names and Codes:
+ COM-PORT-OPTION 44
+
+
+
+
+
+
+
+
+
+Clark Experimental [Page 4]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+ Client to Access Server Access Server to Client
+ SIGNATURE text text
+ SET-BAUDRATE 1 101
+ SET-DATASIZE 2 102
+ SET-PARITY 3 103
+ SET-STOPSIZE 4 104
+ SET-CONTROL 5 105
+ NOTIFY-LINESTATE 6 106
+ NOTIFY-MODEMSTATE 7 107
+ FLOWCONTROL-SUSPEND 8 108
+ FLOWCONTROL-RESUME 9 109
+ SET-LINESTATE-MASK 10 110
+ SET-MODEMSTATE-MASK 11 111
+ PURGE-DATA 12 112
+
+ Discussion: As initially proposed, com port configuration
+ commands are only sent from the client to the access
+ server. There is no current vision that the access
+ server would initiate the use of a com port configuration
+ command, only the notify commands. However, to allow for
+ access server initiated com port configurations different
+ command values have been established.
+
+1. Negotiation of the Com Port Control Option Protocol
+
+ The negotiation of the com port control option protocol uses the
+ standard Telnet negotiation protocol mechanism:
+
+ IAC WILL COM-PORT-OPTION
+ The sender of this command is willing to send com port
+ control option commands.
+ IAC WONT COM-PORT-OPTION
+ The sender of this command refuses to send com port
+ control option commands.
+ IAC DO COM-PORT-OPTION
+ The sender of this command is willing to accept com port
+ control option commands.
+ IAC DONT COM-PORT-OPTION
+ The sender of this command refuses to accept com port control
+ options commands.
+
+ Typically a client will use WILL and WONT, while an access server
+ will use DO and DONT.
+
+
+
+
+
+
+
+
+Clark Experimental [Page 5]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+2. Com Port Configuration Commands
+
+ Once DO and WILL have been negotiated, the client may send any of the
+ following commands. The client can send these commands at any time
+ and multiple times throughout the Telnet session. Each command
+ transmitted from the client to the access server must be acknowledged
+ once the command has been processed by the access server. This
+ confirmation informs the client of the value set at the access server
+ after the processing of the command. This acknowledgment is not used
+ to acknowledge the receipt of the command, which is handled at the
+ TCP protocol layer. Its purpose is to inform the client of the value
+ in use, which may be different than the value requested in the
+ client's command. For example, the client may request a baud rate
+ higher than the access service can provide. If an acknowledgment is
+ not received by the client within a reasonable time (such as twice
+ the delay acknowledgment timer), the client may wish to resend the
+ command or terminate the session.
+
+ Though the commands may be sent from the client to the access server
+ in any sequence, there are sequences which may result in invalid
+ configurations for the com port (for example: EVEN parity is only
+ valid if the data size is set to less than 8 bits). Thus it is
+ recommended that commands be issued in the following sequence:
+
+ 1. SET-BAUDRATE
+ 2. SET-DATASIZE
+ 3. SET-PARITY
+ 4. SET-STOPSIZE
+
+ IAC SB COM-PORT-OPTION SIGNATURE <text> IAC SE
+ This command may be sent by either the client or the access
+ server to exchange signature information. If the command is
+ sent without <text> it is a request from the sender to receive
+ the signature text of the receiver. The text may be a
+ combination of any characters. There is no structure to the
+ <text> field. It may contain manufacturer information, version
+ number information, or any other information desired. If an
+ IAC character appears in the text it must be translated to
+ IAC-IAC to avoid conflict with the IAC which terminates
+ the command.
+
+ IAC SB COM-PORT-OPTION SET-BAUD <value(4)> IAC SE
+ This command is sent by the client to the access server to set
+ the baud rate of the com port. The value is four octets (4 bytes).
+ The value is represented in network standard format. The value
+ is the baud rate being requested. A special case is the value 0.
+ If the value is zero the client is requesting the current baud
+ rate of the com port on the access server.
+
+
+
+Clark Experimental [Page 6]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+ Discussion: Though baud rates used today form a very sparse space,
+ and the initial version of the option used an index
+ based baud rate table, after much discussion with a
+ number of groups it has been determined that the
+ actual baud rate should be used. There are two main
+ reasons. 1) It limits the number of updates to the
+ option as faster baud rates come into use,
+ 2) It provides the greatest amount of flexibility
+ in the selection of the baud rates.
+
+ IAC SB COM-PORT-OPTION SET-DATASIZE <value> IAC SE
+ This command is sent by the client to the access server to set
+ the data bit size. The command can also be sent to query the
+ current data bit size. The value is one octet (byte). The value
+ is an index into the following value table:
+
+ Value Data Bit Size
+ 0 Request Current Data Bit Size
+ 1 Available for Future Use
+ 2 Available for Future Use
+ 3 Available for Future Use
+ 4 Available for Future Use
+ 5 5
+ 6 6
+ 7 7
+ 8 8
+ 9-127 Available for Future Use
+
+ Discussion: There are only eight possible values for the data bit
+ size, only four have ever been used historically and
+ only two are commonly used today. The use of the
+ command-value format is recommended to preserve
+ consistency with other commands. It also reduces the
+ number of commands defined in the protocol, and
+ allows for future expansion.
+
+ IAC SB COM-PORT-OPTION SET-PARITY <value> IAC SE
+ This command is sent by the client to the access server to set
+ the parity. The command can also be sent to query the current
+ parity. The value is one octet (byte). The value is an index into
+ the following value table:
+
+ Value Parity [1]
+ 0 Request Current Data Size
+ 1 NONE
+ 2 ODD
+ 3 EVEN
+ 4 MARK
+
+
+
+Clark Experimental [Page 7]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+ 5 SPACE
+ 6-127 Available for Future Use
+
+ Discussion: There are only five possible values for parity
+ commonly used today. The use of the command-value
+ format is recommended to preserve consistency with
+ other commands.
+
+ IAC SB COM-PORT-OPTION SET-STOPSIZE <value> IAC SE
+ This command is sent by the client to the access server to set
+ the number of stop bits. The command can also be sent to query
+ the current stop bit size. The value is one octet (byte). The
+ value is an index into the following value table:
+
+ Value Stop Bit Size
+ 0 Request Current Data Size
+ 1 1
+ 2 2
+ 3 1.5
+ 4-127 Available for Future Use
+
+ Discussion: Stop bit 1.5 is supported by most com port hardware
+ only if data size is set to 5 bits. It is not
+ commonly used.
+
+3. Special Com Port Control Commands
+
+ The client can send this command to the access server at any time
+ and multiple times throughout the Telnet session. Each command
+ transmitted from the client to the access server is acknowledged
+ with a confirmation of the command and the actual value set. The
+ client should expect a response within a reasonable time (such as
+ twice the delay acknowledgment timer). The client may wish to
+ resend any command which is not acknowledged or terminate the
+ session.
+
+ IAC SB COM-PORT-OPTION SET-CONTROL <value> IAC SE
+ This command is sent by the client to the access server to set
+ special com port options. The command can also be sent to query
+ the current option value. The value is one octet (byte). The
+ value is an index into the following value table:
+
+ Value Control Commands
+ 0 Request Com Port Flow Control Setting
+ (outbound/both)
+ 1 Use No Flow Control (outbound/both)
+ 2 Use XON/XOFF Flow Control (outbound/both)
+ 3 Use HARDWARE Flow Control (outbound/both)
+
+
+
+Clark Experimental [Page 8]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+ 4 Request BREAK State
+ 5 Set BREAK State ON
+ 6 Set BREAK State OFF
+ 7 Request DTR Signal State
+ 8 Set DTR Signal State ON
+ 9 Set DTR Signal State OFF
+ 10 Request RTS Signal State
+ 11 Set RTS Signal State ON
+ 12 Set RTS Signal State OFF
+ 13 Request Com Port Flow Control Setting (inbound)
+ 14 Use No Flow Control (inbound)
+ 15 Use XON/XOFF Flow Control (inbound)
+ 16 Use HARDWARE Flow Control (inbound)
+ 17 Use DCD Flow Control (outbound/both)
+ 18 Use DTR Flow Control (inbound)
+ 19 Use DSR Flow Control (outbound/both)
+ 20-127 Available for Future Use
+
+ Discussion: Flow control options were divided into inbound and
+ outbound to take full advantage of existing
+ programming interfaces and access server
+ capabilities.
+
+ Discussion: The outbound values should set flow control for both
+ outbound and inbound. If inbound is to be, or can
+ be, set separately it should be done after the
+ setting of the outbound value.
+
+ Discussion: If the access server is not able to set inbound flow
+ control differently from the outbound flow control,
+ it should ignore the inbound flow control commands
+ and set the flow control option based on the outbound
+ flow control commands only.
+
+ IAC SB COM-PORT-OPTION SET-LINESTATE-MASK <value> IAC SE
+ This command is sent by the client to the access server to set a
+ bit mask for the sending of the NOTIFY-LINESTATE option (see
+ section 4). When the LINESTATE changes on the access server, the
+ access server will "AND" the new LINESTATE with the LINESTATE-
+ MASK. If the result is not zero, the access server will send the
+ result of the "AND" as the value in a NOTIFY-LINESTATE com port
+ option. If more than one bit satisfies the LINESTATE-MASK, only
+ one NOTIFY-LINESTATE, with all the satisfying bits, will be sent
+ to the client. The SET-LINESTATE-MASK may be any combination of
+ bits as listed below. These are the same bit values used in the
+ NOTIFY-LINESTATE option. The SET-LINESTATE-MASK values are based
+ on the most popular UART (com port control chip) in use [1].
+
+
+
+
+Clark Experimental [Page 9]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+ Bit Position Value Meaning
+ 7 128 Time-out Error
+ 6 64 Transfer Shift Register Empty
+ 5 32 Transfer Holding Register Empty
+ 4 16 Break-detect Error
+ 3 8 Framing Error
+ 2 4 Parity Error
+ 1 2 Overrun Error
+ 0 1 Data Ready
+
+ Discussion: The SET-LINESTATE-MASK value of 0 will prevent the
+ access server from sending NOTIFY-LINESTATE options
+ to the client.
+
+ Discussion: The SET-LINESTATE-MASK value of 255 will allow the
+ access server to send a NOTIFY-LINESTATE option to
+ the client each time the LINESTATE changes on the
+ access server.
+
+ Discussion: The initial LINESTATE-MASK at the access server is 0.
+
+ Discussion: The client does not have to send a new
+ SET-LINESTATE-MASK after receiving a NOTIFY-
+ LINESTATE. The LINESTATE-MASK on the access server
+ is retained until set by the client or reset at the
+ start of a new Telnet session.
+
+ IAC SB COM-PORT-OPTION SET-MODEMSTATE-MASK <value> IAC SE
+ This command is sent by the client to the access server to set a
+ bit mask for the sending of the NOTIFY-MODEMSTATE option (see
+ section 4). When the MODEMSTATE changes on the access server,
+ the access server will "AND" the new MODEMSTATE with the
+ MODEMSTATE-MASK. If the result is not zero, the access server
+ will send the result of the "AND" as the value in a NOTIFY-
+ MODEMSTATE com port option. If more than one bit satisfies the
+ MODEMSTATE-MASK, only one NOTIFY-MODEMSTATE, with all the
+ satisfying bits, will be sent to the client. The SET-
+ MODEMSTATE-MASK may be any combination of bits as listed below.
+ These are the same bit values used in the NOTIFY-MODEMSTATE
+ option. The SET-MODEMSTATE-MASK values are based on the most
+ popular UART (com port control chip) in use [1].
+
+
+
+
+
+
+
+
+
+
+Clark Experimental [Page 10]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+ Bit Position Value Meaning
+ 7 128 Receive Line Signal Detect
+ (also known as Carrier Detect)
+ 6 64 Ring Indicator
+ 5 32 Data-Set-Ready Signal State
+ 4 16 Clear-To-Send Signal State
+ 3 8 Delta Receive Line Signal Detect
+ 2 4 Trailing-edge Ring Detector
+ 1 2 Delta Data-Set-Ready
+ 0 1 Delta Clear-To-Send
+
+ Discussion: The SET-MODEMSTATE-MASK value of 0 will prevent the
+ access server from sending NOTIFY-MODEMSTATE options
+ to the client.
+
+ Discussion: The SET-MODEMSTATE-MASK value of 255 will allow the
+ access server to send a NOTIFY-MODEMSTATE option to
+ the client each time the MODEMSTATE changes on the
+ access server.
+
+ Discussion: The initial MODEMSTATE-MASK at the access server
+ is 255.
+
+ Discussion: The client does not have to send a new
+ SET-MODEMSTATE-MASK after receiving a NOTIFY-
+ MODEMSTATE. The MODEMSTATE-MASK on the access server
+ is retained until set by the client or reset at the
+ start of a new Telnet session.
+
+ IAC SB COM-PORT-OPTION PURGE-DATA <value> IAC SE
+ This command is sent by the client to the access server to
+ instruct the access server to immediately clear all data from the
+ buffer or buffers referenced by the value. The value is one
+ octet (byte). The value is an index into the following value
+ table:
+
+ Value Purge Data Buffer
+ 0 Available for Future Use
+ 1 Purge access server receive data buffer
+ 2 Purge access server transmit data buffer
+ 3 Purge both the access server receive data
+ buffer and the access server transmit data
+ buffer
+ 4-127 Available for Future Use
+
+
+
+
+
+
+
+Clark Experimental [Page 11]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+4. Notification of Com port and Modem Line Changes
+
+ The access server can send these commands to the client any time
+ and multiple times throughout the Telnet session. The access
+ server should send the appropriate command to the client as soon
+ as the com port or modem line changes occurs. The client does
+ not issue a response to these commands.
+
+ IAC SB COM-PORT-OPTION NOTIFY-LINESTATE <value> IAC SE
+ The value is one octet (byte). The value is a bit level
+ composition made up from the value table below. Multiple bit
+ values may be set in a single transmission. The values are based
+ on the most popular UART (com port control chip) in use [1].
+
+ Bit Position Value Meaning
+ 7 128 Time-out Error
+ 6 64 Transfer Shift Register Empty
+ 5 32 Transfer Holding Register Empty
+ 4 16 Break-detect Error
+ 3 8 Framing Error
+ 2 4 Parity Error
+ 1 2 Overrun Error
+ 0 1 Data Ready
+
+
+ Discussion: The LINESTATE is the line state of the UART on
+ the access server.
+
+ IAC SB COM-PORT-OPTION NOTIFY-MODEMSTATE <value> IAC SE
+ The value is one octet (byte). The value is a bit level
+ composition made up from the value table below. Multiple bit
+ values may be set in a single transmission. The values are based
+ on the most popular UART (com port control chip) in use [1].
+
+ Bit Position Value Meaning
+ 7 128 Receive Line Signal Detect
+ (also known as Carrier Detect)
+ 6 64 Ring Indicator
+ 5 32 Data-Set-Ready Signal State
+ 4 16 Clear-To-Send Signal State
+ 3 8 Delta Receive Line Signal Detect
+ 2 4 Trailing-edge Ring Detector
+ 1 2 Delta Data-Set-Ready
+ 0 1 Delta Clear-To-Send
+
+
+
+
+
+
+
+Clark Experimental [Page 12]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+5. Flow Control
+
+ The client and/or access server can send these commands any time and
+ multiple times throughout the Telnet session.
+
+ IAC SB COM-PORT-OPTION FLOWCONTROL-SUSPEND IAC SE
+ The sender of this command is requesting that the receiver
+ suspend transmission of both data and commands until the
+ FLOWCONTROL-RESUME is transmitted by the sender.
+
+ IAC SB COM-PORT-OPTION FLOWCONTROL-RESUME IAC SE
+ The sender of this command is requesting that the receiver resume
+ transmission of both data and commands.
+
+ Discussion: Established Telnet sessions are initially in a
+ resume state between the client and the access server
+ and the access server and the client. There is no
+ need to send the resume command during session
+ initialization.
+
+ Discussion: Multiple concurrent suspend commands may be sent.
+ Secondary suspend commands can be ignored.
+ Transmission will resume with the sending of a single
+ resume command.
+
+ Discussion: The flow control option is designed to handle client
+ to access server flow control for the Telnet session.
+ This option has been added in deference to RFC 1372:
+ Telnet Remote Flow Control Option [2]. RFC 1372 uses
+ a simple character XON/XOFF technology to implement
+ flow control. This can lead to two problems. First,
+ the flow control characters may be valid data values.
+ Second, the flow control characters may be used for
+ end to end flow control (client application to remote
+ dial up service).
+
+6. Security Considerations
+
+ There are two security issues to discuss; authentication and
+ resetting resources.
+
+ Authentication can follow either the Kerberos authentication protocol
+ established in RFC 1411 [3] or the SPX authentication protocol
+ established in RFC 1412 [4].
+
+ Once the Telnet session between the client and the access server has
+ been terminated, the access server should ensure the connection to
+ the remote service is disconnected and the com port geometry (baud
+
+
+
+Clark Experimental [Page 13]
+
+RFC 2217 Telnet Com Port Control Option October 1997
+
+
+ rate, data size, stop bits, parity, and flow control) is reset to a
+ factory or administrator defined configuration. This ensures the com
+ port is in a known state and ready to receive the next client
+ session. This will make operations more predicable and avoid
+ problems which might occur from starting a new session with random
+ com port configurations.
+
+7. Author's Address
+
+ Glen Clark, Software Architect
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 96134
+ USA
+
+ EMail: glenc@cisco.com
+ WEB: www.cisco.com
+
+8. Reference Section
+
+ [1] Joe Campbell. C Programmer's Guide to Serial Communications,
+ Second Edition. Indianapolis: SAMS Publishing, 1993. 213-224.
+
+ [2] Hedrick, C., and D. Borman, "Telnet Remote Flow Control Option",
+ RFC 1372, Cray Research, Inc., October 1992.
+
+ [3] Borman, D., "Telnet Authentication: Kerberos Version 4",
+ RFC 1411, Cray Research, Inc., January 1993.
+
+ [4] Alagappan, K., "Telnet Authentication: SPX",
+ RFC 1412, Digital Equipment Corporation, January 1993.
+
+ [5] D. E. Comer and David Stevens. Internetworking with TCP/IP,
+ Volume III. Prentice Hall, 1993.
+
+ [6] Andrew Margolis. The FAX Modem Sourcebook. John Wiley & Sons.
+ 1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark Experimental [Page 14]
+