3 ms·

> URIs are names for data. Yes, they are, essentially. But the difference is that an HTTP URI is not a name for a piece of data -- instead it is a set of inst

> URIs are names for data. Yes, they are, essentially. But the difference is that an HTTP URI is not a name for a piece of data -- instead it is a set of instructions that say "connect to this network endpoint and send them this string; in return you will get some data." The data may be different every time someone follows these steps to dereference the URI. A single URI does not name a single piece of data. In a URI scheme where the URIs really name the data (rather than an address for finding data), you can get away from TCP-style point-to-point networking in cases where it makes sense, like in one-to-many broadcasts. The paper I linked [1] specifically compares PARC's content-centric network protocol against TCP+HTTP in these scenarios. And it's not just one-to-many that can benefit; see also the VoCCN paper [2] for a very different use case. I agree that you could (and should) still use URIs for data in your content-centric network, which is why I think we could evolve the web platform to use CCN without any major upheaval. You just need to add a new URI scheme besides http and https. For the web, the changes would not be at the application layer but at lower layers like TCP and routing. But more importantly, CCN would help enable new types of platforms (like Urbit?) that do not look like the web. [1] http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.pdf http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.... [2] http://www.parc.com/publication/2319/voccn.html http://www.parc.com/publication/2319/voccn.html

pdonis 13y ago
A single URI does not name a single piece of data. It doesn't have to; but there's no reason why it couldn't. And there's no reason why a standard couldn't be developed that let the owner of a URI designate that it named a single piece of data that would never change. Thanks for the links, I'll read them to get a better idea of the proposal.
- mbrubeck 13y ago
  > And there's no reason why a standard couldn't be developed that let the owner of a URI designate that it named a single piece of data that would never change. Yes, I agree. The "new URI scheme" I suggested in my previous comment is one possible way such a standard might be written. That's just one part of the solution, though; if you want the benefits of getting off of TCP then you also need standards for the new content-centric network layer protocol(s) that will replace it, and you need to implement that in your networks and routers.

pdonis 13y ago

A single URI does not name a single piece of data. It doesn't have to; but there's no reason why it couldn't. And there's no reason why a standard couldn't be developed that let the owner of a URI designate that it named a single piece of data that would never change. Thanks for the links, I'll read them to get a better idea of the proposal.

mbrubeck 13y ago
> And there's no reason why a standard couldn't be developed that let the owner of a URI designate that it named a single piece of data that would never change. Yes, I agree. The "new URI scheme" I suggested in my previous comment is one possible way such a standard might be written. That's just one part of the solution, though; if you want the benefits of getting off of TCP then you also need standards for the new content-centric network layer protocol(s) that will replace it, and you need to implement that in your networks and routers.