W3C home > Mailing lists > Public > public-credentials@w3.org > November 2015

Re: Solutions to the NASCAR problem?

From: <henry.story@bblfish.net>
Date: Mon, 23 Nov 2015 15:02:44 +0000
Cc: public-credentials@w3.org
Message-Id: <EEC3DBA1-A9FE-452D-B0DA-9D09A1C564A7@bblfish.net>
To: Steven Rowat <steven_rowat@sunshine.net>

> On 23 Nov 2015, at 14:41, Steven Rowat <steven_rowat@sunshine.net> wrote:
> On 11/23/15 3:01 AM, henry.story@bblfish.net wrote:
>> I prefer to think of resources needing
>> authentication,
>> [snip]
>> http://www.w3.org/wiki/WebAccessControl
> Interesting -- would you consider that control via authentication of the resource is a meta-related form of Content Centric Networking (CCN) [1] or Named Data Networking [2] ?

Interesting. I had heard of that, and exporing CCN is on my more distant todo list.

The Semantic Web is based on a very general mathematical logic  of relations where the identifiers are URIs - Universal Resource Identifiers - so that it can apply much more widely than HTTP. Patterns that we can use over HTTP using Linked Data over http(s) ( which is an application of RDF ) can thefore be extended to other protocols. 

But it helps to start by exploring HTTP ( whilst always keeping in mind CCNs ),
as the standards are much more stable, the tooling is much more widely deployed, 
and the extra constraints all of these impose means one is less likely to get lost
in building all of that infrastrucutre again.

One of the advantages of the LinkedData principle is though that it won't take much
to integreate systems like
-  Tor and its onion routing,
-  i2p and its garlic routing.
- dht based content such as that proposed by Digital Bazaar
- etc, etc...

At the logical layer of the semantic web one has the full generality of logic. Adapting Wittgenstein's motto: what you can't express in RDF therof thou must remain silent. 

As far as applications goes it is in my experience a mistake to try to deal with all protocols
simultaneously, as that tends to fragment all the application space, with different
implementations no longer able to communicate as they the applications they write then
have no overlapping space. What is needed is rough consensus and running and interoperable code, so one has to start with something reasonably well understood, where interoperability
can be tested. Once that layer is well founded, deployed and used, it is then possible
to extend further. That should be easy if the protocols are written declaratively, which
the web is. ( when it is not abused as SOAP did )

> I looked through the WebAccesControl Implementation and Related links, and saw no mention of the relationship, but just in case you haven't come across this I'll provide a bit of background (that seems unlikely, but anway...)
> Some published rationales (ie, by Van Jacobson, who is now working at PARC) [5,6] made the assertion that the problems of ineffective web publishing and money transfer and security and scalability would remain essentially insoluble until a CCN or NDN system is implemented throughout the Internet.

It is good that people are researching that. When it is stable, and our work is stable it will be very interesting to integrate that too.

> I've been watching with interest the work of PARC on this [5], and they recently released a "CCN lite" [6] of CCNx, which a group of programmers have been working on for several years, and apparently across both CCN and NDN there's a large academic support system and some government support money involved.

yep, its definitively interesting. But its difficult to gather the bandwidth for that too,
when we have people who are struggling understanding how to use the simplest use of RDF
over http... 

> [1] https://en.wikipedia.org/wiki/Content_centric_networking
> [2]http://named-data.net/
> [3] https://en.wikipedia.org/wiki/Van_Jacobson
> [4] http://named-data.net/content-centric-networking-video/
> [5] https://www.parc.com/work/focus-area/content-centric-networking/
> [6] http://www.ccn-lite.net/
> Steven Rowat
Received on Monday, 23 November 2015 15:03:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:26 UTC