RFC relevance of resource

As per Relevance of the word resource, we have this rfc below:

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource

THE GOAL, RESOURCE SHARING 1

The principal goal of all resource-sharing computer networks
including the now international ARPA Network (the ARPANET), is
usefully interconnect geographically distributed hardware, software
and human resources [1]. Achieving this goal requires the
and implementation of various levels of support software within
constituent computer, and the specification of network-
"protocols" (that is, conventions regarding the format and
relative timing of network messages) governing their interaction
This paper outlines an alternative to the approach that
system builders have been taking since work in this area began
1970, and suggests a strategy for modeling distributed
within any large computer network. 1

The first section of this paper describes the prevailing
protocol strategy, which involves specifying a family
application-dependent protocols with a network-wide inter-
communication facility as their common foundation. In the
section, the application-independent command/response
that characterizes this protocol family is identified and
isolation as a separate protocol proposed. Such isolation
reduce the work of the applications programmer by allowing
software that implements the protocol to be factored out of
applications program and supplied as a single
installation-maintained module. The final section of this
proposes an extensible model for this class of network
that in itself would even further encourage the use of
resources. 1

-1-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
The Current Software Approach to Resource

THE CURRENT SOFTWARE APPROACH TO RESOURCE SHARING 2

Function-Oriented Protocols 2

The current ARPANET software approach to facilitating
sharing has been detailed elsewhere in the literature [2, 3, 4].
Briefly, it involves defining a Host-Host Protocol by which
operating systems of the various "host" computers cooperate
support a network-wide inter-process communication (IPC) facility
and then various function-oriented protocols by which
deliver and receive specific services via IPC.
function-oriented protocol regulates the dialog between a
"server process" providing the service, and a "user process"
the service on behalf of a user (the terms "user" and "user process
will be used consistently throughout this paper to distinguish
human user from the computer process acting on his behalf). 2a

The current Host-Host Protocol has been in service since 1970.
Since its initial design and implementation, a variety
deficiencies have been recognized and several alternative
suggested [5, 6]. Although improvements at this level would
have a positive effect upon Network resource sharing, the
paper simply assumes the existence of some form of IPC and
attention upon higher level protocol design issues. 2a

Each of the function-oriented protocols mentioned in this
constitutes the official ARPANET protocol for its
application domain and is therefore implemented at nearly all of
75 host installations that now comprise the Network. It
primarily upon this widely implemented protocol family (and
philosophy it represents) that the present paper focuses.
to say, other important resource sharing tools have also
constructed within the ARPANET. The Resource Sharing
(RSEXEC), designed and implemented by Bolt, Beranek and Newman,
[7], provides an excellent example of such work. 2a

Experience with and Limitations of Hands-On Resource Sharing 2

The oldest and still by far the most heavily
function-oriented protocol is the Telecommunications
protocol (TELNET) [8], which effectively attaches a terminal on
computer to an interactive time-sharing system on another,
allows a user to interact with the remote system via the terminal
if he were one of its local users. 2b

-2-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
The Current Software Approach to Resource

As depicted in Figure 1, TELNET specifies the means by which
user process monitoring the user's terminal is interconnected,
an IPC communication channel, with a server process with access
the target time-sharing system. TELNET also legislates a
character set in which the user's commands and the system'
responses are to be represented in transmission between machines
The syntax and semantics of these interchanges, however, vary
one system to another and are unregulated by the protocol; the
and server processes simply shuttle characters between the
user and the target system. 2b

Although the hands-on use of remote resources that TELNET
possible is a natural and highly visible form of resource sharing
several limitations severely reduce its long-term utility: 2b

(1) It forces upon the user all of the trappings of
resource's own system

To exploit a remote resource, the user must leave
familiar working environment provided by his local system
enter an alien one with its own peculiar system
(login, logout, and subsystem entry and exit procedures)
command language discipline (command recognition
completion conventions, editing characters, and so on).
Hands-on resource sharing thus fails to provide the user
the kind of organized and consistent workshop he requires
work effectively [9].

(2) It provides no basis for bootstrapping new
resources from existing ones

Because the network access discipline imposed by
resource is a human-engineered command language, rather than
machine-oriented communication protocol, it is
impossible for one resource to programatically draw upon
services of others. Doing so would require that the
deal successfully with complicated echoing and
characteristics; unstructured, even unsolicited
responses; and so forth. Hands-on resource sharing thus
nothing to provide an environment in which existing
can be used as building blocks to construct new, more
ones

These inherent limitations of hands-on resource sharing
removed by a protocol that simplifies and standardizes the
between user and server processes. Given such a protocol,

-3-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
The Current Software Approach to Resource

various remote resources upon which a user might wish to draw
indeed be made to appear as a single, coherent workshop
interposing between him and them a command language interpreter
transforms his commands into the appropriate protocol
[10, 11]. The construction of composite resources also
feasible, since each resource is accessible by means of
machine-oriented protocol and can thus be readily employed by
processes within the network. 2b

Standardizing the Inter-Machine Dialog in Specific Application Areas 2

After the TELNET protocol had been designed and
implemented within the ARPANET, work began on a family
function-oriented protocols designed for use by programs,
than human users. Each such protocol standardizes the inter-
dialog in a particular application area. While TELNET dictates
the manner in which user and server processes are interconnected
the IPC facility, and the character set in which the two
communicate once connected, each member of this family specifies
addition the syntax and semantics of the commands and responses
comprise their dialog. 2c

Protocols within this family necessarily differ in substance
each specifying its own application-specific command set. The
Transfer Protocol (FTP) [12], for example, specifies commands
manipulating files, and the Remote Job Entry Protocol (RJE) [13]
specifies commands for manipulating batch jobs.
throughout the family are, however, similar in form, each
family member having simply inherited the physical features of
predecessors. Thus FTP and RJE enforce the same conventions
formulating commands and responses. 2c

This common command/response discipline requires that
and responses have the following respective formats: 2c

command-name parameter response-number text
Each command invoked by the user process is identified by NAME
is allowed a single PARAMETER. Each response generated by
server process contains a three-digit decimal response NUMBER (to
interpreted by the user process) and explanatory TEXT (
presentation, if necessary, to the user). Response numbers
assigned in such a way that, for example, positive and
acknowledgments can be easily distinguished by the user process. 2c

-4-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
The Current Software Approach to Resource

FTP contains, among others, the following commands (each
with one of its possible responses) for retrieving, appending to
replacing, and deleting files, respectively, within the
process' file system: 2c

Command

RETR filename 250 Beginning transfer. APPE filename 400 Not implemented. STOR filename 453 Directory overflow. DELE filename 450 File not found.
The first three commands serve only to initiate the transfer of
file from one machine to another. The transfer itself occurs on
separate IPC channel and is governed by what amounts to a
protocol. 2c

Since the general command format admits but a single parameter
multiparameter operations must be implemented as sequences
commands. Thus two commands are required to rename a file: 2c

Command

RNFR oldname 200 Next parameter. RNTO newname 253 File renamed.

-5-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A Command/Response Protocol, the Basis for an Alternative

A COMMAND/RESPONSE PROTOCOL, THE BASIS FOR AN ALTERNATIVE APPROACH 3

The Importance of Factoring Out the Command/Response Discipline 3

That FTP, RJE, and the other protocols within this family share
common command/response discipline is a fact not formally
within the protocol literature, and each new protocol
describes it in detail, as if for the first time. Nowhere are
conventions codified in isolation from the various contexts in
they find use, being viewed as a necessary but
unimportant facet of each function-oriented protocol. "This
command/response discipline has thus gone unrecognized as
important, application-independent protocol that it is." 3a

This oversight has had two important negative effects upon
growth of resource sharing within the ARPANET: 3a

(1) It has allowed the command/response discipline to
crude

As already noted, operations that require more than
single parameter are consistently implemented as two or
separate commands, each of which requires a response and
incurs the overhead of a full round-trip network delay
Furthermore, there are no standards for encoding
types other than character strings, nor is there provision
returning results in a command response

(2) It has placed upon the applications programmer the burden
implementing the network "run-time environment (RTE)"
enables him to access remote processes at the desired
functional level

Before he can address remote processes in terms like
following

execute function DELE with argument
on machine

the applications programmer must first construct (as
invariably does in every program he writes) a module
provides the desired program interface while implementing
agreed upon command/response discipline. This run-
environment contains the code required to properly
outgoing commands, to interface with the IPC facility, and
parse incoming responses. Because the system provides

-6-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A Command/Response Protocol, the Basis for an Alternative

the IPC facility as a foundation, the applications
is deterred from using remote resources by the amount
specialized knowledge and software that must first
acquired

If, on the other hand, the command/response discipline
formalized as a separate protocol, its use in
function-oriented protocols could rightly be anticipated
the systems programmer, and a single run-time
constructed for use throughout an installation (in the
case, one implementation per programming language per
might be required). This module could then be placed in
library and, as depicted in Figure 2, link loaded with (
otherwise made available to) each new applications program
thereby greatly simplifying its use of remote resources

Furthermore, since enhancements to it would pay
to every applications program employing its services,
run-time environment would gradually be augmented to
additional new services to the programmer

The thesis of the present paper is that one of the keys
facilitating network resource sharing lies in (1) isolating as
separate protocol the command/response discipline common to a
class of applications protocols; (2) making this new
application-independent protocol flexible and efficient; and (3)
constructing at each installation a RTE that employs it to give
applications programmer easy and high-level access to
resources. 3a

Specifications for the Command/Response Protocol 3

Having argued the value of a command/response protocol (
termed the Protocol) as the foundation for a large class
applications protocols, there remains the task of suggesting
form that the Protocol might take. There are eight requirements
First, it must reproduce the capabilities of the discipline
replaces: 3b

(1) Permit invocation of arbitrary, named commands (or functions
implemented by the remote process

(2) Permit command outcomes to be reported in a way that
both the program invoking the commmand and the user
whose control it may be executing

-7-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A Command/Response Protocol, the Basis for an Alternative

Second, the Protocol should remove the known deficiencies of
predecessor, that is: 3b

(3) Allow an arbitrary number of parameters to be supplied
arguments to a single command

(4) Provide representations for a variety of parameter types
including but not limited to character strings

(5) Permit commands to return parameters as results as well
accept them as arguments

And, finally, the Protocol should provide whatever
capabilities are required by the more complex distributed
whose creation the Protocol seeks to encourage. Although others
later be identified, the three capabilities below are recognized
to be important: 3b

(6) Permit the server process to invoke commands in the
process, that is, eliminate entirely the often
user/server distinction, and allow each process to
commands in the other

In the workshop environment alluded to earlier,
example, the user process is the command language
and the server process is any of the software tools
to the user. While most commands are issued by
interpreter and addressed to the tool, occasionally the
must invoke commands in the interpreter or in another tool.
graphical text editor, for example, must invoke
within the interpreter to update the user's display
after an editing operation

(7) Permit a process to accept two or more commands
concurrrent execution

The text editor may wish to permit the user to initiate
long formatting operation with one command and yet continue
issue additional, shorter commands before there is a
to the first

(8) Allow the process issuing a command to suppress the
the command would otherwise elicit

This feature would permit network traffic to be reduced
those cases in which the process invoking the command deems

-8-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A Command/Response Protocol, the Basis for an Alternative

response unnecessary. Commands that always succeed but
return results are obvious candidates for this kind
treatment

A Formulation of the Protocol That Meets These Specifications 3

The eight requirements listed above are met by a protocol
which the following two messages are defined: 3c

message-type=COMMAND [tid] command-name
message-type=RESPONSE tid outcome

Here and in subsequent protocol descriptions, elements enclosed
square brackets are optional. 3c

The first message invokes the command whose NAME is
using the ARGUMENTS provided. The second is issued in
response to the first and returns the OUTCOME and RESULTS of
completed command. Whenever OUTCOME indicates that a command
failed, the command's RESULTS are required to be an error number
diagnostic message, the former to help the invoking
determine what to do next, the latter for possible presentation
the user. The protocol thus provides a framework for
errors, while leaving to the applications program the tasks
assigning error numbers and composing the text of error messages. 3c

There are several elements of the Protocol that are absent
the existing command/response discipline: 3c

(1) RESULTS, in fulfillment of Requirement 5.

(2) A MESSAGE TYPE that distinguishes commands from responses
arising from Requirement 6.

In the existing discipline, this distinction is implicit
since user and server processes receive only responses
commands, respectively

(3) An optional transaction identifier TID by which a command
its response are associated, arising from Requirements 7
8.

The presence of a transaction identifier in a
implies the necessity of a response echoing the identifier
and no two concurrently outstanding commands may bear the
identifier

-9-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A Command/Response Protocol, the Basis for an Alternative

Requirements 3 and 4--the ability to transmit an arbitrary
of parameters of various types with each command or response--
most economically and effectively met by defining a small set
primitive "data types" (for example, booleans, integers,
strings) from which concrete parameters can be modeled, and
"transmission format" in which such parameters can be encoded
Appendix A suggests a set of data types suitable for a large
of applications; Appendix B defines some possible
formats. 3c

The protocol description given above is, of course,
symbolic. Appendix C explores one possible encoding of the
in detail. 3c

Summarizing the Arguments Advanced So Far 3

The author trusts that little of what has been presented thus
will be considered controversial by the reader. The
principal arguments have been made: 3d

(1) The more effective forms of resource sharing depend
remote resources being usefully accessible to other programs
not just to human users

(2) Application-dependent protocols providing such access
the current approach leave to the applications programmer
task of constructing the additional layer of software (
the IPC facility provided by the system) required to
remote resources accessible at the functional level,
discouraging their use

(3) A single, resource-independent protocol providing
and efficient access at the functional level to
remote resources can be devised

(4) This protocol would make possible the construction at
installation of an application-independent, network run-
environment making remote resources accessible at
functional level and thus encouraging their use by
applications programmer

A protocol as simple as that suggested here has great
for stimulating the sharing of resources within a computer network
First, it would reduce the cost of adapting existing resources
network use by eliminating the need for the design, documentation
and implementation of specialized delivery protocols. Second,

-10-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A Command/Response Protocol, the Basis for an Alternative

would encourage the use of remote resources by eliminating the
for application-specific interface software. And finally, it
encourage the construction of new resources built expressly
remote access, because of the ease with which they could be
and used within the network software marketplace. 3d

-11-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A High-Level Model of the Network

A HIGH-LEVEL MODEL OF THE NETWORK ENVIRONMENT 4

The Importance of the Model Imposed by the Protocol 4

The Protocol proposed above imposes upon the
programmer a particular model of the network environment. In
heterogeneous computer network, nearly every protocol intended
general implementation has this effect, since it idealizes a
of operations that have concrete but slightly different
in each system. Thus the ARPANET's TELNET Protocol alluded
earlier, for example, specifies a Network Virtual Terminal
attempts to provide a best fit to the many real terminals in
around the Network. 4a

As now formulated, the Protocol models a remote resource as
interactive program with a simple, rigidly specified
language. This model follows naturally from the fact that
function-oriented protocols from which the Protocol was
were necessitated by the complexity and diversity of user-
command languages. The Protocol may thus legitimately be viewed
a vehicle for providing, as an adjunct to the sophisticated
languages already available to users, a family of simple
languages that can readily be employed by programs. 4a

While the command/response model is a natural one, others
possible. A remote resource might also be modeled as a process
services and replies to requests it receives from other
processes. This request/reply model would emphasize the fact
the Protocol is a vehicle for inter-process communication and
no human user is directly involved. 4a

Substituting the request/reply model for the command/
model requires only cosmetic changes to the Protocol: 4a

message-type=REQUEST [tid] op-code
message-type=REPLY tid outcome

In the formulation above, the terms "REQUEST", "REPLY",
"op-code" have simply been substituted for "COMMAND", "RESPONSE",
and "command-name", respectively. 4a

The choice of model need affect neither the content of
Protocol nor the behavior of the processes whose dialog it governs
Use of the word "command" in the command/response model,
example, is not meant to imply that the remote process can
coerced into action. Whatever model is adopted, a process

-12-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A High-Level Model of the Network

complete freedom to reject an incoming remote request that it
incapable of or unwilling to fulfill. 4a

But even though it has no substantive effect upon the Protocol
the selection of a model--command/response, request/reply, and
on--is an important task because it determines the way in which
applications and systems programmers perceive the
environment. If the network environment is made to appear
to him, the applications programmer may be discouraged from
it. The choice of model also constrains the kind and range
protocol extensions that are likely to occur to the
programmer; one model may suggest a rich set of useful extensions
another lead nowhere (or worse still, in the wrong direction). 4a

In this final section of the paper, the author suggests a
model (hereafter termed the Model) that he believes will
encourage the use of remote resources by the applications
and suggest to the systems programmer a wide variety of
Protocol extensions. Unlike the substance of the Protocol, however
the Model has already proven quite controversial within the
community. 4a

Modeling Resources As Collections of Procedures 4

Ideally, the goal of both the Protocol and its accompanying
is to make remote resources as easy to use as local ones.
local resources usually take the form of resident and/or
subroutines, the possibility of modeling remote commands
"procedures" immediately suggests itself. The Model is
confirmed by the similarity that exists between local procedures
the remote commands to which the Protocol provides access.
carry out arbitrarily complex, named operations on behalf of
requesting program (the caller); are governed by arguments
by the caller; and return to it results that reflect the outcome
the operation. The procedure call model thus acknowledges that,
a network environment, programs must sometimes call subroutines
machines other than their own. 4b

Like the request/reply model already described, the
call model requires only cosmetic changes to the Protocol: 4b

message-type=CALL [tid] procedure-name
message-type=RETURN tid outcome

In this third formulation, the terms "CALL", "RETURN",
"procedure-name" have been substituted for "COMMAND, "RESPONSE",

-13-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A High-Level Model of the Network

"command-name", respectively. And in this form, the Protocol
aptly be designated a "procedure call protocol (PCP)". 4b

"The procedure call model would elevate the task of
applications protocols to that of defining procedures and
calling sequences. It would also provide the foundation for a
distributed programming system (DPS) that encourages and
the work of the applications programmer by gracefully extending
local programming environment, via the RTE, to embrace modules
other machines." This integration of local and network
environments can even be carried as far as modifying compilers
provide minor variants of their normal procedure-calling
for addressing remote procedures (for which calls to the
RTE primitives would be dropped out). 4b

Finally, the Model is one that can be naturally extended in
variety of ways (for example, coroutine linkages and signals)
further enhance the distributed programming environment. 4b

Clarifying the Procedure Call Model 4

Although in many ways it accurately portrays the class of
interactions with which this paper deals, the Model suggested
may in other respects tend to mislead the applications programmer
The Model must therefore be clarified: 4c

(1) Local procedure calls are cheap; remote procedure calls
not

Local procedure calls are often effected by means of
single machine instruction and are therefore
inexpensive. Remote procedure calls, on the other hand,
be effected by means of a primitive provided by the local
and require an exchange of messages via IPC

Because of this cost differential, the
programmer must exercise discretion in his use of
resources, even though the mechanics of their use will
been greatly simplified by the RTE. Like virtual memory,
procedure call model offers great convenience, and
power, in exchange for reasonable alertness to
possibilities of abuse

(2) Conventional programs usually have a single locus of control
distributed programs need not

-14-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
A High-Level Model of the Network

Conventional programs are usually implemented as a
process with exactly one locus of control. A procedure call
therefore, traditionally implies a transfer of control
caller to callee. Distributed systems, on the other hand,
implemented as two or more processes, each of which is
of independent execution. In this new environment, a
procedure call need not suspend the caller, which is
of continuing execution in parallel with the called procedure

The RTE can therefore be expected to provide,
convenience, two modes of remote procedure invocation:
blocking mode that suspends the caller until the
returns; and a non-blocking mode that releases the caller
soon as the CALL message has been sent or queued.
conventional operating systems already provide such a
choice for I/O operations. For non-blocking calls, the
must also, of course, either arrange to asynchronously
the program when the call is complete, or provide
additional primitive by which the applications program
periodically test for that condition

Finally, the applications programmer must recognize that by
means all useful forms of network communication are
modeled as procedure calls. The lower level IPC facility
remains directly accessible to him must therefore be employed
those applications for which the procedure call model
inappropriate and RTE-provided primitives simply will not do. 4c

-15-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
Some

SOME EXPECTATIONS 5

Both the Procedure Call Protocol and its associated Run-
Environment have great potential for facilitating the work of
network programmer; only a small percentage of that potential
been discussed in the present paper. Upon the foundation
by PCP can be erected higher level application-independent
layers that further enhance the distributed programming
by providing even more powerful capabilities (see Appendix D). 5

As the importance of the RTE becomes fully evident,
tasks will gradually be assigned to it, including perhaps those of: 5

(1) Converting parameters between the format employed
by the applications program, and that imposed by
Protocol. 5b

(2) Automatically selecting the most appropriate inter-
transmission format on the basis of the two machines'
sizes. 5b

(3) Automatically substituting for network IPC a more
form of communication when both processes reside on the
machine. 5b

The RTE will eventually offer the programmer a wide variety
application-independent, network-programming conveniences, and so
by means of the Protocol, become an increasingly
distributed-system-building tool. 5

-16-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource

ACKNOWLEDGMENTS 6

Many individuals within both SRI's Augmentation Research
(ARC) and the larger ARPANET community have contributed their
and ideas to the development of the Protocol and Model described
this paper. The contributions of the following individuals
expressly acknowledged: Dick Watson, Jon Postel, Charles Irby,
Victor, Dave Maynard, and Larry Garlick of ARC; and Bob Thomas
Rick Schantz of Bolt, Beranek and Newman, Inc. 6

ARC has been working toward a high-level framework
network-based distributed systems for a number of years now [14].
The particular Protocol and Model described here result
research begun by ARC in July of 1974. This research
developing the Model; designing and documenting the
required to support it [15]; and designing, documenting,
implementing a prototype run-time environment for a
machine [16, 17], specifically a PDP-10 running the Tenex
system developed by Bolt, Beranek and Newman, Inc [18].
design iterations were carried out during a 12-month period, and
resulting specification implemented for Tenex. The Tenex
provides a superset of the capabilities presented in the body
this paper and Appendices A through C as well as those alluded to
Appendix D. 6

The work reported here was supported by the Advanced
Projects Agency of the Department of Defense, and by the Rome
Development Center of the Air Force. 6

-17-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
Appendix A: Suggested Data

APPENDIX A: SUGGESTED DATA TYPES 7

The Protocol requires that every parameter or "data object"
represented by one of several primitive data types defined by
Model. The set of data types below is sufficient to
model a large class of data objects, but since the need
additional data types (for example, floating-point numbers)
surely arise, the set must remain open-ended. Throughout
descriptions below, N is confined to the range [0, 2**15-1]: 7

LIST: A list is an ordered sequence of N data objects
"elements". A LIST may contain other LISTs as elements, and
therefore be employed to construct arbitrarily complex
data objects. 7a

CHARSTR: A character string is an ordered sequence of N
characters, and conveniently models a variety of
entities, from short user names to whole paragraphs of text. 7a

BITSTR: A bit string is an ordered sequence of N bits and
therefore, provides a means for representing arbitrary
data (for example, the contents of a word of memory). 7a

INTEGER: An integer is a fixed-point number in the
[-2**31, 2**31-1], and conveniently models various kinds
numerical data, including time intervals, distances, and so on. 7a

INDEX: An index is an integer in the range [1, 2**15-1].
its name and value range suggest, an INDEX can be used to
a particular bit or character within a string, or element
a list. INDEXes have other uses as well, including the
of handles or identifiers for open files, created processes,
the like. Also, because of their restricted range, INDEXes
more compact in transmission than INTEGERs (see Appendix B). 7a

BOOLEAN: A boolean represents a single bit of information
and has either the value true or false. 7a

EMPTY: An empty is a valueless place holder within a LIST
parameter list. 7a

-18-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
Appendix B: Suggested Transmission

APPENDIX B: SUGGESTED TRANSMISSION FORMATS 8

Parameters must be encoded in a standard transmission
before they can be sent from one process to another via
Protocol. An effective strategy is to define several formats
select the most appropriate one at run-time, adding to the
a mechanism for format negotiation. Format negotiation would
another responsibility of the RTE and could thus be made
invisible to the applications program. 8

Suggested below are two transmission formats. The first is
36-bit binary format for use between 36-bit machines, the second
8-bit binary, "universal" format for use between
machines. Data objects are fully typed in each format to enable
RTE to automatically decode and internalize incoming
should it be desired to provide this service to the
program. 8

PCPB36, For Use Between 36-Bit Machines 8

Bits 0-13 Unused (zero) 8c
Bits 14-17 Data type 8c
EMPTY =1 INTEGER=4 LIST=7
BOOLEAN=2 BITSTR =5
INDEX =3 CHARSTR=6
Bits 18-20 Unused (zero) 8c
Bits 21-35 Value or length N 8c
EMPTY unused (zero
BOOLEAN 14 zero-bits + 1-bit value (TRUE=1/FALSE=0)
INDEX unsigned
INTEGER unused (zero
BITSTR unsigned bit count
CHARSTR unsigned character count
LIST unsigned element count
Bits 36- Value 8c
EMPTY unused (nonexistent
BOOLEAN unused (nonexistent
INDEX unused (nonexistent
INTEGER two's complement full-word
BITSTR bit string + zero padding to word
CHARSTR ASCII string + zero padding to word
LIST element data

-19-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
Appendix B: Suggested Transmission

PCPB8, For Use Between Dissimilar Machines 8

Byte 0 Data type 8d
EMPTY =1 INTEGER=4 LIST=7
BOOLEAN=2 BITSTR =5
INDEX =3 CHARSTR=6
Bytes 1- Value 8d
EMPTY unused (nonexistent
BOOLEAN 7 zero-bits + 1-bit value (TRUE=1/FALSE=0)
INDEX 2-byte unsigned
INTEGER 4-byte two's complement
BITSTR 2-byte unsigned bit count N + bit
+ zero padding to byte
CHARSTR 2-byte unsigned character count N + ASCII
LIST 2-byte element count N + element data

-20-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
Appendix C: A Detailed Encoding of the Procedure Call

APPENDIX C: A DETAILED ENCODING OF THE PROCEDURE CALL PROTOCOL 9

Although the data types and transmission formats detailed in
previous appendixes serve primarily as vehicles for representing
arguments and results of remote procedures, they can just as
and effectively be employed to represent the commands and
by which those parameters are transmitted. 9

Taking this approach, one might model each of the two
messages as a PCP data object, specifically a LIST whose
element is an INDEX message type. The following concise
of the Protocol then results: 9

LIST (CALL, tid, procedure, arguments
INDEX=1 INDEX/EMPTY CHARSTR LIST 9b
LIST (RETURN, tid, outcome, results
INDEX=2 INDEX BOOLEAN LIST 9b

The RESULTS of an unsuccessful procedure would be represented
follows: 9

LIST (error, diagnostic
INDEX CHARSTR 9c

-21-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
Appendix D: A Look at Some Possible Extensions to the

APPENDIX D: A LOOK AT SOME POSSIBLE EXTENSIONS TO THE MODEL 10

The result of the distributed-system-building strategy
in the body of this paper and the preceeding appendices is
in Figure D-1. At the core of each process is the inter-
communication facility provided by the operating system,
effects the transmission of arbitrary binary data between
processes. Surrounding this core are conventions regarding
the format in which a few, primitive types of data objects
encoded in binary for IPC, and then the formats of several
data objects (that is, messages) whose transmission either
or acknowledges the previous invocation of a remote procedure
Immediately above lies an open-ended protocol layer in which
arbitrary number of enhancements to the distributed
environment can be implemented. Encapsulating these
protocol layers is the installation-provided run-time environment
which delivers DPS services to the applications program according
machine- and possibly programming-language-dependent conventions. 10

The Protocol proposed in the present paper recognizes only
most fundamental aspects of remote procedure calling. It
the caller to identify the procedure to be called, supply
necessary arguments, determine the outcome of the procedure,
recover its results. In a second paper [19], the author
some extensions to this simple procedure call model, and attempts
identify other common forms of inter-process interaction
standardization would enhance the distributed
environment. Included among the topics discussed are: 10

(1) Coroutine linkages and other forms of communication
the caller and callee. 10b

(2) Propagation of notices and requests up the thread of
that results from nested procedure calls. 10b

(3) Standard mechanisms for remotely reading or
system-global data objects within another program. 10b

(4) Access controls for collections of related procedures. 10b

(5) A standard means for creating and initializing processes
that is, for establishing contact with and logging into
remote machine, identifying the program to be executed,
so forth. This facility would permit arbitrarily
process hierarchies to be created. 10b

-22-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
Appendix D: A Look at Some Possible Extensions to the

(6) A mechanism for introducing processes to one another,
is, for superimposing more general communication paths
the process hierarchy. 10b

These and other extensions can all find a place in the open-
protocol layer of Figure D-1. The particular extensions explored
[19] are offered not as dogma but rather as a means of
the possibilities and stimulating further research. 10

-23-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource

REFERENCES 11

1. Kahn, R. E., "Resource-Sharing Computer
Networks," Proceedings of the IEEE, Vol. 60, No. 11, pp
1397-1407, November 1972. 11

2. Crocker, S. D., Heafner, J. F., Metcalfe, R. M., Postel, J. B.,
"Function-oriented Protocols for the ARPA Computer Network,"
AFIPS Proceedings, Spring Joint Computer Conference, Vol. 40,
pp. 271-279, 1972. 11

3. Carr, C. S., Crocker, S. D., Cerf, V. G., "Host-
Communication Protocol in the ARPA Network," AFIPS Proceedings
Spring Joint Computer Conference, Vol. 36, pp. 589-597, 1970. 11

4. Mc Kenzie, A. A., Host/Host Protocol for the ARPA Network,
Beranek and Newman Inc., Cambridge, Massachusetts, January 1972
(SRI-ARC Catalog Item 8246). 11

5. Walden, D. C., "A System for Interprocess Communication in
Resource Sharing Computer Network," Communications of the ACM
Vol. 15, No. 4, pp. 221-230, April 1972. 11

6. Cerf, V. G., Kahn, R. E., "A Protocol for Packet
Intercommunication," IEEE Transactions on Communications, Vol
Com-22, No. 5, pp. 637-648, May 1974. 11

7. Thomas, R. H., "A Resource-Sharing Executive for the ARPANET,"
AFIPS Proceedings, National Computer Conference, Vol. 42, pp
155-163, 1973. 11

8. TELNET Protocol Specification, Stanford Research Institute
Menlo Park, California, August 1973 (SRI-ARC Catalog
18639). 11

9. Engelbart, D. C., Watson, R. W., Norton, J. C., "The
Knowledge Workshop," AFIPS Proceedings, National
Conference, Vol. 42, pp. 9-21, 1973. 11

10. Engelbart, D. C., English, W. K., "A Research Center
Augmenting Human Intellect," AFIPS Proceedings, Fall
Computer Conference, Vol. 33, pp. 395-410, 1968. 11

11. Irby, C. H., Dornbush, C. F., Victor, K. E., Wallace, D. C., "
Command Meta Language for NLS," Final Report,

-24-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource

RADC-TR-75-304, SRI Project 1868, Stanford Research Institute
Menlo Park, California, December, 1975. 11

12. Neigus, N. J., File Transfer Protocol, ARPA Network
Group Request for Comments 542, Bolt Beranek and Newman Inc.,
Cambridge, Massachusetts, July 1973 (SRI-ARC Catalog
17759). 11

13. Bressler, R. D., Guida, R., Mc Kenzie, A. A., Remote Job
Protocol, ARPA Network Working Group Request for Comments 360,
Dynamic Modeling Group, Massachusetts Institute of Technology
Cambridge, Massachusetts, (undated) (SRI-ARC Catalog
12112). 11

14. Watson, R. W., Some Thoughts on System Design to
Resource Sharing, ARPA Network Working Group Request
Comments 592, Augmentation Research Center, Stanford
Institute, Menlo Park, California, November 20, 1973 (SRI-
Catalog Item 20391). 11

15. White, J. E., DPS-10 Version 2.5 Implementer's Guide
Augmentation Research Center, Stanford Research Institute,
Park, California, August 15, 1975 (SRI-ARC Catalog Item 26282). 11

16. White, J. E., DPS-10 Version 2.5 Programmer's Guide
Augmentation Research Center, Stanford Research Institute,
Park, California, August 13, 1975 (SRI-ARC Catalog Item 26271). 11

17. White, J. E., DPS-10 Version 2.5 Source Code,
Research Center, Stanford Research Institute, Menlo Park
California, August 13, 1975 (SRI-ARC Catalog Item 26267). 11

18. Bobrow, D. G., Burchfiel, J. D., Murphy, D. L., Tomlinson, R
S., "TENEX, a Paged Time Sharing System for the PDP-10,"
Communications of the ACM, Vol. 15, No. 3, pp. 135-143,
1972. 11

19. White, J. E., "Elements of a Distributed Programming System,"
Submitted for publication in the Journal of Computer Languages
1976. 11

-25-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource
Figure

FIGURE LIST 12

Figure 1. Interfacing a remote terminal to a local time-
system via the TELNET Protocol. 12

Figure 2. Interfacing distant applications programs via
run-time environments. 12

Figure D-1. Software and protocol layers comprising a
within the distributed programming system. 12

-26-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263

-27-

NWG/RFC# 707 JEW 14-JAN-76 19:51 34263

A High-Level Framework for Network-Based Resource

23-DEC-75

James E.
Augmentation Research

Stanford Research
Menlo Park, California 94025

(415) 326-6200 x2960

This paper proposes a high-level, application-
protocol and software framework that would extend the
programming environment to embrace modules in other
within a resource sharing computer network, and
facilitate the construction of distributed systems and
the sharing of resources

The work reported here was supported by the Advanced
Projects Agency of the Department of Defense, and by the Rome
Development Center of the Air Force

This paper has been submitted for publication in

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX