RE: httpy:// Mark S. Miller (markm@caplet.com)
Sun, 14 May 2000 10:56:49 -0700

At 03:58 AM 5/14/00 , Ben Laurie wrote:
>I'm investigating how we go about registering httpy:. ... which is
>going to be non-trivial.

Sounds to me like a good reason to merge proposals, assuming it makes sense on other grounds...

At 09:45 PM 5/13/00 , Tyler Close wrote:
>I think that it is correct for cap URIs to indicate the Pluribus
>interface to the Acid database and https (and eventually httpy) URLs
>to indicate the CGI interface. This is, afterall, what the 'protocol
>specification' is meant to do.

If I have a capability URI string that designates a particular object, and therefore grants a certain authority, why shouldn't I be able to use that either from a browser (Droplet/CGI style) or from E (Pluribus style), if the object is accessible in both ways? It seems strange that I would need a new designation token in order to invoke the same designated object through a different message conveyance medium.

Besides, the protocol binding mechanism you already proposed would be adequate: httpy: gives back other URIs that contain their own protocol identifier. If an object can be reached through both https: and cap:(?), then you could get both back. You might also say in your httpy: query which protocols you are prepared to speak.

Actually, I think this is the wrong way to negotiate the protocol, but it demonstrates that httpy: itself specifies only an agreed protocol for finding the object (and negotiating the protocol to speak to it). There can be multiple post-negotiation protocols for speaking to the found object, but none of these are the httpy: protocol.

However, I notice something present in cap: URIs that's missing in your proposal: The list of TCP/IP addresses of the SLSs to consult. Sure, the browser can be configured to check some well known ones, but if you're going to have a truly decentralized and non-corruptible system, it's important for the URI string to carry its own list of suggested SLSs as well. Otherwise, the well known SLSs becomes a point of vulnerability. 

         Cheers,
         --MarkM