[foaf-protocols] [FOAF-SSL] XRI, WOT, Alternate transports, Server security, Naming, DNS support

Story Henry henry.story at bblfish.net
Fri Apr 16 12:52:48 CEST 2010


On 16 Apr 2010, at 04:16, thib wrote:

> Maybe I read you very wrong, but I feel you might be taking a quite 
> defensive stance here

I was trying to point out to you the following:

  1. what we are doing is compatible with other protocols and uri schemes
  2. Philosophically I think it is very well founded, so what we are doing
    I am certain will last
  3. developing new URI schemes, and protocols takes a lot of time and energy
    and the problem you were trying to solve may end up being solved in some
    other way, or being unimportant along the 

> [ ✄ ]
>> 
>> Yes, it's going to be difficult in a discussion to trust the arguments more than
>> the future. Since we know the future is going to come up with unexpected answers
>> we might as well not try to out engineer the future answers that are going to
>> come up.
> 
> Well, I'm sorry, but I think this is a bit fallacious.  Anticipating 
> questions is different than anticipating answers.  I'm just leaving room for 
> answers, I wouldn't pretend.

If you think we have excluded answers, please argue for that. I don't see that
have.

> 
> Note that there could be a practical use even today, I'll take the SPDY 
> example again:  someone wants to try it out and experiment with it, then is 
> not satisfied and whishes to switch back to HTTP -- wouldn't it be better 
> for the owner to be able to choose the protocol, rather than creating 
> different IRIs referencing the WebID and trying to convince people to use 
> the desired protocol (twice)?  I believe some people would want these tests 
> to be transparent to the outside world.  Again, it's not excluding the 
> second solution, it's just a choice.

No problem. If you want to use another type of URI associated with another
protocol in your X509 cert, you can.


> So, this is about making the scheme "opaque";  does anybody think it's worth it?

I don't think it's about making the scheme opaque. What you are doing is wanting
to invent a new dereferencing protocol. If you don't have that, then your IRIs
won't have any sense.

See the sense/reference distinction here

http://esw.w3.org/Foaf%2Bssl/FAQ#How_does_Secure_Authentication_Work_with_FOAF.2BSSL.3F

and if you want to pursue that in a lot more detail

http://frege.brown.edu/heck/pdf/published/FregeContribution.pdf

You can't just magically associate meaning with names.
 
> [ ✄ ]
> 
>> [snip]
>> 
>> And you are suggesting that instead they make their site really confusing by
>> overwriting 10 years of useage of their WebIds with new unrelated content?
> 
> No, that's obviously wrong.  And what's the alternative?  Another domain? 
> That's even more wrong.  

Not really. Another domain is quite a simple solution. 

> That would merely be workaround, not a real answer. 
>  What I'm thinking about is a dedicated namespace for WebIDs, different 
> from the one of the organization website pages (or whatever they need for 
> their new activities), but still resolvable via DNS and HTTP (possibly a 
> different, or a set of, dedicated HTTP server(s), but not necessarily).

You are probably thinking of the recently proposed accnt scheme
http://hueniverse.com/2009/08/making-the-case-for-a-new-acct-uri-scheme/

Either you map those new URLs to http(s) URLs in which case the problem above still exists, or you have to invent quite a lot of new things.

In any case I don't quite see what the problem is. Rephrase your attempted counter example with home page. Are you suggesting that people in the future won't want to have home pages? 

Well you may suggest that people use accnt:henry.story at bblfish.net as pointers to their home page, and that those could then point to the home pages themselves. But don't you think people will be wanting to link to those home pages too? And since people will be pointing to home pages, then it will still be difficult to change
the location of those home pages - without breaking the links on the web.

  I think you will find that many of your arguments will just displace the current problems to the problems for your accnt scheme. 

> 
>>> [snip] It's a problem that, in a theoretical sense, cannot be solved with URLs, 
>>> because IDs are not locations
>> 
>> It's a problem that will occur with any IRI. In a decentralised naming system you
>> cannot change the way people use the names you have coined. If you attempt to change
>> the meaning in a non compatible way, you will have the world against you when 
>> defending your decision.
> 
> Yup;  now what if you didn't have to change it, and still be able to 
> restructure the website (or whatever is hosted there)?  My opinion is that 
> this ability has a certain value.

As I pointed out above, people will still be linking to the web site, so you
won't be able to restructure the web site without breaking links to you. And if there
are no links to your web site, then you can change the URLS without any danger too.

> 
>> so take XRIs.
>> 
>> What if I choose =juce as my XRI. Then in the future juce comes to mean something
>> vulgar. Now XRIs I believe have this way of saying that a name is forever valid,
>> right? So how would I undo that name?
> 
> That's not the issue I'm trying to solve.  XRIs partially solved it with 
> i-numbers, I believe, but that's not something I would really care about. 
> People can still setup special IdPs for this if they want.
> 
>>> Now, even if they did add an "id" subdomain from the beginning, why would 
>>> that be necessary for the lookup clients?  In this example, the client knows 
>>> he wants to get an ID which is global to that organization.  If there were a 
>>> special protocol to look up IDs in place of HTTP, stating "id" anywhere 
>>> inside the ID itself would be simply redundant and useless.
>> 
>> You remind me of the people 30 years ago who were rightly worried about every
>> byte used in writing programs. At the time given the available memory that was
>> clearly correct. Had you given them the job of writing the web, every html element
>> would  have been an integer id, to be looked up in some lookup table somewhere. 
>> That's what led to weird and impossible standards to work with such as ASN.1
>> 
>> But from their perspective, it must have seemed fundamental. And HTML's verbosity
>> a heresy.
> 
> Wow, sorry, that part was quite ambiguous and I'm pretty sure you got me 
> very wrong.  It's not at all about optimization.  I'd say it's quite similar 
> to the Hungarian notation debate.  People who don't like it believe it's 
> useless to add the notations, since they can safely be considered implicit 
> 100% of the time, and they would then unnecessarily clutter the names. 
> (Ultimately, there's no answer to this debate, it's just a matter of taste.)
> 
> Just like them, I don't think it's necessary to explicitely indicate that a 
> WebID is an ID anywhere in the address referencing it, because clients 
> looking it up can safely assume what they are each and every time.  It also 
> comes down to taste, really, and there's no need to select one True Answer 
> here either.

We are not selecting one true answer. We are just starting with one that works
easily, where we don't need to invent another protocol. DNS and the Web is a huge
lookup service. What strikes me about some of the XRI proposal is they seem to
want to build another lookup layer on top of that lookup layer.

Now if it works, we can always integrate it as I say. 

> 
> In the same lines, most people don't feel necessary to use the www 
> subdomain[1], nor a "html" or "web" one.  It's even less common to see these 
> "notations" as subdirectories in the URL.  I'm not sure anyone can blame 
> them.  Using these even though they're not necessary at one time is the same 
> kind of anticipation as mine, one just needs to choose if one prefers to 
> solve the problem at the web server level or at the DNS level (which 
> effectively hides it entirely).  And we seem to both agree that at least 
> some anticipation is necessary, to avoid the a.org situation.

yes, I never really understood why people used www. There must be an interesting
psychological explanation there.

> 
> [1] http://no-www.org/ (disclaimer:  I do not support the.. radicalism 
> around the idea.)
> 
> Note that the a.org problem could be solved by leaving the WebIDs at the 
> bare domain level, and using a subdomain for their new activities, but that 
> still might not reflect their new priorities, it would just be another 
> workaround.  I really want to be able to solve the problem at its core:  by 
> not sharing a namespace between two different things (WebIDs hosting and any 
> other kind of HTTP hosting, say HTML pages).

If you follow this to its logical conclusion,  you'll end up with one url scheme per type of thing in existence.
car://, bus://, elephant://, washingmashing:// ....

Note that there are an infinite number of things in existence. 

That is why the W3C ended up recommending that people use http URLs, instead of inventing new schemes.

> 
> Essentially, the reason we need to push the problem down to the nameserver 
> *if* we want to get that transparency is that we cannot reserve a subdomain 
> name (that's obvious reasoning, I know).  Again, e-mails get their own entry 
> (we don't reserve the "mail" subdomain for SMTP servers), why wouldn't 
> WebIDs get one?  I think they're just that important.

You are just following the trajectory that the W3C went through. Initially they
were for developing all kinds of URI schemes, but soon they found out that there
is not that much value there. 

I can't find a good document right now that describes the whole history of this
- a very lengthy one with huge amounts of debate - but you can follow some of the
conclusions here

http://www.w3.org/TR/cooluris/

> We also get DNS fallbacks for free, which is not a luxury for this kind of 
> important things.

Anyway, the answer is simple. What we are doing is not incompatible
with the invention of new schemes. The semantic web is defined at the level of 
IRIS. 

In my opinion publishing a document at an apache http server is the simplest 
thing one can do, and so we start here. 


Henry


More information about the foaf-protocols mailing list