📄 rfc138.txt
字号:
Network Working Group Bob Anderson
Request for Comments: 138 Rand
NIC 6715 Vint Cerf
UCLA
Eric Harslem
John Heafner
Rand
Jim Madden
U. of Illinois
Bob Metcalfe
MIT
Arie Shoshani
SDC
Jim White
UCSB
David Wood
Mitre
28 April 1971
STATUS REPORT ON PROPOSED DATA RECONFIGURATION SERVICE
CONTENTS
I. INTRODUCTION ................................. 2
Purpose of this RFC .......................... 2
Motivation ................................... 2
II. OVERVIEW OF DATA RECONFIGURATION SERVICE ..... 3
Elements of Data Reconfiguration Service ..... 3
Conceptual Network Connections ............... 3
Connection Protocols and Message Formats ..... 4
Example Connection Configurations ............ 6
III. THE FORM MACHINE ............................. 7
Input/Output Stream and Forms ................ 7
Form Machine BNF Syntax ...................... 7
Alternate Specification of Form Machine Syntax 8
Forms ........................................ 9
Rules ........................................ 10
Terms ........................................ 10
Term Format 1 .............................. 11
Term Format 2 .............................. 11
Term Format 3 .............................. 13
Term Format 4 .............................. 13
Application of a Term ...................... 14
Anderson, et al. [Page 1]
RFC 138 Data Reconfiguration Service April 1971
Restrictions and Interpretations of
Term Functions ........................... 14
Term and Rule Sequencing ..................... 16
IV. EXAMPLES ..................................... 16
Remarks ...................................... 16
Field Insertion .............................. 17
Deletion ..................................... 17
Variable Length Records ...................... 17
String Length Computation .................... 18
Transposition ................................ 18
Character Packing and Unpacking .............. 18
V. PROPOSED USES OF DATA RECONFIGURATION SERVICE 19
VI. IMPLEMENTATION PLANS ......................... 20
Appendix A ......................................... 21
Note 1 to the DRS Working Group .............. 21
Note 2 to the DRS Working Group .............. 22
I. INTRODUCTION
PURPOSE OF THIS RFC
The purpose of this RFC is to describe, in part, a proposed Network
experiment and to solicit comments on any aspect of the experiment.
The experiment involves a software mechanism to reformat Network data
streams. The mechanism can be adapted to numerous Network
application programs. We hope that the results of the experiment
will lead to a further standard service that embodies the principles
described in this RFC. We would like comments on the
appropriateness of this work as a Network experiment and also
comments on particular Network data reformatting needs that could not
easily be accomplished using these techniques.
MOTIVATION
Application programs require specific data I/O formats yet the
formats are different from program to program. We take the position
that the Network should adapt to the individual program requirements
rather than changing each program to comply with a standard. This
position doesn't preclude the use of standards that describe the
formats of regular message contents; it is merely an interpretation
of a standard as being a desirable mode of operation but not a
necessary one.
Anderson, et al. [Page 2]
RFC 138 Data Reconfiguration Service April 1971
In addition to differing program requirements, a format mismatch
problem occurs where users wish to employ many different kinds of
consoles to attach to a single service program. It is desirable to
have the Network adapt to individual console configurations rather
than requiring unique software packages for each console
transformation.
One approach to providing adaptation is for those sites with
substantial computing power to offer a data reconfiguration service;
a proposed example of such a service is described here.
The envisioned modus operandi of the service is that an applications
programmer defines _forms_ that describe data reconfigurations. The
service stores the forms by name. At a later time, a user (perhaps a
non-programmer) employs the service to accomplish a particular
transformation of a Network data stream, simply by calling the form
by name.
We have attempted to provide a notation tailored to some specifically
needed instances of data reformatting while keeping the notation and
its underlying implementation within some utility range that is
bounded on the lower end by a notation expressive enough to make the
experimental service useful, and that is bounded on the upper end by
a notation short of a general purpose programming language.
II. OVERVIEW OF THE DATA RECONFIGURATION SERVICE
ELEMENTS OF THE DATA RECONFIGURATION SERVICE
An implementation of the Data Reconfiguration Service (DRS) includes
modules for connection protocols, a handler of some requests that can
be made of the service, a compiler and/or interpreter (called the
Form Machine) to act on those requests, and a file storage module for
saving and retrieving definitions of data reconfigurations (forms).
This section highlights connection protocols and requests. The next
section covers the Form Machine language in some detail. File
storage is not described in this document because it is transparent
to the use of the service and its implementation is different at each
DRS host.
CONCEPTUAL NETWORK CONNECTIONS
There are three conceptual Network connections to the DRS, see Fig.
1.
1) The control connection (CC) is between an originating user
and the DRS. A form specifying data reconfiguration is
Anderson, et al. [Page 3]
RFC 138 Data Reconfiguration Service April 1971
defined over this connection and is applied to data passing
over the two connections described below.
2) The user connection (UC) is between a user process and the
DRS.
3) The server connection (SC) is between the DRS and the
serving process.
Since the goal is to adapt the Network to user and server processes,
a minimum of requirements are imposed on the UC and SC.
+-------------+ CC +-----------+ SC +-----------+
| ORIGINATING +--------+ DRS +--------+ SERVER |
| USER | ^ | | ^ | PROCESS |
+-------------+ | +------+----+ | +-----------+
| / |
Telnet / <------ Simplex or Duplex
Protocol UC/ Connections
Connection /
/
+-----+-----+
| USER |
| PROCESS |
+-----------+
Figure 1. DRS Network Connections
CONNECTION PROTOCOLS AND MESSAGE FORMATS
Over a control connection the dialog is directly between an
originating user and the DRS. Here the user is defining forms or
assigning forms to connections for reformatting.
The user connects to the DRS via the initial connection protocol
(ICP) specified in NWG/RFC #80, version 1. Rather than going through
a logger, the user calls on a particular socket on which the DRS
always listens. DRS switches the user to another socket pair.
Messages sent over a control connection are of the types and formats
to be specified for TELNET. Thus, a user at a terminal should be
able to connect to a DRS via his local TELNET, for example, as shown
in Fig. 2.
Anderson, et al. [Page 4]
RFC 138 Data Reconfiguration Service April 1971
+--------------+
+--------+ CC | |
+-------+ TELNET +-------+ DRS |
| +--------+ | |
| +--------------+
+----------+---------+
| USER |
|(TERMINAL OR PROGRAM|
+--------------------+
Figure 2. A TELNET Connection to DRS
When a user connects to DRS he supplies a six-character user ID (UID)
as a qualifier to guarantee the uniqueness of his form names. He
will have (at least) the following commands:
1. DEFFORM (name)
2. ENDFORM (name)
These two commands define a form, the text of which is
chronologically entered between them. The (name) is six
characters. The form is stored in the DRS local file
system.
3. PURGE (name)
The named form, as qualified by the current UID, is purged
from the DRS file system.
4. LISTNAMES (UID)
The unqualified names of all forms assigned to UID are
returned.
5. LISTFORM (name)
The source text of a named form is returned.
6. DUPLEXCONNECT (user site, user send, user receive,
user method, server site, server
send, server receive, server method,
user-to-server form, server-to-user form)
7. SIMPLEXCONNECT (send site, send socket, send
method, receive site, receive
socket, receive method, form)
Anderson, et al. [Page 5]
RFC 138 Data Reconfiguration Service April 1971
Either one, both, or neither of the two parties specified in 6 or 7
may be at the same host as the party issuing the request. Sites and
sockets specify user and server for the connection. Method indicates
the way in which the connection is established. Three options are
provided:
1) Site/socket already connected to DRS as a dummy
control connection. (A dummy control connection
should not also be the real control connection.)
2) Connect via standard ICP. (Only for command no. 6.)
3) Connect directly via STR, RTS.
EXAMPLE CONNECTION CONFIGURATIONS
There are basically two modes of DRS operation: 1) the user wishes to
establish a DRS UC/SC connection(s) between two programs and 2) the
user wants to establish the same connection(s) where he (his
terminal) is at the end of the UC or the SC. The latter case is
appropriate when the user wishes to interact from his terminal with
the serving process (e.g., a logger).
In the first case (Fig. 1, where the originating user is either a
terminal or a program) the user issues the appropriate CONNECT
command. The UC/SC can be simplex or duplex.
The second case has two possible configurations, shown in Figs. 3 and
4.
+--------+ CC +--------+ +------+
| +------+ | SC | |
+------+ /| TELNET | UC | DRS +------+ SP |
| |/ | +------+ | | |
| USER | /+--------+ +--------+ +------+
| |/
+------+
Figure 3. Use of Dummy Control Connection
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -