RFC 1001
Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods
Network Working Group Request for Comments: 1001 March, 1987 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS ABSTRACT This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques. Detailed specifications are found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".
SUMMARY OF CONTENTS
1. STATUS OF THIS MEMO 6
2. ACKNOWLEDGEMENTS 6
3. INTRODUCTION 7
4. DESIGN PRINCIPLES 7
5. OVERVIEW OF NetBIOS 10
6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD 15
7. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS 15
8. RELATED PROTOCOLS AND SERVICES 16
9. NetBIOS SCOPE 16
10. NetBIOS END-NODES 16
11. NetBIOS SUPPORT SERVERS 18
12. TOPOLOGIES 20
13. GENERAL METHODS 23
14. REPRESENTATION OF NETBIOS NAMES 25
15. NetBIOS NAME SERVICE 27
16. NetBIOS SESSION SERVICE 48
17. NETBIOS DATAGRAM SERVICE 55
18. NODE CONFIGURATION PARAMETERS 58
19. MINIMAL CONFORMANCE 59
REFERENCES 60
APPENDIX A - INTEGRATION WITH INTERNET GROUP MULTICASTING 61
APPENDIX B - IMPLEMENTATION CONSIDERATIONS 62
TABLE OF CONTENTS 1. STATUS OF THIS MEMO 6 2. ACKNOWLEDGEMENTS 6 3. INTRODUCTION 7 4. DESIGN PRINCIPLES 8 4.1 PRESERVE NetBIOS SERVICES 8 4.2 USE EXISTING STANDARDS 8 4.3 MINIMIZE OPTIONS 8 4.4 TOLERATE ERRORS AND DISRUPTIONS 8 4.5 DO NOT REQUIRE CENTRAL MANAGEMENT 9 4.6 ALLOW INTERNET OPERATION 9 4.7 MINIMIZE BROADCAST ACTIVITY 9 4.8 PERMIT IMPLEMENTATION ON EXISTING SYSTEMS 9 4.9 REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE 9 4.10 MAXIMIZE EFFICIENCY 10 4.11 MINIMIZE NEW INVENTIONS 10 5. OVERVIEW OF NetBIOS 10 5.1 INTERFACE TO APPLICATION PROGRAMS 10 5.2 NAME SERVICE 11 5.3 SESSION SERVICE 12 5.4 DATAGRAM SERVICE 13 5.5 MISCELLANEOUS FUNCTIONS 14 5.6 NON-STANDARD EXTENSIONS 15 6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD 15 7. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS 15 8. RELATED PROTOCOLS AND SERVICES 16 9. NetBIOS SCOPE 16 10. NetBIOS END-NODES 16 10.1 BROADCAST (B) NODES 16 10.2 POINT-TO-POINT (P) NODES 16 10.3 MIXED MODE (M) NODES 16 11. NetBIOS SUPPORT SERVERS 18 11.1 NetBIOS NAME SERVER (NBNS) NODES 18 11.1.1 RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM 19 11.2 NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES 19 11.3 RELATIONSHIP OF NBNS AND NBDD NODES 20 11.4 RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES 20 12. TOPOLOGIES 20 12.1 LOCAL 20
12.1.1 B NODES ONLY 21
12.1.2 P NODES ONLY 21
12.1.3 MIXED B AND P NODES 21
12.2 INTERNET 22
12.2.1 P NODES ONLY 22
12.2.2 MIXED M AND P NODES 23
13. GENERAL METHODS 23
13.1 REQUEST/RESPONSE INTERACTION STYLE 23
13.1.1 RETRANSMISSION OF REQUESTS 24
13.1.2 REQUESTS WITHOUT RESPONSES: DEMANDS 24
13.2 TRANSACTIONS 25
13.2.1 TRANSACTION ID 25
13.3 TCP AND UDP FOUNDATIONS 25
14. REPRESENTATION OF NETBIOS NAMES 25
14.1 FIRST LEVEL ENCODING 26
14.2 SECOND LEVEL ENCODING 27
15. NetBIOS NAME SERVICE 27
15.1 OVERVIEW OF NetBIOS NAME SERVICE 27
15.1.1 NAME REGISTRATION (CLAIM) 27
15.1.2 NAME QUERY (DISCOVERY) 28
15.1.3 NAME RELEASE 28
15.1.3.1 EXPLICIT RELEASE 28
15.1.3.2 NAME LIFETIME AND REFRESH 29
15.1.3.3 NAME CHALLENGE 29
15.1.3.4 GROUP NAME FADE-OUT 29
15.1.3.5 NAME CONFLICT 30
15.1.4 ADAPTER STATUS 31
15.1.5 END-NODE NBNS INTERACTION 31
15.1.5.1 UDP, TCP, AND TRUNCATION 31
15.1.5.2 NBNS WACK 32
15.1.5.3 NBNS REDIRECTION 32
15.1.6 SECURED VERSUS NON-SECURED NBNS 32
15.1.7 CONSISTENCY OF THE NBNS DATA BASE 32
15.1.8 NAME CACHING 34
15.2 NAME REGISTRATION TRANSACTIONS 34
15.2.1 NAME REGISTRATION BY B NODES 34
15.2.2 NAME REGISTRATION BY P NODES 35
15.2.2.1 NEW NAME, OR NEW GROUP MEMBER 35
15.2.2.2 EXISTING NAME AND OWNER IS STILL ACTIVE 36
15.2.2.3 EXISTING NAME AND OWNER IS INACTIVE 37
15.2.3 NAME REGISTRATION BY M NODES 38
15.3 NAME QUERY TRANSACTIONS 39
15.3.1 QUERY BY B NODES 39
15.3.2 QUERY BY P NODES 40
15.3.3 QUERY BY M NODES 43
15.3.4 ACQUIRE GROUP MEMBERSHIP LIST 43
15.4 NAME RELEASE TRANSACTIONS 44
15.4.1 RELEASE BY B NODES 44
15.4.2 RELEASE BY P NODES 44
15.4.3 RELEASE BY M NODES 44
15.5 NAME MAINTENANCE TRANSACTIONS 45
15.5.1 NAME REFRESH 45
15.5.2 NAME CHALLENGE 46
15.5.3 CLEAR NAME CONFLICT 47
15.6 ADAPTER STATUS TRANSACTIONS 47
16. NetBIOS SESSION SERVICE 48
16.1 OVERVIEW OF NetBIOS SESSION SERVICE 49
16.1.1 SESSION ESTABLISHMENT PHASE OVERVIEW 49
16.1.1.1 RETRYING AFTER BEING RETARGETTED 50
16.1.1.2 SESSION ESTABLISHMENT TO A GROUP NAME 51
16.1.2 STEADY STATE PHASE OVERVIEW 51
16.1.3 SESSION TERMINATION PHASE OVERVIEW 51
16.2 SESSION ESTABLISHMENT PHASE 52
16.3 SESSION DATA TRANSFER PHASE 54
16.3.1 DATA ENCAPSULATION 54
16.3.2 SESSION KEEP-ALIVES 54
17. NETBIOS DATAGRAM SERVICE 55
17.1 OVERVIEW OF NetBIOS DATAGRAM SERVICE 55
17.1.1 UNICAST, MULTICAST, AND BROADCAST 55
17.1.2 FRAGMENTATION OF NetBIOS DATAGRAMS 55
17.2 NetBIOS DATAGRAMS BY B NODES 57
17.3 NetBIOS DATAGRAMS BY P AND M NODES 58
18. NODE CONFIGURATION PARAMETERS 58
19. MINIMAL CONFORMANCE 59
REFERENCES 60
APPENDIX A 61
INTEGRATION WITH INTERNET GROUP MULTICASTING 61
A-1. ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES 61
A-2. CONSTRAINTS 61
APPENDIX B 62
IMPLEMENTATION CONSIDERATIONS 62
B-1. IMPLEMENTATION MODELS 62
B-1.1 MODEL INDEPENDENT CONSIDERATIONS 63
B-1.2 SERVICE OPERATION FOR EACH MODEL 63
B-2. CASUAL AND RESTRICTED NetBIOS APPLICATIONS 64
B-3. TCP VERSUS SESSION KEEP-ALIVES 66
B-4. RETARGET ALGORITHMS 67
B-5. NBDD SERVICE 68
B-6. APPLICATION CONSIDERATIONS 68
B-6.1 USE OF NetBIOS DATAGRAMS 68
PROTOCOL STANDARD FOR A NetBIOS SERVICE
ON A TCP/UDP TRANSPORT:
CONCEPTS AND METHODS
1. STATUS OF THIS MEMO
This RFC specifies a proposed standard for the Internet
community. Since this topic is new to the Internet community,
discussions and suggestions are specifically requested.
Please send written comments to:
Karl Auerbach
Epilogue Technology Corporation
P.O. Box 5432
Redwood City, CA 94063
Please send online comments to:
Avnish Aggarwal
Internet: mtxinu!excelan!avnish@ucbvax.berkeley.edu
Usenet: ucbvax!mtxinu!excelan!avnish
Distribution of this document is unlimited.
2. ACKNOWLEDGEMENTS
This RFC has been developed under the auspices of the Internet
Activities Board, especially the End-to-End Services Task Force.
The following individuals have contributed to the development of
this RFC:
Avnish Aggarwal Arvind Agrawal Lorenzo Aguilar
Geoffrey Arnold Karl Auerbach K. Ramesh Babu
Keith Ball Amatzia Ben-Artzi Vint Cerf
Richard Cherry David Crocker Steve Deering
Greg Ennis Steve Holmgren Jay Israel
David Kaufman Lee LaBarre James Lau
Dan Lynch Gaylord Miyata David Stevens
Steve Thomas Ishan Wu
The system proposed by this RFC does not reflect any existing
Netbios-over-TCP implementation. However, the design
incorporates considerable knowledge obtained from prior
implementations. Special thanks goes to the following
organizations which have provided this invaluable information:
CMC/Syros Excelan Sytek Ungermann-Bass
3. INTRODUCTION This RFC describes the ideas and general methods used to provide NetBIOS on a TCP and UDP foundation. A companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications"[1] contains detailed descriptions of packet formats, protocols, and defined constants and variables. The NetBIOS service has become the dominant mechanism for personal computer networking. NetBIOS provides a vendor independent interface for the IBM Personal Computer (PC) and compatible systems. NetBIOS defines a software interface not a protocol. There is no "official" NetBIOS service standard. In practice, however, the IBM PC-Network version is used as a reference. That version is described in the IBM document 6322916, "Technical Reference PC Network"[2]. Protocols supporting NetBIOS services have been constructed on diverse protocol and hardware foundations. Even when the same foundation is used, different implementations may not be able to interoperate unless they use a common protocol. To allow NetBIOS interoperation in the Internet, this RFC defines a standard protocol to support NetBIOS services using TCP and UDP. NetBIOS has generally been confined to personal computers to date. However, since larger computers are often well suited to run certain NetBIOS applications, such as file servers, this specification has been designed to allow an implementation to be built on virtually any type of system where the TCP/IP protocol suite is available. This standard defines a set of protocols to support NetBIOS services. These protocols are more than a simple communications service involving two entities. Rather, this note describes a distributed system in which many entities play a part even if they are not involved as an end-point of a particular NetBIOS connection. This standard neither constrains nor determines how those services are presented to application programs. Nevertheless, it is expected that on computers operating under the PC-DOS and MS-DOS operating systems that the existing NetBIOS interface will be preserved by implementors. NOTE: Various symbolic values are used in this document. For their definitions, refer to the Detailed Specifications[1].
4. DESIGN PRINCIPLES In order to develop the specification the following design principles were adopted to guide the effort. Most are typical to any protocol standardization effort; however, some have been assigned priorities that may be considered unusual. 4.1. PRESERVE NetBIOS SERVICES In the absence of an "official" standard for NetBIOS services, the version found in the IBM PC Network Technical Reference[2] is used. NetBIOS is the foundation of a large body of existing applications. It is desirable to operate these applications on TCP networks and to extend them beyond personal computers into larger hosts. To support these applications, NetBIOS on TCP must closely conform to the services offered by existing NetBIOS systems. IBM PC-Network NetBIOS contains some implementation specific characteristics. This standard does not attempt to completely preserve these. It is certain that some existing software requires these characteristics and will fail to operate correctly on a NetBIOS service based on this RFC. 4.2. USE EXISTING STANDARDS Protocol development, especially with standardization, is a demanding process. The development of new protocols must be minimized. It is considered essential that an existing standard which provides the necessary functionality with reasonable performance always be chosen in preference to developing a new protocol. When a standard protocol is used, it must be unmodified. 4.3. MINIMIZE OPTIONS The standard for NetBIOS on TCP should contain few, if any, options. Where options are included, the options should be designed so that devices with different option selections should interoperate. 4.4. TOLERATE ERRORS AND DISRUPTIONS NetBIOS networks typically operate in an uncontrolled environment. Computers come on-line at arbitrary times. Computers usually go off-line without any notice to their peers. The software is often operated by users who are unfamiliar with networks and who may randomly perturb configuration settings. Despite this chaos, NetBIOS networks work. NetBIOS on TCP must also
be able to operate well in this environment. Robust operation does not necessarily mean that the network is proof against all disruptions. A typical NetBIOS network may be disrupted by certain types of behavior, whether inadvertent or malicious. 4.5. DO NOT REQUIRE CENTRAL MANAGEMENT NetBIOS on TCP should be able to operate, if desired, without centralized management beyond that typically required by a TCP based network. 4.6. ALLOW INTERNET OPERATION The proposed standard recognizes the need for NetBIOS operation across a set of networks interconnected by network (IP) level relays (gateways.) However, the standard assumes that this form of operation will be less frequent than on the local MAC bridged-LAN. 4.7. MINIMIZE BROADCAST ACTIVITY The standard pre-supposes that the only broadcast services are those supported by UDP. Multicast capabilities are not assumed to be available in any form. Despite the availability of broadcast capabilities, the standard recognizes that some administrations may wish to avoid heavy broadcast activity. For example, an administration may wish to avoid isolated non-participating hosts from the burden of receiving and discarding NetBIOS broadcasts. 4.8. PERMIT IMPLEMENTATION ON EXISTING SYSTEMS The NetBIOS on TCP protocol should be implementable on common operating systems, such as Unix(tm) and VAX/VMS(tm), without massive effort. The NetBIOS protocols should not require services typically unavailable on presently existing TCP/UDP/IP implementations. 4.9. REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE The protocol definition should specify only the minimal set of protocols required for interoperation. However, additional protocol elements may be defined to enhance efficiency. These latter elements may be generated at the option of the sender, although they must be accepted by all receivers.
4.10. MAXIMIZE EFFICIENCY To be useful, a protocol must conduct its business quickly. 4.11. MINIMIZE NEW INVENTIONS When an existing protocol is not quite able to support a necessary function, but with a small amount of change, it could, that protocol should be used. This is felt to be easier to achieve than development of new protocols; further, it is likely to have more general utility for the Internet. 5. OVERVIEW OF NetBIOS This section describes the NetBIOS services. It is for background information only. The reader may chose to skip to the next section. NetBIOS was designed for use by groups of PCs, sharing a broadcast medium. Both connection (Session) and connectionless (Datagram) services are provided, and broadcast and multicast are supported. Participants are identified by name. Assignment of names is distributed and highly dynamic. NetBIOS applications employ NetBIOS mechanisms to locate resources, establish connections, send and receive data with an application peer, and terminate connections. For purposes of discussion, these mechanisms will collectively be called the NetBIOS Service. This service can be implemented in many different ways. One of the first implementations was for personal computers running the PC-DOS and MS-DOS operating systems. It is possible to implement NetBIOS within other operating systems, or as processes which are, themselves, simply application programs as far as the host operating system is concerned. The NetBIOS specification, published by IBM as "Technical Reference PC Network"[2] defines the interface and services available to the NetBIOS user. The protocols outlined by that document pertain only to the IBM PC Network and are not generally applicable to other networks. 5.1. INTERFACE TO APPLICATION PROGRAMS NetBIOS on personal computers includes both a set of services and an exact program interface to those services. NetBIOS on other computer systems may present the NetBIOS services to programs using other interfaces. Except on personal computers, no clear standard for a NetBIOS software interface has emerged.
5.2. NAME SERVICE NetBIOS resources are referenced by name. Lower-level address information is not available to NetBIOS applications. An application, representing a resource, registers one or more names that it wishes to use. The name space is flat and uses sixteen alphanumeric characters. Names may not start with an asterisk (*). Registration is a bid for use of a name. The bid may be for exclusive (unique) or shared (group) ownership. Each application contends with the other applications in real time. Implicit permission is granted to a station when it receives no objections. That is, a bid is made and the application waits for a period of time. If no objections are received, the station assumes that it has permission. A unique name should be held by only one station at a time. However, duplicates ("name conflicts") may arise due to errors. All instances of a group name are equivalent. An application referencing a name generally does not know (or care) whether the name is registered as a unique or a group name. An explicit name deletion function is specified, so that applications may remove a name. Implicit name deletion occurs when a station ceases operation. In the case of personal computers, implicit name deletion is a frequent occurrence. The Name Service primitives are: 1) Add Name The requesting application wants exclusive use of the name. 2) Add Group Name The requesting application is willing to share use of the name with other applications. 3) Delete Name The application no longer requires use of the name. It is important to note that typical use of NetBIOS is among independently-operated personal computers. A common way to stop using a PC is to turn it off; in this case, the graceful give-back mechanism, provided by the Delete Name function, is not used. Because this occurs frequently, the network service must support this behavior.
5.3. SESSION SERVICE A session is a reliable message exchange, conducted between a pair of NetBIOS applications. Sessions are full-duplex, sequenced, and reliable. Data is organized into messages. Each message may range in size from 0 to 131,071 bytes. No expedited or urgent data capabilities are present. Multiple sessions may exist between any pair of calling and called names. The parties to a connection have access to the calling and called names. The NetBIOS specification does not define how a connection request to a shared (group) name resolves into a session. The usual assumption is that a session may be established with any one owner of the called group name. An important service provided to NetBIOS applications is the detection of sessions failure. The loss of a session is reported to an application via all of the outstanding service requests for that session. For example, if the application has only a NetBIOS receive primitive pending and the session terminates, the pending receive will abort with a termination indication. Session Service primitives are: 1) Call Initiate a session with a process that is listening under the specified name. The calling entity must indicate both a calling name (properly registered to the caller) and a called name. 2) Listen Accept a session from a caller. The listen primitive may be constrained to accept an incoming call from a named caller. Alternatively, a call may be accepted from any caller. 3) Hang Up Gracefully terminate a session. All pending data is transferred before the session is terminated. 4) Send Transmit one message. A time-out can occur. A time-out of any session send forces the non-graceful termination of the session.
A "chain send" primitive is required by the PC NetBIOS
software interface to allow a single message to be gathered
from pieces in various buffers. Chain Send is an interface
detail and does not effect the protocol.
5) Receive
Receive data. A time-out can occur. A time-out on a
session receive only terminates the receive, not the
session, although the data is lost.
The receive primitive may be implemented with variants, such
as "Receive Any", which is required by the PC NetBIOS
software interface. Receive Any is an interface detail and
does not effect the protocol.
6) Session Status
Obtain information about all of the requestor's sessions,
under the specified name. No network activity is involved.
5.4. DATAGRAM SERVICE
The Datagram service is an unreliable, non-sequenced, connectionless
service. Datagrams are sent under cover of a name properly
registered to the sender.
Datagrams may be sent to a specific name or may be explicitly
broadcast.
Datagrams sent to an exclusive name are received, if at all, by the
holder of that name. Datagrams sent to a group name are multicast to
all holders of that name. The sending application program cannot
distinguish between group and unique names and thus must act as if
all non-broadcast datagrams are multicast.
As with the Session Service, the receiver of the datagram is told the
sending and receiving names.
Datagram Service primitives are:
1) Send Datagram
Send an unreliable datagram to an application that is
associated with the specified name. The name may be unique
or group; the sender is not aware of the difference. If the
name belongs to a group, then each member is to receive the
datagram.
2) Send Broadcast Datagram
Send an unreliable datagram to any application with a
Receive Broadcast Datagram posted.
3) Receive Datagram
Receive a datagram sent by a specified originating name to
the specified name. If the originating name is an asterisk,
then the datagram may have been originated under any name.
Note: An arriving datagram will be delivered to all pending
Receiving Datagrams that have source and destination
specifications matching those of the datagram. In other
words, if a program (or group of programs) issue a series of
identical Receive Datagrams, one datagram will cause the
entire series to complete.
4) Receive Broadcast Datagram
Receive a datagram sent as a broadcast.
If there are multiple pending Receive Broadcast Datagram
operations pending, all will be satisfied by the same
received datagram.
5.5. MISCELLANEOUS FUNCTIONS
The following functions are present to control the operation of the
hardware interface to the network. These functions are generally
implementation dependent.
1) Reset
Initialize the local network adapter.
2) Cancel
Abort a pending NetBIOS request. The successful cancel of a
Send (or Chain Send) operation will terminate the associated
session.
3) Adapter Status
Obtain information about the local network adapter or of a
remote adapter.
4) Unlink
For use with Remote Program Load (RPL). Unlink redirects
the PC boot disk device back to the local disk. See the
NetBIOS specification for further details concerning RPL and
the Unlink operation (see page 2-35 in [2]).
5) Remote Program Load
Remote Program Load (RPL) is not a NetBIOS function. It is
a NetBIOS application defined by IBM in their NetBIOS
specification (see pages 2-80 through 2-82 in [2]).
5.6. NON-STANDARD EXTENSIONS
The IBM Token Ring implementation of NetBIOS has added at least one
new user capability:
1) Find Name
This function determines whether a given name has been
registered on the network.
6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD
The protocol specified by this standard permits an implementer to
provide all of the NetBIOS services as described in the IBM
"Technical Reference PC Network"[2].
The following NetBIOS facilities are outside the scope of this
specification. These are local implementation matters and do not
impact interoperability:
- RESET
- SESSION STATUS
- UNLINK
- RPL (Remote Program Load)
7. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS
The protocols described in this RFC require service interfaces to the
following:
- TCP[3,4]
- UDP[5]
Byte ordering, addressing conventions (including addresses to be
used for broadcasts and multicasts) are defined by the most
recent version of:
- Assigned Numbers[6]
Additional definitions and constraints are in:
- IP[7]
- Internet Subnets[8,9,10]
8. RELATED PROTOCOLS AND SERVICES
The design of the protocols described in this RFC allow for the
future incorporation of the following protocols and services.
However, before this may occur, certain extensions may be required to
the protocols defined in this RFC or to those listed below.
- Domain Name Service[11,12,13,14]
- Internet Group Multicast[15,16]
9. NetBIOS SCOPE
A "NetBIOS Scope" is the population of computers across which a
registered NetBIOS name is known. NetBIOS broadcast and multicast
datagram operations must reach the entire extent of the NetBIOS
scope.
An internet may support multiple, non-intersecting NetBIOS Scopes.
Each NetBIOS scope has a "scope identifier". This identifier is a
character string meeting the requirements of the domain name system
for domain names.
NOTE: Each implementation of NetBIOS-over-TCP must provide
mechanisms to manage the scope identifier(s) to be used.
Control of scope identifiers implies a requirement for additional
NetBIOS interface capabilities. These may be provided through
extensions of the user service interface or other means (such as node
configuration parameters.) The nature of these extensions is not
part of this specification.
(page 16 continued on part 2)
