All these functions should return an RPC response, either the specified value (on success) or one of Volity's fixed list of RPC faults (on failure). Where a return value isn't specified, then the function should return truth (a boolean).
RPC timeouts can generally be handled the same as RPC faults or Jabber stanza errors.
The server and referee may have additional admin RPC requests in the "admin.*" namespace. These would be defined by the server implementation, not by the Volity spec.
Arguments of true or false refer to literal values of "1" and "0" marked as <boolean> datatypes, as defined by the XML-RPC spec.
Note that numeric values sent by ECMAScript in the client may arrive as Jabber-RPC <double> tags, even if the values are whole numbers. See the discussion on Jabber-RPC.
Volity presumes that a client handles game RPCs and user actions in a single-threaded way. (This is currently true of Gamut). In other words, a client might not respond to an RPC until it's finished handling a previous RPC.
Therefore, it is unwise for a referee (or any entity contacting a client) to block waiting for the client's RPC response.
(The current Perl and Python referee libraries are designed to not block, ever. When they need to query a client, they use asynchronous callbacks with timeouts.)