RFC 6 UNKNOWN ARPANET · HISTORY · HOST-IMP

Conversation with Bob Kahn

A note recording a conversation about character conversion and Host-IMP communication.

On rfc-editor.org ↗
PUBLISHED
April 1969
AUTHORS
S.D. Crocker
STREAM
Legacy
LINK FIELD
5 bits
CHARACTER CODES DISCUSSED
6, 7, 8 or 9 bits; converted to 8-bit ASCII
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.

ISO Plain Language

On this page
PROBLEMThe conversation raises how the ARPANET should handle hosts that use different character codes and how hosts communicate with their IMPs.
MECHANISMSteve Crocker records proposals discussed with Bob Kahn about character conversion, link fields and messages exchanged between hosts and IMPs.
DOCUMENT TYPEThe document is a record of a discussion, not a protocol specification.

§1Character-Code Conversion

The note says BB&N was prepared to convert character codes of 6, 7, 8 or 9 bits into 8-bit ASCII for transmission, then convert them again at the destination IMP. The proposed conversion used a one-for-one table unique to each host.

Crocker raises the possibility that hosts with 6-bit codes might need case shifting. Kahn notes that too many shifts could overflow; Crocker suggests that an overflow indication might be acceptable because he considers the case rare.

The discussion proposes translating different character codes into 8-bit ASCII for sending, then translating them again at the destination. It also considers what to do if changing letter case causes overflow.

§1Host-IMP Fields and Conversion Control

For host-to-IMP communication, the note says there is a five-bit link field and a bit indicating conversion. It also discusses a possible two-bit conversion indicator: one bit for converting before sending and another for converting after sending.

The note suggests that the two-bit arrangement could provide another way to handle checking or controlling the system. It records this as a possibility in the conversation.

The host-IMP message has a link field and a conversion indicator. The speakers also consider using two conversion bits to give the system another way to check or control conversion.

§1Information Hosts and IMPs Exchange

The note lists information a host can send to its IMP, including requests about tracing and conversion, whether a message is for a destination IMP or host, readiness for the next message, host status, synchronization, format errors, clearing a master link and requesting status.

It also lists information an IMP can send to its host: conversion information, arrival of a ready-for-next-message signal, IMP status, synchronization, a called host not responding, format errors and IMP status details.

A host can send its IMP control requests and ask for status. The IMP can report message readiness, host or IMP status, synchronization and errors.