Belated Network Meeting Report
Decisions on record formats from a May 1970 Network Working Group meeting.
Cerf, V.G., "Belated Network Meeting Report", RFC 63, DOI 10.17487/RFC0063, July 1970, <https://www.rfc-editor.org/info/rfc63>.
@misc{rfc63,
series = {Request for Comments},
number = 63,
howpublished = {RFC 63},
publisher = {RFC Editor},
doi = {10.17487/RFC0063},
url = {https://www.rfc-editor.org/info/rfc63},
author = {V.G. Cerf},
title = {{Belated Network Meeting Report}},
pagetotal = 2,
year = 1970,
month = jul,
} RFC text
Network Working Group V. Cerf
Request for Comments #63 31 July 70
Belated Network Meeting Report
On 8 May 1970, a Network Working Group meeting was hosted at Lincoln Labs.
The topics under discussion were:
1) Lincoln Lab's Local Interaction Language (LIL)
2) Records, Messages, and Format in HOST-HOST information exchange.
3) Miscellaneous gripes
The first topic is thoroughly summarized in Lincoln Lab's Semi annual
Technical Summary titled "Graphics", dated May 31, 1970 (document id.
ESD-TR-70-151).
The second topic involved considerable discussion of NWG/RFC #42 in which
it was proposed that all messages be preceded by an 8-bit type byte which
would declare the format of the message which followed.
The following decisions were reached:
a) Records may begin anywhere within a message.
b) The first 8 bits of a record are reserved for type information.
c) The first transmission on a connection starts a record.
Type 0 is agreed to mean that the transmission that follows consists of an
arbitrarily long record, and that no further type bytes will be present.
The notions of messages and records are independent of the flow-control
protocol. Thus the receipt of a message does not carry any semantic
importance. The receipt of a record, however, may initiate some interpre-
tation process.
After some discussion, the proposals in NWG/RFC #42 were permuted as follows:
type 0 = bit string of arbitrary length follows
type 1 = 8-bit ASCII follows
type 2 = EBCDIC follows
type 3 = MOD 33 TTY 7-bit ASCII
Network Working Group V. Cerf
Request for Comments #63 31 July 70
type 4 = YOUR Local
followed by another type byte
type 5 = MY Local
followed by another type byte
The praise or blame for the preceding decisions rests on the attendees at
the meeting, to wit:
E. Ancona (LL)
T. J. Barkalow (LL)
D. B. Black (Harvard)
Jack Bouknight (UI)
Howard Brodie (MAC)
Vint Cerf (UCLA)
Steve Crocker (UCLA)
Jim Curry (UTAH)
A. Evans (LL, MAC)
Robert Flegal (UTAH)
Jim Frogie (LL)
J. D. Fry (MITRE)
John Heafner (RAND)
Bob Hoffman (RAND)
Richard Kalin (LL)
William Kantrowitz (LL)
Peggy Karp (MITRE)
Abe Landsberg (SDC)
Robert Long (SDC)
James Madden (UI)
John Melvin (SRI)
Alan Nemeth (LL)
John Newkirk (Harvard)
Jon Postel (UCLA)
Tom O'Sullivan (Raytheon)
Ari Shoshani (SDC)
Joel Winett (LL)
Instead of sending NWG/RFC's to Chuck Rose at Case University, Jim Torson
will be receiving them.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Tammy and Ofer Porat 1/97 ]
ISO Plain Language
On this page
§1The Lincoln Labs Meeting
Vint Cerf's report describes a Network Working Group meeting hosted at Lincoln Labs on May 8, 1970. Topics included Lincoln Lab's Local Interaction Language, records and message formats for Host-Host exchange, and miscellaneous issues.
The meeting discussed RFC 42's proposal to precede messages with an 8-bit type byte.
The report summarizes a meeting about interactive systems and host-to-host message formats. Much of its detail concerns the type information at the start of a record.
§1Record Boundaries and Type Bytes
The attendees agreed that records may begin anywhere within a message, and that the first 8 bits of a record are reserved for type information. The first transmission on a connection starts a record.
Type 0 indicates an arbitrarily long record with no further type bytes. Types 1, 2, and 3 identify 8-bit ASCII, EBCDIC, and MOD 33 TTY 7-bit ASCII. Types 4 and 5 identify local forms followed by another type byte.
A record can begin within a message and starts with an eight-bit type. The type identifies the data representation that follows.
§1Messages, Records, and Attribution
The report distinguishes messages from records: message receipt has no semantic importance by itself, while a received record may start an interpretation process.
It lists the meeting attendees and notes that Jim Torson would receive NWG/RFCs instead of Chuck Rose at Case University.
A message boundary does not itself tell a program what to do. A record's type and contents may be meaningful to the receiving program.