Message Data Types
Labeling message types so different computers understand data.
Ancona, E., "Message Data Types", RFC 42, DOI 10.17487/RFC0042, March 1970, <https://www.rfc-editor.org/info/rfc42>.
@misc{rfc42,
series = {Request for Comments},
number = 42,
howpublished = {RFC 42},
publisher = {RFC Editor},
doi = {10.17487/RFC0042},
url = {https://www.rfc-editor.org/info/rfc42},
author = {E. Ancona},
title = {{Message Data Types}},
pagetotal = 3,
year = 1970,
month = mar,
} RFC text
Network Working Group E.I. Ancona
Request for Comments: 42 M.I.T. Lincoln Laboratory
31 March 1970
Message Data Types
Proposal:
We propose that the first eight bits of a normal message be reserved
for a message data type. Adoption of this convention does not in any
way signify agreement as to the actual data types to be used. It
merely establishes the convention that the first eight bits of every
normal message are not available for user data.
Discussion:
Socket Port
| | | ____________
| V V / \
V / \
|=| /==| |
-------(+)->|Y|-->< | |
|=| \==| |
| PROCESS |
| |
|=| /==| |
-------(-)->|X|<--< | |
|=| \==| |
\ /
\____________/
It is important that conventions regarding the contents of messages
be set up early so that there will not be a large proliferation of
such conventions between every pair of programs running on the
network.
As network usage grows, network languages may develop for specifying
both the syntax and semantics of messages. However, even before such
conventions are developed, a simple way of describing such a
specification is by means of a message type which both sender and
receiver know how to interpret.
It is important that currently running programs still run with this
convention; thus, we propose that two system programs be written
which initially put in and test and remove the type information from
the message. Let us call these two programs X and Y, for lack of
better names. In general, X and Y will perform transformations on
the data, e.g., change character sets or number formats. As network
usage grows, X and Y might become table driven with the table
specified by the user.
Standard Types and Local Types:
We propose to distinguish between two kinds of message data types:
standard and local.
Since our two transformation programs cannot be expected to perform a
transformation between every possible data representation and the
data representation of the machine they are running on, and also
since the addition of a data representation should not necessarily
involve a change to X or Y, we propose that only a fixed number of
message types have meaning throughout the network. These are
standard types.
There are two classes of local types: MYLOCAL and YOURLOCAL. A
message type MYLOCAL n implies: this is type n of the set of types of
the sending host. YOURLOCAL n implies: this is type n of the set of
types of the receiving host.
Conventions:
A possible implementation of standard and local types is to define
standard type 0 to be YOURLOCAL and standard type 1 to be MYLOCAL. In
these cases, the second byte would be the local type number.
Local type 0 would mean user-specified, i.e., the message contents
are unchanged and unchecked. Installations would define their own
local type numbers and these would normally be available from the
Network Information Center.
Thus initially, all messages sent to currently running programs will
be type 0, n and all messages received from currently running
programs will be type 1, n where n is the local type number of the
character set of the installation.
Examples of Possible Standard Types:
0. YOURLOCAL
1. MYLOCAL
2. U.S. Ascii
3. EBCDIC
4. Mod 33 TTY Ascii
5. Load table driven translator table #n. If, in the
future, the X and Y transformation boxes are table
driven, this gives the table. The table number n is
stored in the second byte of the message.
6. Use table driven translator table #n.
7. Network standard graphics message.
Examples of Local Types:
1. Local Character sets, e.g., Lincoln writer, DEC Ascii,
etc.
2. Graphics local messages, e.g., TX-2 Apex display
executive calls, GSAM.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Robbie Bennet 11/98 ]
AI ELI5
On this page
§1The Problem
When computers on the early ARPA network send messages to each other, they must agree on what each message contains. One computer might send a text file, another a binary data structure, another a graphics command. Without a clear label, the receiving computer cannot know how to interpret the bytes it gets.
E.I. Ancona of M.I.T. Lincoln Laboratory proposed a simple convention: reserve the first eight bits (one byte) of every message for a type field.
Different computers send different stuff. The first byte is a label saying what is inside, so the receiver knows what to do with it.
§2Standard and Local Types
The proposal defines two categories of message types. Standard types have the same meaning across the entire network; all hosts recognize them. Local types are specific to each host or even to each user.
A standard type 0 means the message uses the receiving host's local data format. A standard type 1 means it uses the sending host's format. Standard types 2 through 7 could represent common formats like U.S. ASCII, EBCDIC, or graphical data. Local types let each installation define additional formats without coordinating across the network.
Some labels are understood everywhere, like ASCII text. Others are home-made, like the special way one computer likes to store numbers.
§3Implementation
Two system programs called X and Y would handle the type field. When a process sends a message, program Y adds the type field in the first eight bits. When a message arrives, program X reads the type field and can transform the data if needed, such as converting character sets or number formats.
As network usage grew, X and Y could become table driven, where a table specified how to transform between formats. This would let users define transformations without changing the network software.
Two helper programs sit at each door: one labels outgoing mail, the other reads labels on incoming mail and converts it if needed.
§4Example Types
The RFC suggests possible standard types including U.S. ASCII, EBCDIC (used on IBM computers), and a special TTY mode called Mod 33. Another type could point to a translation table so systems could load custom conversion rules without hardcoding them.
Local types could represent each host's own character set, such as the Lincoln writer or DEC ASCII, or local graphics formats used by specific displays and graphics systems.
There could be a type for American text, one for IBM text, one for graphics, and each site adds its own special types as needed.