[cap-talk] OO interoperation via OCap, presentation level issues

[Jed Donnelley]

On 5/6/2008 6:20 PM, Baldur Johannsson wrote:
> Pardon but did you mean that components written in other ocap
> languages might want to
> inter-communicate over Pluribus (the intervat protocol of E)?

Essentially yes.  However, to be honest I think I grossly
over minimized the difficulty of such inter-communication.
I've taken a little time to respond while I've thought through
where I was coming from and what the difficulties might truly be.

I think it might be worthwhile to describe where I was coming
from as I think it might illustrate some aspects of such
inter-communication that could be usefully modularized.

In the capability systems that I've worked most on, RATS,
the DCCS design, and LINCS/NLTSS, what I would call the
presentation layer (from the ISO model) - essentially the
marshalling and unmarshalling of parameters - was disassociated
from any need for trust (kernel?/TCB).  For example, in the
DCCS messages consist of a block of bits and a block of
capabilities - undifferentiated.  In LINCS/NLTSS since the
capabilities are data, the messages are simply a block of
undifferentiated bits.

To be sure, in any communication mechanism there must be
presentation level conventions.  In NLTSS, for example,
we had a "token" protocol and a set of conventions with
it that were used at the application level, e.g. responding
to capability invocations.  Our message passing system of
course knew nothing about these presentation level
conventions.

The main reason I'm writing this message is because I find
it an interesting question as to whether the presentation
level transformations can be kept out of the "TCB".  It may
be that when you're talking about language level systems this
isn't a big issue because the TCBs are so large in any case.
Even then, however, it might be that there could be value in
a stronger trust barrier between environments separated
across vats, e.g. between different language or OS OCap
implementations, and the presentation level logic could be
kept out of the TCB for such communication.

In any case I see value in standardization of the presentation
level protocol for OCap communication.  I hadn't considered
Pluribus in that context before.  After this thinking, however,
I think I should take a closer look.

> If so then I would love to sink my teeth into specification of the
> Pluribus protocol.

Seems like a worthwhile project to me.  It's on my queue also.

Regarding:

On 5/8/2008 4:30 AM, Kevin Reid wrote:
 > ...
 > Note that VatTP as it is today will be going away when the Pluribus
 > implementation is rewritten in E; the encryption layer is to be
 > replaced with SSL. There will still be a layer on top, to support
 > delimited variable-length messages and PING messages.

Doesn't that "layer on top" also have to distinguish serialized
capabilities and other parameters with semantic meaning (e.g. strings,
integers, etc.)?  I ask in case I might be focusing at the wrong point.

Do you (Kevin) consider that "layer on top" to be a reasonable place
for standardization that will allow interoperability between OCap
languages and OSs?  If not, why not?

--Jed  http://www.webstart.com/jed/