RFC 51 UNKNOWN LANGUAGES · DATA FORMATS · NETWORK PROGRAMMING
Proposal for a Network Interchange Language
An early proposal for a high-level network programming language for computer networks
RFC EDITOR
Elie, M., "Proposal for a Network Interchange Language", RFC 51, DOI 10.17487/RFC0051, May 1970, <https://www.rfc-editor.org/info/rfc51>.
BIBTEX
@misc{rfc51,
series = {Request for Comments},
number = 51,
howpublished = {RFC 51},
publisher = {RFC Editor},
doi = {10.17487/RFC0051},
url = {https://www.rfc-editor.org/info/rfc51},
author = {M. Elie},
title = {{Proposal for a Network Interchange Language}},
year = 1970,
month = may,
} RFC text
Contents
This text was converted from the RFC Editor's PDF edition and may contain conversion errors; the layout is approximate. The PDF is the reference copy.
Network lflo.rking Grou.'"P M. Elie
~. '!'Jes t for Ccnment.s #51 4 Hay .70
L C A-
Proposal for a Net"iOrk InterChange Language
IntreXiuction
. In this paper 04"1 attempt is made to specify a high level programning Lanquaqe
for co:nputer networks , and rrore specifically the l\.RPA network, The main con
cept introduced. is t.he one of an abstrract; Netv;ork iV.L3chine, which is conai.st.ent;
with the idea of a HOST ask.inq a service fran the o::roputer netvork considered
as an overall canputinJ facility. The dial~e is always between a HCST ar.r1
the Nebvork Ma&.ine ~;Jhich language is always the same, though itS configuration
may va:ry accordir.g to the real remote nOST. .
. Fran a prcqranrrdnq langu'3.ge po.int; .of vi.ew, this concept is similar to the mX:OL .
proposed in 1958 [STR05S] but never implemented, oo'J..'E!Ver,· the applicati.on to a
o.::mputer network implies a realtime interaction between programs. Also, ::'~e
possibility for the user to use ~'IL either in a standard rnode or in an exten:1ed
mode where he defines himself hi,s own entities shoul.d give to NIT. a maxinum of
flexibility.
1. Basic concepts introduced in NTh
1.1 Aim of NIL
The u..'O main objectives of NIL are:
a) to describe the enviror.ment in which a prcqzam is executed
(its conplemerrc ); this involves the description of:
data formats am data structures
excharqes with input and out~t devices and characcerd.stdcs
-- expected =;:.uu fhen -
- interface ~rlth operating system
b) . to express the front end part of an interactive system:
The data flcM rhrouqh an interactive systxsn g('nerally decreases
as the data. zeaches the kernel of the syst.sm: it is assumed
that in ma...'1y interactive systems a separable rrodu Le exists or
can be def Lned vzhi.ch involves a great errount, of data exchanqed
with the user, and much less exchanqed vath the rest of the
systrm, This modul,e is called Front-End. It is Impor-tant; th~t
the zesponse time of the syst.em is affected as little as poss.ibl.e
by additional trar:.smission delays. Also, it is desirable to
keep the data rates as 10;" as possdbl,e on the netvork.
It is assumed t.hat fhe trar.sfer of a Front Ern does r.ot imply to solve the
whole problem of p:o.:;sT<li.11 trC.!'1Sfer&l1i.1 ity •
,.
Netwo:~:k Working Group M. Elie
Request for Ccmrents #51 4 May 70
1.2 NIL subcategorization
As pointed out by S. Volansky [ ] it's convenient to divide J.an:ruages
in several sublanguages cozresponddrq to their main functdons , NIL is
thus. subdivided in:
a oontrol sublanguage
an operation sublanguage
a data declaration sublanguage
- an environment sublanguage !
.1
I
1.2.1 COntrol sublanguage
The control sublanguage states WHEN a ccmputatzion is done: It describes
the flOtl of control or orderinj of the canputations. ~lith sane infor
mation contained frcrn the other sections of the language, it also states
WHERE the canputations are to be executed.
As a canputer netvork introduces loose connections between several systems,
the control language of the Neb-x:lrk r-1achine should be able ,in an elaborate
version/of assigning canputations to available processors, taking into
account the time delays and resource allocation problems involved. It is
not our purpose to consider this level at the m:ment.
1.2.2 Operation' sublanguage
The operation sublanguage describes the operations to be perfonned on the
data without indication of the sequencing between operations, it answer's
to the question of Hal] an operation is performed. The operat.ions are sub
divided into u.x:> groups. . .
- a canputation group
- a data manipulation group
The later is the most irnp:>rtant part of NIL since its main purpose is the
transfonration of data structures and patterns.
1.2.3 Data declaration sublanguage
The data declaration sublanguage is necessary to declare the variables
and data structures on which operations are perfonned.
The possibility is given to build structures of atonic e Iementis called
beads. NIL provides a stan:1ard set of beads used in the "standard rncde" ;
in the "ext.ended IIDc1e" a user may define new beads and new structures of
them.
.'
Network Working Group
Request for Canrents #51 ,
M. Elie
4 May 70
I
1
i
1.2.4 Envirorroent sublanguage
' The environment sub).anguage expresses the context in whi.ch a pregram
expects to operate; ex.pecte:1 characteristics of the peripherals,
I
semantics of the excharqes with the outside \A.orld through a particular
operating system. ,~
!
I
Thus a canplete "projrem descriptor" will contain, four distinct sections:
'e nvironnent section
data declaration section
control section
operation section
The identification section is anitted because it corresponds to the leg
in and socket grabbing port of the initialization procedure. !
---- --- - -- 1
, I
I
1.3 ' '!he Network Hachine
One fundanenta'l concept in NIL is that of an abstrac·t Net\'1Ork r-1achine
which 'has the follo;.7ing characteristics:
- an infinite memory: there is no problem of memory allccation
or garbage collection in this machine. But as an item must be
accessible, it must still have an address.
- variable word length: a word may be considered as the snallest
intelligible and addressable item of data. The atanic element
called bead is in fact the machine word, The structure and
1eI"X]th of each type of beads are expressed in the data. defini
tion sublanguage. ~
As presented on figure 1.9.1, one HOST r=:-=-l(--3 Network
only carmunicates with a Net\olOrk Mach- ~ Machine
ine which may operate in bX) medea,
, figure 1.9.1
starrlard mode where the beads ..f-4:('H:i~a .
their structures I am the all&',ed -'transforrnations on them are
standard and need not to be redefined: standard beads and
structures are known of every HOST
- - _ ... -- .. .
, --- .,.
'. .. . ... .. . .
",, ' " . -: .
extended rrode where in addition to or instead of the standard
data definilions and 'manipulation, a HOST may specify new beads
structures and transformations. The extended rrode. al.Icws ::-1l.e.
user to define his aim ma chi.ne as the Net work Machi.ne , Tlu.S 15
then equivalent to the mcdes HY LCCcIL, YOUR LOCAL proposed
in RFC #42 by Ancona. If the definition of a narre has not been
altered the st.andard definition is assumed.
Network vlorking Group M. Elie
Request for Carments #51 4 May 70
The data definition sublanguage is as we l.L used for the purpose of documenb
ing the set of s'candard beads.
The instruction set of the Net\'.Drk Machine stands at a high level per
mitting global transfonnations of data structures.
The 'envirorment of the Neu-x:>rk Machine is detennined by the subset; of
the environuent of the server I s HOST \'mch is used by the program in
execution; the systen HOST-Netv..-ork Naclllne can take bo-:o main configura
tions shown in figure 1. 3.2. .
• a) The Neuvork Hach.ine ·stands for the user of a
pro:;ram provided by t;he HOST (server HOST) '
~f-(--/f~=~~
~ ~server)
b) The HOST machine is the user of a proqram
provided by the Neb-lOrk Machine.
The server machine assigns its hardware .environ
ment to the user machine. This choice is made
so tf'l.at prcgrams can be ranotely used without
bei.ng- mcx1ified; it is up to the user of a remote
Network program to adapt himself and his own environnent.
Machine
(user) Thus, when the Network Machine is server, it
defines the Data Definition and Environrrent
figure 1. 3.2 sections.
.' ~
Network ~'Jorking Group M. E1ie
Request for Caments #51 4 May 70
1.4 Irnplenentation "
The data and environment definition sublanguages should be able to
describe as wel.L envirorment and
data in HOSTs as data in Net HOST description Neu\:ork Hac1'ine
,,"ork Machine. At the limit • (description
it should enable .two programs
written in different languages
non
r standard mcx1e)
Netv.ork Hachin~
to a:mnunicate r .
as long as the data / starrlard mode I
representation they use are
expressible in the data de I i
scription sublanguage. I
/
GENERATOR I
I
In each HOST will be
implenented a "generator" / I
which will accept rules I
describing the HOST data
structures arrl environ
/ I
I
ment and will generate . ~ Data in \ TRANSLATOR rata is J,
an adequate translator I-------~
HOST for
to translate than in Neh?Ork Mach±ile
mat
Netv.;ork Nachine format, format
as sbown in the figure
1.4.1. figure 1.4.1
once the network machine
stanc1a.rds wi.Ll, be settled
. it seans valuable to think
about anulatin:] the tran
slator using a micropro
gramed unit which would
be either added to the HOOT
Host or rather to the nIP"
thus avoiding the load of
a translation whi.ch may
involve lengthy operations Figure 1. 4. 2
on the bit level - (Figure
1.4.2. )
· Network Working Group M. Elie
Request for Ccmrents #51 4 May 70
2. Data definition sub1anguage
2.1 Fields
All ccmnunications with the Network Hachine are done using
strings of bits: these strings of bits, also referred to as
messages are parsed by the receiving HOST to reconstruct inside
its memory the data structures in its a.m rremory and cede.
Bits are grouped into significant fields: a field is a group
of bits having definite contents • . It may contain:
a) an elarent of data (data field)
b) sate bit pattern specifying' environrrent parameters
c) .a pointer
d) the identification of sane other fields.
'!he method to describe the fonnats of beads is derived from
the method of description of a binary message suggested in
RFC 4/:31:
a) each field is declared with its narre and length in
number of bits.
b) ccmnon1y used fixed values of a field that correspond
.to a special meaning, may be given names.
c) legal ways of concatenating fields are initiated by
rules; men only certain fixed values of a field are
allo.'led, they may be either specified by their
value or by the corresponding narre.
2.2 Data beads.
Data fields (type (a» are concatenaded to form data beads:
a bead is an indivisible atomic unit of data .us ed as
building element of any data structure to be transrnitted
between HOSTs and Network Mach.ine , A bead is the smallest
unit of data that can be referenced.
The legal ways of forming a bead by concatenation of several
fields are indicated in a construction rule. Beads have a
fixed length and an unambiguous structure. In real machine
beads are usually defined as an integer number of contiguous
registers. This constraint does not apply here, though it
may turn out to be more efficient to favor HOSTs with, for
L instance, 32 b.i.cwords , and 4 bytes per word, which .a r e the
most carmon ....r ord structure on the ARPA network. !.""
Data beads may be consd.dered as the operands of the Lanquaqe
in which fields of type (b) and (c) would be operators.
-,
Nat\vork V\orking Group M. Elie
Request for Carrrents #51 4 May 70
2.3 Control fields
'!be way data beads are linked ore to the other and the environ
ment in which they operate are specified by additional control
fields whi.ch cannot be referenced and are operators on or
identifiers of the follo.ving string of beads, or linkage
between individual beads.
The scope of a control field may as well be all the beads or
substructures of a structure, if it is specified at the level
of the .he ad of the structure. To be more precise, two kinds
of structures of beads must be defined: hcmogeneous and
.heterogeneous structures •
.A structure is defined as hanogeneous if both a unique type
of bead and a fixed pararreter environrrent for the whole
structure is specified at the head of the structure.
A structure is defined as heterogeneous if at least one of
the follcwing conditions i's true ..
- different types of beads are used for building the
structure .
- the environrnent in which lie tile beads of the structure
is changing wi thin the structure.
Five main control fields need to be defined.
a) MODIFY
b) . FLAG
c) POINI'ER
d) IDENI'IFlCATION
e) PARAMETER
2.3.1 MODIFY field
'!he HODIFY field is a one bit field preceding every bead of
a heterogeneous structure: it is a flag set when follo.~·ed
by one or several control fields of type b, d, or e, which aim
at modifying either the environment of data beads or their
type. '!bis field has the value:
1 if the attached data bead type and its envi.romrant; do
not change
o . if t11e attached elernent is a control field or a '
sequence of control fields of type b, d, or e specify
ing a change in type/or environment of follo.ving data
beads.
· , Network Working Group M. Elie
Request for Carrrents #:51 4 May 70
2.3.2 FIAG field
\'ben set, the MODIFY field is imnediately follaved by an 8
bit FLAG field indicating which of the IDENTIFICATION and
several possible PARAHEiI'ER fields are present; when set to
one each individual bit means the follcwing:
bit number
o IDENTIFICATION field present
.1 first pararr.eter field present
2 second parameter field present
- - -+-- - _..
,6 siXth para:rreter field present
. 7 next - fielq#- is another FLAG field ,
' for sane more pararreters (in case '
\ rrore than 6 parameters may be
I attarned to a bead environrrent) •
\ -- - -- --- - - - - ..
2.3.3 POINTER field
The number and nature of pointers to be attached to each bead
depends on the structure definition. A given list structure
may need one forward pointer. A ring structure may use an'
additional pointer to the first element. 'Ihe necessary
lin1(age between beads are defined in the structure definition
thereafter the necessary pointer fields autanatically added to
each data bead. A bead is referenced within a structure by
an address relative to the head of the 5 tructure. 'Ihus a
16 bit pointer field should be fully sufficient to contain
this address.
2.3.4 IDENTIFICATION field
The IDENTIFICATION field is an 8 bit field which identifies a
bead type arrong the list of defined bead 'types . Standard bead
types are nuubered from zero up and non-standard bead types are
numbered from 255 dam. The non-standard types mrrnbering is
special to each server program or to a set of server programs.
The IDENTIFIC"\TIO~J fields ,f ol I a .., a HODIFY field of value 1 when
ever the bead type has not been defined alloVer the structure
in the structure root. Identification fields are also used at
the level of the head of the structure to specify the type of
identical elements (beads or structures) used wi, thin this structure.
2.3.5 P~~R field
The' PARN1E.'TER field gives the list of the environment pararreters
in whi.ch the f cd. Lcwi.nq string of data beads lies. A PARi\HCTER
field is specific of a bead type; it directly follolls the HODIY:{
field when there is no arrbigui ty or the type of the next data beads.
Network Working Group M. Elie
.' ReqUest for Connents #51 4 May 70
Example: "the par~er field of the standard bead BEN-NVr
will contain the follcMing fields.
- a 2 bit field indicating the type of moverrent generated
00 do not display nove the beam
01 ". display final point point.
10 display vector vector
11 unused
- a 4 bit field indicating beam intensity, by a nun:ber
fran 0 to 15, 0 meaning a null intensity, and 15 the
maximum possible intensity.
- a 1 bit field for blinking
o off
1 an
- a 1 bit field for light pen sensitivity
o off
1 on
2.4 Metalanguage definition
A COBOL - report like rreta language is used in the examples
because of its readibility, as well in the beads as in the
structure definitions.
Symbol Meaning
+ concatanation
{ } choice
[ ] optional choice
repetition
- - --- - - - -- _. -- - -- ~ - - - - - - - _ ... ._ -- -_._ - _._ -- - ---- -_ ._. _- - -- - -- -
- . _ -~ - - - - - ----_._- -
1 laver bound on the
number of identical
items; if anitted 1
is assumed to be O.
u upper bound on the
nurrber of identical
iterns; if anitted u
is assumed to be 00 •
.a number alone rreans: exact;
nU1lber of repetilion.
" .. .' " Netw"Ork \'k>rking Group " M. Elie
Request for eomtents *51 4 May 70
.. label for further use within the same rule
= assignment
= ::>
"
conditional alternative
,
( ) grouping
indicates a special value given to the folloong field narre
o plus
G minus
2.5 Prcposed standard beads
2.5.1 Alphanumeric beads
Character: CHAR
A character is canposed of one eight bit field (which has the
same name). Many special patterns, corresponding to currently "
used special characters are defined; they are indicated in
table 2.5.1, as we l l, as sorre subsets of CHAR. The basic char
acter code is declared as s tandard ASCII
standard EBCDIC
or by the name CODE
follo....e d by the 128 characters in this code corresponding to
the 128 ASCII charactars , If no code declaration is specified,
the ASCII code is assumed by default.
Nu:nber representation
Normally the kernel of a proqrarn stays in the ' server's HOST
and the user's HOsr should have no arithrnetic operations to
perform on the data. In this case, the principles involved
in the arithmetic unit conception of a HOST do not need to
be described. But the format of fixed and floating point
nunbers has to be described.
in the "case when user and server Hosr' s have the same
number representation,for instance the stiandard
representation) the transmission of data in their
nunber representation reduces the data flo..; between
them.
- if the server HOST has a different number representatioi1
than the standard representation, depending on the data
transmitted, there are two alternatives:
»,
".
Network Working Group M. Elie
Request for Ccmnents #51 4 May 70
+ the nunerical data is exchan:jed as decimal nUI1'lters in the
standard code
+ the fixed and floating po.int; fonnat are defined to the
_Neuvork Machine and the user HOST performs
either a ' direct transco:1.ing fra-n the server binary
representation to decimal representation and vice.
versa.
or a transcoc1ing f ran the server binarY representation
to its own binary representation an::l vice versa.
As most of the numbers exchanged are to be printed in decilnal or
are given as decimal input, it is felt that when there is incanpati
bility between binary represe..T1te"ltions of corresrx::mc1irrg HOSTs,
exchanges in decimal representation would te the easiest.
Thus are defined:
a) .Number in decimal r~presentati.on whi.ch is not a bead but
a string of characters (see 2.3.1)
b) Fixed poirrt numbers single preci.sion FXP1.'illMl
double precision FXPNUH2
Field defi.nition BYTE 8 SIGN 1
SBYTE 7
FXP NThU~SIGN + SBY'I'E + {BYTE}3
.: 4
FXP NUM2 <-FXP!-'TQM i + {BYTE}
c) Floating point numbers single precision FLPNUMI
double precision FLPl'-JG'M2
FLP NUHl ~ SIGN + SBYTE + {BYTE}3
FLP. NUM2 ~ FLPNUr'-U + {BYTE} 4
This only ~presses the syntax of t..;e floating po.int; number.
The sanantics should say: in FLPNUI\'l1
SIGN is the sign of the number of fonnat {BY'I'E}3 vlhich is
the mantissa
SBi.'TE is the exponent, ard its value is based by a value
of 401 6 to insure positive exponents. In fact, FXPNu'H1
and FLP~·;(JMl di f f er by their s emant.i.cs ,
Network vbrkir.g Group M. E1ie
Request for Carments #51 '4 Nay 70
These prop=rties will be expressed by specd.al, field
definition:
EXP .(_ SBYTE (±) I 400 I SBYTE
rW1r <_,. SIGN G1 {BY"TE} 3
and a floating point number is defined as:
FLP "= !v1ANT .pp
:
Nebvork Harking Group r-1. E1ie
Request for Crnroents #51 4 r-1ay 70
1. Special Characters
Transnission Control Characters
SOH
STX
ETX
Ear
ENQ
ACK
DLE
NAK
SYN
EI'B
ESC
Printer Control Characters
horizontal tabulation HT 1- 'OXl' CHAR
vertical tabulation VT 1- 'OBX' CHAR
new line NL 1- 'OAX' OlAR
end of message ID-1 1- '08X' CHAR
- _.
Te1e otype
Control Characters
Carriage return CR 1- "ODX' oOIAR
shift out SO 1- 'OEX' OIAR
shift in 81 1 'OFX' OlJ-R
BS 1
Device Control Characters
OC1
OC2
OC3
OC4
Table 2.3.1
.:
Neu..urk \,]orki!'B Group M. Elie
Request for Carrnents if5l 4 May 70
2. Subsets of Characters
Numeric characters 1
2
NUM + aJAR
9
Printable characters
PRCHAR +
Intennediate characters 'J~acters "I'
ITCHAR + \n~l= ) OIAR
Final Ch3.rac·ters
FIN CHAR + CHAR e ITCHAR
<,
Transnission Control
Characters *
t~}
CHAR
TRACHA..~ +
Derra Control Characters DEL Teletype control character
OCQIAR + ' (OCl I' CHAR TYCOIAR {CR ~
SO "
t~~ ) S1
BSJ
r,
Alphabetic characters
M:l?H +
Printer Control
Characters
~HAR +
Table 2.3.1: Special ASCII characters and groups of ASCII
characters.
*see USACII standards
- <, Netwurk ~vorking Group r.1. Elie
Request for Ccrrments #51 4 Hay 70
2.5.2 ' Graphic Beads
As proposed in RFC #5 by J. Rulifson, the screen of any graphical
display is taken to be a square; the coordinates of points are
normalized fran -1/2 to +1/2 on roth axes. The pos.ilion of the
first podrit; of a structure is determined by the deflection fran
the origin whi.ch is the rest po.int; of the beam; fol1m"d.ng points
are detennined by their deflections (AX,AY) fran the last beam
pos.i.tdon • .
Thus, only u.o data fields need to be defined:
DEFLECl'ION which is a 12 bit field: the deflection is
defined by a mmber between - 1 and +1 with
the precision usual to the server.
ANGLE which is a 15 bit field defining an angle fran 0
to 211 in radians between the horizontal axis and
an axis passing through the origin. The first bit
of it indicates if the angle must be taken clock
wise or counterclock.\vise.
The data beads are:
MOVE
Deperrling on the parameters which are set when this bead appears,
MOVE may specify:
- an invisible movement of the beam; in this case the beam
intensity is null
a new point: in this case the team intensity is on only
when the team has reached the new point.
- a vector: in this case thebearn intensity is set to a certain
non zero value
MOVE + {DEFIECl'ION}2
Arc of circle: ARC
An arc of circle is defined vJ its center, fo'l.Lowed by its start
ing point and fhe angle of its ending axis.
ARC + {DEFI.ECrrCN} 4+liJ."\"l(;I.E
.
. ". ·M. Elie
NeUt.Drk ~Alorking- Group
Request for Colments #51 4 May 70
2.6 Proposed parameter fields.
2.6.1 Character str.i.nqs.
In character strings sane of the control characters are really
parameter fields: they act as an operator on the folloftTing
strin:; of characters. Le. :
10\'1er shift
upper shift
new line
escape
But as the code and use of these characters are detiemtined in
the standard codes, they are not included in parameter definition.
I ,t may be taken advantage that these characters are in the Ut70
left columns of ti'e ASCII or EBCDIC standard code: they cor.respond
to codes with the first three bits Jll..lll in EBCDIC ard the ' first
two bits null in ASCII.
2.6. 2 Graphics parameters
The follOt.-,.i.nq parameter fields are defined:
scale SCALE 4
beam intesity I~"T 4
light pen sensivity SENS + SV·iTrCH
blinkim BLINK + S"I"1I'ICH
beam B.E1J'1 + SWITCH
~~rDCH is. a 1 bit field Which may take the values:
00<-'1' S\"1I'ICH
OFF <.- '0' S"I'1I'I'CH
A switch parameter stays ON, as long- as it is not reset to
OFF.
The beam intensity is expressed. by a number' fran 0 to 1. 0 is
black and 1 as light as the display can go. .Numbers in between
specify the relative log of the intensity difference. BEAM
permits to swi.tch the BEAM on or off without chancJing the
Current INT parameter.
2.7 StructLrres
2.7.1 Structure definition.
The structure def ini ·t i on consits mainl y i n t.he specif i cat i on of
thetor.olcgical relation..s between data beads:
sequential relations; DO r:ointer field necessary
link.s through a mmber of p:>inters.
'" .
Netv..urk v.larking' Group M. Elie
Request for 'Cannents #51 4 May 70
2.7.2 Standard structure type.
'l\-x) basic standard structure types are chosen
VECIOR to represent 's eque nc e of data beads (strings, arrays,
tables ••• ) ' '
PLEX to represent any kind of directed graph, tree, ring .•. )
VECTOR (CiN, •••N +- VECroRIIDR + VEX:TOP.BODY
C)
VECrORBODY+(=C+l:{defi.r!ed bead}Ni + [VEC'IOPBODY]
VECTOPJIDR +'VECTOR' IDEN"TIFICATION + C + N + N2 + ••• -tNc
l
C is the number of parts (co.limns) in the vector, each part hav
:in:J ~:TC elsuents.
It is also probably interesting to define a canpressed vector
CCMPVECTOR in whi.ch sequence of the identical elErnents~are trans
rni tted as 1 elanent + .a special bead + the number of identical
eleuents in sequence. '
PLEX (H)
The first bit of a podrrter field indicates if the p::>inter po.irrcs
to a tenninal el.ement; or not. If it is the case, forward
p?inter fields are not added to the data element.
M is the nunber of data elsuents in the ' structure.
2.8 Objects
2.8.1 object 'definition.
An object is defined by a semantic rule including, on the right
hand side r a name to identify the object
'La set of parameters of the object definition.
(operands: name of tie beads used as data e'lemenbs
on the left: : , --
hand side loperators: parameter fields
structure of the data beads .
Le. The definition of a new object called SQUARE is: SQUARE ';,-
(A,L~Ae) RYI'lh(ANGLE:Z,) (VECrOR (l, 4) (OCl\!'1'OFF' +
MOVE (A) + B.EJ..I-I 'ON' + f.'lOVE (O,L) + r. :OVE (1.,0) +
HOVE (0 ,~L) + NOVE (e.L, 0) )
v.]here Rar refers to a transformation defi.ned in the data rnani.oul,«
ation Lanjuaqe , aril. VECTOR is defi.ned as a atardard structure:
·"
Neu.~"'Ork \'Iorking
Group M. Elie
Request for Ccmnents #51 4 May 70
The identifier of the le\" structure is SQUAnE
.The structure type used is VECTOR wi.th dimension 1 and 4 el.enents .'
The elerrents of the VECTOR are standard beads HOVE
The parameters are A, L , ard A G
Parameter fields BEAH ,IOFF ' and EEAH ION' are used ,
2.8.2 Alphanumeric standard objects.
Ccrnpressed character string (CQ."1STRmG) , "t\.
a::JMSTRING ~ VECIOR (1) ( [PRCHAR] n + ~NlJi'll ) .
V!'+}.,"'tJM I EOF)
:C+CHAJJR
EOP
A canpressed string of characters is any mmber of times a
strin:3' of any number of printable characters fo'l.Lcwed by one of
the follcMing characters .
horizontal tabulation fol.Iowed by the mmber of correspond- .
in:; blan.1.::.s to be added
- vertical tabulation fo Llrwed by the nurnber of lines to
be ski.pped,
- escape fo'l Lowed by any character
- new line
- end of page
The canpr-essed string is ended by an EOF character.
Co1e table (CODE)
CODE.(-VECroR (1; 128) [~28
CODE is the name of the translation table assumErl for a given
program. When definErl by the user I he must give fran
column 1 to column 8 the 8 bit pattern equdvaLent; to the
correspor.ding ]lEerr cede.
.. ~
. .
Netv.:ork ~·;orkilXJ Group H. Elie
Request for Ccmnents #51 4 .I-1ay 70
"
Binary card image
B CARD (-VEX:TOR (1; 120) {CHAR}120
packed dec.irrB.l number ffiU·1 4 bits field
.::~~'
x
X
X
X
HNUH PN1JI·1 f- HNUH
X
X
1£.n.:31
. PDNUH f-- ~NL"r-t} + DSIGN
_ . Decimal mmber (unpacked or zoned
_ lL..n<31
DNU1 f-- {i-roi.1] + D SIGN+ PNUM
-I
AI ELI5
On this page
PROBLEMDifferent computers on the ARPA network used different data formats and languages, making it difficult for them to communicate and exchange information reliably.
MECHANISMNIL (Network Interchange Language) proposes a high-level language with separate sublanguages for control, operations, data declaration, and environment description, along with an abstract Network Machine concept and standard data elements called beads.
AN EARLY INFLUENTIAL PROPOSALThis 1970 proposal influenced thinking about network protocols and data interchange but was never formally adopted, as the networking community developed other standards like ARPANET protocols and later TCP/IP.
§1The Network Interchange Language Concept
RFC 51, from May 1970, proposes NIL (Network Interchange Language), a high-level programming language for the ARPA network. The RFC is organized around the concept of an abstract Network Machine that presents a unified interface regardless of the underlying computer systems involved.
The core idea is that a HOST (user computer) always communicates with a Network Machine using the same language, though the Network Machine's configuration may vary depending on the remote HOST it interacts with. This abstraction aims to allow programs written in different languages on different machines to communicate as long as they can express their data structures in NIL.
Imagine all computers on the network talked to a magical middleman who understood all languages. The middleman would translate for everyone.
§2Language Sublanguages and Structure
NIL is divided into four sublanguages for different purposes:
- Control sublanguage: Describes when and where computations are performed, the flow of control and ordering of operations
- Operation sublanguage: Describes operations to be performed on data, divided into computation and data manipulation groups
- Data declaration sublanguage: Declares variables and data structures, using standard or user-defined beads (atomic elements) as building blocks
- Environment sublanguage: Describes the context and expected characteristics of peripherals and operating system interfaces
A complete program descriptor contains environment, data declaration, control, and operation sections. The Network Machine operates in two modes: standard mode with predefined beads and structures, and extended mode where users define custom beads and transformations.
The language has parts for saying what to do, how to do it, what kind of data you have, and what equipment you expect. Think of beads as Lego blocks that you snap together.
§3Data Elements and Structures
The RFC proposes beads as the smallest indivisible units of data. Standard beads include alphanumeric types (characters, numbers), graphic types for display (MOVE, ARC), and various data structures.
Larger data structures are built from beads using VECTOR (for sequences, strings, and arrays) and PLEX (for directed graphs, trees, and rings). Control fields within structures specify linkage, modification, and parameterization. The data definition sublanguage uses a COBOL-like metalanguage for readability.
Beads are like atoms. You use control markers to say how they link together: in a line like a string, in a tree, in a ring.
§4Implementation and Legacy
The RFC proposes that each HOST implement a 'generator' that accepts rules describing its data structures and environment, then generates an appropriate translator to convert data between the HOST's native format and NIL (Network Machine) format.
The document notes similarity to ALGOL and considers hardware-level translation implementations. While never formally adopted as an internet standard, RFC 51 reflects early thinking about network interchange formats and the need for a common language in heterogeneous computer networks.
Each computer would have a tool that learns how that computer stores data, then translates to and from the network language. Though never built, it influenced how networks later solved this same problem.