First, computers do communicate directly now (1975). In the late 1950s the Social Security Administration announced a format for IBM seven channel magnetic tape on which it was prepared to receive reports of earnings and payroll deductions. Note the limitations: (i) magnetic tapes are mailed rather than direct electronic communication--admittedly entirely appropriate in this case. (ii) A single fixed kind of message with a fixed set of parameters exists for each report. (iii) There is only one receiver of information which can dictate the format. Today information is often exchanged electronically among computer systems belonging to different organizations, and this is usually by specific treaty betwen the two organizations, but sometimes a group that will be communicating has agreed on formats. An example is the U.S. Navy's Fleet Data System for exchanging information among ships about what their radars and other sensors can see so that each ship can have the full radar picture acquired by the whole fleet. In connection with the extension of the system to NATO, it was completely redesigned, and on a designated day, all users switched to the new system.
Our goal is more ambitious in the following respects:
1. A common language is to be adopted that can express business communications. For example, requests for price quotations, offers to buy and sell, queries about delivery times and places, inquiries about the status of delayed orders, references to standard commercial legal agreements. If possible, the same language should with only different primitives suffice to communicate the Navy's or the FAA's radar information or a request from one state's department of motor vehicles to another's for a list of a person's traffic convictions.
2. Any organization should be able to communicate with any other
without pre-arrangement over ordinary dial-up telephone connections.
Of course, this requires authentication procedures and verification of
authorization procedures, but let us not be unduly distracted by the
security aspects of computing lest we end up with a secure method of
communication and nothing to say.
3.
The system should be open ended so that as programs
improve, programs that can at first only order by stock numbers can
later be programmed to inquire about specifications and prices and
decide on the best deal. This requires that each message be
translatable into a human-comprehensible form and that each computer
have a way of referring messages it is not yet programmed to
understand to humans. When a new type of message is to displace an
old one, the programs should send both
until all the receivers can understand the
new form. Thus the crises of cutover days, as in the naval
example, could be eliminated.
4. CBCL is strictly a communication protocol. It should not presuppose any data-base format for the storage within machines of the information communicated, and it should not presuppose anything about the programs that use the language. Each business using the language would have a program designed to use the particular part of CBCL relevant to its business communications. Thus CBCL presupposes nothing about the programs that decide when to order or what orders to accept.
5. CBCL is not concerned with the low-level aspects of the message formats, i.e., what kinds of bit streams and what kinds of modems, except to remark that the system should avoid traps in these areas, and the users should be able to change their systems asynchronously. Presumably CBCL would use the same low level protocols used for more simple inter-business communications like person-to-person messages and file transfer.
We do not have a final proposal but here are some ideas:
1.
The messages are lists of items punctuated by parentheses.
The lead item of each list identifies the type of message and is used
to determine how to interpret the rest. The items may be either
sublists or atoms. If an item is a sublist, its first element tells
how to interpret it. Atoms are binary numbers of say 32 bits. A
dictionary tells what each means. Other forms of data
may be used provided they are demarcated by appropriate
punctuation and provided they are pointed at from lists that tell how
they are to be interpreted.
2. Here are some examples:
a. (REQUEST-QUOTE (YOUR-STOCK-NUMBER A7305) (UNITS 100))
b. (REQUEST-QUOTE (PENCILS #2) (GROSS 100))
[1998: The above two examples correspond directly to what has been proposed for ICE apart from the names of the structures.]
c. (REQUEST-QUOTE (ADJECTIVE (PENCILS #2) YELLOW) (GROSS 100))
[1998: The point of ADJECTIVE is that a program not understanding YELLOW could nevertheless understand that #2 pencils were called for, and could reply that they don't have any pencils, if that were so.]
d. (WE-QUOTE (OUR-STOCK-NUMBER A7305) (QUANTITY 100) (DELIVERY-DATE 3-10-77) (PRICE $1.00))
[1998: This is also standard today.]
e. (PLEASE-SAY (IOTA (X) (AND (RED X) (PENCIL X))))
[1998: This uses the Russell description operator, essentially
corresponding to the English word ``the''. [1998: That's not such a
good example. Here's a better one using the Hilbert 
(epsilon) symbol: (PLEASE-RESERVE (EPSILON (X) (AND (IS-FLIGHT X) (DEPARTS
MONDAY) (ARRIVES (BEFORE WEDNESDAY))))). 
stands
for ``an x such that P(x). If you don't like , you can
write (AN (X)...,etc. This raises a general expression about
variable binders. CBCL proposes to handle them in a standard way,
namely (<binder> (<variables> <body>), i.e. all binders
including those to be invented in the future are handled the same.
The logical operators AND, OR, and NOT are also to be standard where
used at all.]
It appears that some items may require a variable number of modifiers.
As a toy example, imagine writing conventions that would permit any Monopoly-like game to be played by independently written programs. Suppose that the moves are communicated to a referee who receives requests to roll the dice and returns information about what squares the pieces landed on and what `chance' cards were drawn. The programs would communicate offers to buy and sell directly to each other and to the `banker'.
CBCL should have an important property enunciated by Chomsky in his
Reflections on Language as a characteristic of human language.
(Linguists tell me that whether natural languages have it is
controversial; but whether they do or don't, CBCL shall have it.) The
principle (reworded considerably) is that no grammatical position
should require an identifier or a number per se but should allow a
phrase. For example, instead of requiring a stock number, an
expression designating the stock number, such as `the same stock
number as last week' or `the new stock number of the item that was
formerly stock number 2531'. We don't really mean these English
phrases but rather whatever CBCL expression translates into them.