[foaf-protocols] vrsn and dnssec

peter williams home_pw at msn.com
Sat Dec 11 00:13:12 CET 2010


As I read the historical wpad material, it's obvious that folks were
discussing rdf and its support for resource discovery processes back then.
Some folks were just not willing to wait; focusing on discovering javascript
encodings of the rules for web-centric proxing, caching, load balancing,
etc.

 

What's was the scoop and what was the politics (that is still relevant
today)?

 

Moreover, what can we do today in the FOAF+wpad arena that could not be done
then?

 

In the todays era (where my personal "PC" has 512G of RAM, and 80 cores at
2Ghz each with io to match, and can happily support 250K normal users
piddling around on the web) I can afford to be a virtual ISP - inviting
folks to create a connectionless ssl vpn session between their browser and
me - whose mere connection and change in default route, if nothing else,
creates a network event that forces a new wpad discovery, the associated
DNS/DNSsec tree walk, and the loading of the config file defining the url
redirector/tunneling logic.

 

 

 

From: peter williams [mailto:home_pw at msn.com] 
Sent: Thursday, December 09, 2010 5:31 AM
To: 'foaf-protocols at lists.foaf-project.org'
Subject: RE: [foaf-protocols] vrsn and dnssec

 

One of the things DNS provides the semweb world with is, of course, good old
web proxy location services to browsers. That is. an RR field can be a URL
to the proxy config file, that almost EVERY browser in the world actually
pings (nice auto-DDOS opportunity, here.).

 

So, could one imagine typing peter at verisign.com, where the name resolver
then looks up peter.verisign.com to find an RR, whose web proxy URL is a
pointer to the foaf file (which contains the next generation browser proxy
config info)?

 

Now, such is the nature of the internet that anyone can locally-master the
name space verisign.com (things like trademarks, aside), and locally cache
the RRs in the DNS cache of the resolver, or the nameserver. What really
matters is. who is willing to accept the key that introduces the authority
of the naming space.

 

Ok. Its clear to me. that there is lots for an incubator to work on in just
the protocolar aspect of FOAF, speculating about work topics that might be
formalized after an appropriate time spent on brainstorming. As Dan
indicates, it's not the job of the incubator to work on the topics, or even
decide the appropriate forum of any followup activities. Its job is to
formulate a coherent wish list.

 

 

From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of peter
williams
Sent: Wednesday, December 08, 2010 8:05 PM
To: foaf-protocols at lists.foaf-project.org
Subject: [foaf-protocols] vrsn and dnssec

 

http://finance.yahoo.com/news/VeriSign-Launches-New-DNSSEC-iw-3797902406.htm
l?x=0
<http://finance.yahoo.com/news/VeriSign-Launches-New-DNSSEC-iw-3797902406.ht
ml?x=0&.v=1> &.v=1

 

Of course, it's all centralized in the US..

 

I keep hoping VeriSign will do what it did with PKI - partner with major
national telcos to customize the solution, so policy making is devolved from
the US. Who operates the computers. is irrelevant, in the normal course of
events.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101210/79203419/attachment.htm 


More information about the foaf-protocols mailing list