[cap-talk] Capability levels - transparent network extension, no encryption

[David Hopwood]

Jed at Webstart wrote:
> That's why I published RFC 712 - essentially
> an earlier version of the DCCS description (2/76).

RFC 712 is one of the few RFCs that are not online. If you still have a
copy (scan or transcript), I'm sure that <rfc-editor at ietf.org> would
appreciate it.

[...]
> What about the case, though, when the capability being sent "up"
> to go out on the network is a local CCS capability that isn't a local
> representation of a network capability?  In that case it would seem
> that the network extension service must store the local CCS capability
> for remote access and make up some sort of a YURL that it can
> communicate through the existing YURL to allow the desired delegation
> to happen.  Even beyond the data formatting issues (how do YURLs
> show up in 'invocations' on other YURLs?) this business of turning
> a CCS capability (e.g. consider CapDesk or E) into a network capability
> of the YURL sort seems a bit problematic.

I'm not sure why.

There must be a mechanism to create a new object at the network level,
assigning it a new capability representation (YURL, etc.) So just create
a new network object with the behaviour of forwarding to the local object.
This is often called a "scion" or "skeleton". Various optimizations are
possible -- cacheing so that there is at most one scion per local object,
shortening chains of scions and "stubs" (proxies), etc. A variant that
also supports object migration and acyclic distributed GC is described
in:

  M. Shapiro, P. Dickman, and D. Plainfossé
  SSP Chains: Robust, Distributed References Supporting Acyclic Garbage
  Collection. Technical Report 1799, Institut National de la Recherche
  en Informatique et Automatique, Rocquencourt, France, 1992.
  <http://www-sor.inria.fr/publi/SSPC_rr1799.html>

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>