RFC 42

Message Data Types

πŸ“… published March 1970, from ietf

RFC 42: Message Data Types πŸ’–

Network Working Group πŸŽ€ Request for Comments: 42

okay so bestie, this one is from 31 March 1970 and it was written by E.I. Ancona at M.I.T. Lincoln Laboratory 🧚 the original doesn't list a category, and it doesn't say it obsoletes or updates anything, so there's no lineage info to add. it's just the OG message-types proposal, and it's giving foundational ✨


Proposal ✨

okay the main idea is super simple: we reserve the first eight bits of every normal message for a message data type. πŸ¦‹ adopting this does NOT mean everyone agrees on which data types to use. it only sets up the rule that those first eight bits are not for user data. that's the whole vibe πŸ’…


Discussion 🌸

here's a little picture of how the pieces fit together πŸ‘‘

                 Socket    Port
                 |    |      |    ____________
                 |    V      V   /            \
                 V              /              \
                     |=|    /==|                |
         -------(+)->|Y|--><   |                |
                     |=|    \==|                |
                               |    PROCESS     |
                               |                |
                     |=|    /==|                |
         -------(-)->|X|<--<   |                |
                     |=|    \==|                |
                                \              /
                                 \____________/

it's important to set up message conventions early, bestie πŸ™ˆ otherwise every pair of programs on the network ends up with its own random conventions and it becomes a total mess πŸ’€

as network usage grows, network languages might show up to describe both the syntax and the semantics of messages πŸ”₯ but even before that happens, a simple move is to describe messages with a message type that both sender and receiver know how to read 🫢

also, the currently running programs still have to keep working with this convention 😭 so the plan is to write two system programs, called X and Y (we're going with "for lack of better names" energy πŸ’…). they'll put in the type info and test it, and they'll take it back out. basically they do transformations on the data, like changing character sets or number formats. and as the network grows, X and Y could get table driven, with the table set by the user ✨


Standard Types and Local Types πŸŽ€

we want two kinds of message data types: standard and local πŸ’œ

X and Y can't be expected to transform between every possible data representation and the representation of whatever machine they're running on 😭 and adding a new representation shouldn't force a change to X or Y either. so only a fixed number of message types get meaning across the whole network. those are the standard types πŸ‘‘

there are two classes of local types: MYLOCAL and YOURLOCAL 🌈

  • MYLOCAL n means: this is type n in the sending host's set of types.
  • YOURLOCAL n means: this is type n in the receiving host's set of types.

Conventions 🧚

one way to set up standard and local types is to make standard type 0 YOURLOCAL and standard type 1 MYLOCAL πŸ¦‹ in those cases, the second byte holds the local type number.

local type 0 means user-specified, which is the iconic "contents unchanged and unchecked" move ✨ installations define their own local type numbers, and those are normally available from the Network Information Center πŸ“

so initially, every message sent to currently running programs is type 0, n, and every message received from them is type 1, n, where n is the local type number of the installation's character set πŸ’–


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.

πŸ’€ the original RFC was put into machine readable form for entry into the online RFC archives by Robbie Bennet, 11/98.
πŸ“¦ where this page comes from