[cap-talk] Capability Semantics
Jed at Webstart
donnelley1 at webstart.com
Tue Jul 25 20:27:27 EDT 2006
At 03:49 PM 7/25/2006, David Hopwood wrote:
>Jed at Webstart wrote:
>...
> > I can understand an emphasis on http <for the Web Calculus>,
> > but I think at least email must be included. At present it seems
> > that email is nearly (absolutely?) the only means for individual
> > domain to domain (e.g. person to person) communication.
> > Without the ability to safely send capabilities in email, it's
> > difficult for me to see how any richer object based sharing
> > structure can be built up.
>
>Another reason why you need to consider email, is that email is a
>"push" protocol, while HTTP is primarily a "pull" protocol (although
>it can be used for "push" as well). Also email is store-and-forward
>(no end-to-end communication), while HTTP is end-to-end.
>
>"Push" and "pull" protocols have fundamentally different properties
>in terms of secure interaction. If the user wants to *give* some
>resource to another user, he or she will normally think of a push
>protocol as being the most natural way to do that. Also, most users
>don't have full control over a web server, which leaves them with no
>way to receive unsolicited (or not directly requested) messages
>containing capabilities.
I pretty much echo the above concerns - which is why I think
email is important for capability communication. I don't see
an immediately available and convenient alternative. However,
with regard to:
>Store-and-forward transport protocols place additional constraints on
>any higher-level protocol built on them, and you need to know whether
>the web calculus can handle these constraints gracefully.
Isn't it clear that as a capabilities as data protocol the Web
Calculus representations, YURLs, will pass through any
sort of store and forward transport protocol unaffected?
Even the sorts of network mechanisms that I've suggested
that require marshaling and unmarshaling (translation into
and out of communication buffers) work fine through any
sort of store and forward mechanism, as long as the capabilities
don't need to be invoked or redirected at any point along the way.
--Jed http://www.webstart.com/jed/
More information about the cap-talk
mailing list