It provides the information needed to design code that uses the functionality but give no hint on how the functionality is provided. In that sense it is the opposite of a protocol specification. Nor does this spec instruct how to write the code for it does not even specify the language in which it is called.
Imagine a source of port pairs. If <A,B> is such a port pair then there are two queues asociated with this pair, one queue from A to B and the other from B to A. The queues of a new pair are empty. A.in(ob) adds ob to the first queue and B.out() evaluates to the oldest member of the same queue while removing it from the queue. B.out() blocks while the queue is empty. The same goes for the other direction. In particular ports may be passed, as obs, thru these queues. I am deliberatly vague about what else can pass thru but certainly a byte can.Some of these ideas are rather similar to fundamental Joule constructs. Like the Joule channel, they are concieved to make distribution transparent. The Jould channel has more function at the bottom and I don't want to argue here whether it is necessary to put that function at the bottom. The language E also exemplifies these ideas.Imagine further a port pair whose ports are on different machines. It is unspecified here how this comes about but is to be presumed nonetheless.
This construct binds communications to capability discipline. The port is a capability to communicate with the holder at the other end. This sort of port could be a Java interface except that its strength stems from functionality that it lacks. Such functionality includes