RFC 6 UNKNOWN ARPANET · HISTORY

Conversation with Bob Kahn

Notes from a 1969 discussion about character code conversion and Host-IMP communication.

On rfc-editor.org ↗
PUBLISHED
April 1969
AUTHORS
S.D. Crocker
STREAM
Legacy
CONTEXT
Early ARPANET Host software discussions
DOI
10.17487/RFC0006

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
Network Working Note                                    Steve Crocker, UCLA
RFC-6                                                   10 April 1969



                        CONVERSATION WITH BOB KAHN





I talked with Bob Kahn at BB&N yesterday.  We talked about code conversion
in the IMP's, IMP-HOST communication, and HOST software.

BB&N is prepared to convert 6, 7, 8, or 9 bit character codes into 8-bit
ASCII for transmission and convert again upon assembly at the destination
IMP.  BB&N plans a one for one conversion scheme with tables unique to the
HOST.  I suggested that places with 6-bit codes may also want case shifting.
Bob said this may result in overflow if too many case shifts are necessary.
I suggested that this is rare and we could probably live with an overflow
indication instead of a guarantee.

With respect to HOST-IMP communication, we now have a five bit link field
and a bit to indicate conversion.  Also possible is a 2-bit conversion
indicator, one for converting before sending and one for converting after.
This would allow another handle for checking or controlling the system.

The HOST can send messages or portions of a message to its IMP specifying

        1.  Tracing
        2.  Conversion
        3.  Whether message is for destination IMP or HOST
        4.  Send RFNM
        5.  HOST up or down
        6.  Synchronization
        7.  Format Error Messages
        8.  Master Link Clear
        9.  Status Requested

The IMP can send to its HOST information on

        1.  Conversion
        2.  REFNM Arrived
        3.  IMP up or down
        4.  Synchornization
        5.  Called HOST not Responding
        6.  Format Error
        7.  Status in IMP

I also summarized for Bob the contents of Network Notes l, 2, and 3.

AI ELI5

On this page
PROBLEMDifferent ARPANET hosts used different character encodings and had questions about how to handle code conversion transparently across the network.
MECHANISMSteve Crocker documents a conversation with Bob Kahn from BBN about how IMPs can convert between character codes, what link fields should carry, and what status information flows between hosts and their IMPs.
EARLY DESIGN NOTESThis informal note captured early thinking about network architecture that fed into later protocol development. It records design questions that helped shape how the ARPANET handled heterogeneous systems.

§1Character Code Conversion

The ARPANET connected hosts with different word sizes and character encodings. PDP-10 computers used 5 seven-bit ASCII characters packed into 36-bit words; IBM 360s used EBCDIC codes in 32-bit words. The conversation with Kahn discusses BBN's plan to convert all data to and from the standard NVT-ASCII format in the IMPs, with character code tables specific to each host. Crocker suggests that overflow from case shifting might be acceptable since it is rare.

Some computers think words are 6-bit puzzles, others think they're 8-bit. The network agreement says 'everyone translate your puzzle to the standard shape, send it through, then translate back'.

§2Host-IMP Protocol Details

The note documents Host-to-IMP communication fields and signals: a 5-bit link field to identify the connection, a conversion bit, and status information. Hosts can send commands about tracing, conversion control, message destination, RFNMs (ready-for-next-message), host up/down status, synchronization, error format, and link clearing. IMPs respond with status on conversion, RFNM arrivals, IMP status, synchronization, host responsiveness, format errors, and internal state.

A host tells its IMP what to do (trace this, convert that, is the host ready?) and the IMP tells back what happened (code converted, message ready, I am working).

§3Historical Note

This RFC is an informal working note, not a specification. It captures early ARPANET design discussions that informed later protocol work. It shows the practical concerns engineers faced when building the first packet-switched network connecting heterogeneous computers.

This is not a rule book, just notes someone wrote down while working on a hard problem. It shows what people cared about in 1969.