			P H O N E   P R O T O C O L
			---------   ---------------


PHONE uses what are essentially half-duplex links between processes.
A process, known as the Master, sets up a link to a network slave on the
node in which it is interested.  Some of the communication occurs between
the Master and the network slave.  If the Master wishes to communicate with
a user on that node, known as the Target, then the network slave sets
up communication with that user.  The resulting Master-slave-Target
link is a one-way link.  If the Target in turn wishes to communicate back
to the Master, it reverses the procedure, resulting in two links for the
conversation.

The protocol has been made as asynchronous as possible.  This means that
messages can be sent in essentially undefined order, and received similarly.
The PHONE program must be robust enough to handle all situations.  There
is only one case where a certain message must be sent first, as described
below.

All messages sent from Master to slave are of the following format:

	+----+--------------+-------+
	|msg |sender        |message|
	|type|identification|text   |
	+----+--------------+-------+

	The message type is a 1-byte code identifying the type of message
	being sent.  See the descriptions below.

	The sender identification is an asciz string identifying the sender
	of the message.  The identification is in the following format:
	node::user

	The message text is optional additional information qualifying the
	message.

Many of the messages sent from Master to slave are simply to be relayed to
the Target.  A few messages, however, are handled directly by the slave,
which may then return information to the Master.  Thus the Master-slave
portion of the link is two-way.  The following paragraphs describe the
various messages.

CODE	DESCRIPTION
----	-----------

  7	This message is sent to the slave when the Master wants to verify
	the existence of some person.  It is the FIRST message sent to the
	slave when a link is created for the purpose of talking to
	someone.  The message text is the identification of the desired
	target, in the following format:  node::user.  The slave must
	verify the existence and validity of the Target, and then return
	a status as described below.

  8	This message is sent when the Master wants to ring the Target's phone.
	The message text is a 1-byte flag, true if this is the first ring
	for this call, false otherwise.  The slave must try to ring the
	phone, and then return a status as described below.

  9*	This message is sent by the Master when it wants to hang up on the
	Target.  The Target then knows that the Master is breaking the link.

 10*	This message is sent by a Master when it is busy and cannot perform
	an operation requested by some other process.  This typically occurs
	after a Target has established a link back to a Master, thus becoming
	a Master itself.  It then would send a busy message if it couldn't
	handle a ring, for example.

 11*	This message is sent by a Master when it answers a call from another
	Master.  This occurs after a Target has established a link back to
	a Master, thus becoming a Master itself.  When the original Master
	receives this message, it knows that the Target has established
	a return link and can answer the call.

 12*	This message is sent by a Master when the user rejects a call from 
	another	Master.  This occurs after a Target has established a link 
	back to	a Master, thus becoming a Master itself.  When the original 
	Master receives this message, it knows that that Target has 
	established a temporary return link and that the user does not 
	want to answer the call.

 13	This message is sent to the slave when the Master no longer needs it.
	It tells the slave to exit.

 14*	This message is sent by the Master when it has a conversation text
	fragment for the Target.  The message text is one or more characters
	of conversation.

 15	This message is sent to the slave when the Master wants the next
	directory line for a remote directory.  The slave must build the
	directory line, adhering to the format as displayed on the screen,
	and return it to the Master.  If there are no more processes to
	display, the the slave should return a null line.  NOTE that the
	slave exists only for the duration of one remote directory command.

 17*	This message is sent by the Master when it wants to force the Target
	to set up a link to a third person.  It is used when the Master
	establishes a conference call, in order to force all existing 
	participants to recognize the new person.  The message text is an
	identification of the new person, in the following format:
	node::user.

 18*	This message is sent by the Master when it wants to put the Target
	on hold.

 19*	This message is sent by the Master when it wants to take the Target
	off hold.


* These messages are simply relayed from the slave on to the Target.

Some of the messages handled directly by the slave require the slave to
return a status to the Master.  This status is always a 1-byte code selected
from the following table.

CODE	DESCRIPTION
----	-----------

 0	Some problem has occurred that is not covered by other codes.
 1	The operation was completed successfully.
 2	A user identification (node::user) was syntactically invalid.
 3	Something prevented the slave from communicating with the user.
 4	The user identification (node::user) was missing the user name.
 5	The slave does not have the necessary privileges.
 6	The specified Target user does not exist.
 7	The Target's terminal cannot be used by PHONE.
 8	The Target logged off during the procedure.
 9	The Target's phone is off the hook (e.g., /NOBROADCAST set).

NOTES
-----

1.	The user identification parser must be able to handle
	strings which are more complex than the format given above.
	The complete format is as follows:

		[[_]node::]...[_]node::user

	The last node is the home node of the user.

2.	The Master must be able to handle random deaths of the slave.
	The slave will simply vanish if it gets totally confused.
