Some additions to Bill's reply:
>How useful and common is FORKing ...
FORK can't be implemented with CALL because CALL passes as the last key a (newly created) resume key to the caller. With FORK the caller can pass any key there, and often does so to advantage. I gave an example earlier in which a start key is passed to the server.
>how useful and common is RETURNing ...
Yes, the RETURN operation is unnecessary if there were some other way to become ready (which in KeyKOS is done by RETURNing to a data key). It is merely a performance issue (but probably an important one).
> ... on a start key
Let me emphasize what Bill said, that the effect of the operation on the client mustn't depend on the key invoked.
>> it seems to burden all servers that don't trust their clients with
the necessity of explicitly checking every resume key
>we provide a kernel implemented operation ...
It's called the RETURNER key. Norm's OSR paper neglected to mention that it checks for a resume key.
>supposing the FORK operation on a start key did not allow ...
FORK seems more exotic than CALL, but it is really simpler; it just sends a message to a key. I don't know what you gain by restricting it (if you buy the philosophy that a message is independent of its sender). Arranging to get a reply takes more work; it is CALL that is complicated, but it's in the kernel because of its fundamental importance.