[foaf-protocols] WebID - mandated syntax or market solution? was WebID Incubator Charter draft

Jiří Procházka ojirio at gmail.com
Sat Dec 18 13:27:20 CET 2010


On 12/18/2010 01:10 PM, Henry Story wrote:
> 
> On 18 Dec 2010, at 13:00, Jiří Procházka wrote:
> 
>> On 12/18/2010 10:10 AM, Henry Story wrote:
>>>
>>> On 18 Dec 2010, at 00:53, Jiří Procházka wrote:
>>>
>>>>
>>>> Do you agree the "WebID" name could be used, besides as the protocol
>>>> name, for something like a certificate (think
>>>> http://validator.w3.org/docs/help.html#icon) which guarantees to an end
>>>> user the software/service is usable in some way? (when it is not offline
>>>> of course)
>>>
>>> It won't happen quite like that. It will probably be integrated into the
>>> browsers themselves. See some of the issues here
>>> http://code.google.com/p/chromium/issues/detail?id=29784
>>
>> The problem here is you see only the browser side of things, while I
>> from time to time feel the need to remind, that WebID is great tech
>> usable not only from browsers, but for wide range of applications, doing
>> also server-server authentication without any direct user input.
> 
> Agree. But I don't see why you need to remind me of that. If you look
> at the WebID XG it says just that
> http://bblfish.net/tmp/2010/12/15/webid-charter-draft.html
> "Of course it is not limited to browser based authentication: peer to peer server authentication will work just as well."
> 
>> This is
>> why such applications would find such "badge" useful, and why it should
>> really mean it guarantees something.
> 
> I don't quite see how a badge is going to be useful for robots though. Who is going 
> to "see" the badge here. Presumably robots will get a request for a client side certificate
> and send one over.

When user installs the software he should expect it to work with all
WebIDs in basic functionality, regardless how many additional syntaxes
it doesn't understand, sacrificing potential performance gains and
additional features.

>> You don't want your automated
>> backup tool to fail, except when it looses connectivity. Maybe browsers
>> will have no problem being updated with latest WebID syntax
>> developments, but tools running on server or routers certainly will,
>> also they often need to be as small as possible. These use cases are the
>> edge on other similar technologies, so please consider them.
> 
> You have developed a good practical reduction ad absurdum. If too many 
> syntaxes develop with no way of knowing their semantics, then clearly it
> won't work. Therefore one should not develop syntaxes with no clear semantics.

I haven't said that. That is wrong because there is a different option
which I advocate - have 1 simple syntax with simple semantics defined in
a spec, accounting for basic functionality, while welcoming conneg of
different syntaxes.

> That is why we follow the procedure of the IETF: loose consensus and working 
> code. Currently our working code prooves this is not a problem. Let's see
> how things progress...
> 
> Henry
> 
>>
>> Best,
>> Jiri
>>
>>>> Do you agree there are higher demands on reliability of protocols then
>>>> anything else?
>>>
>>> In some ways it is not sure that this is a protocol either, btw. 
>>> I don't exactly know what WebID is. The protocol is already 
>>> defined, as TLS.  HTTP is a protcol and is already defined.
>>> Perhaps what we are defining is a proof procedure, in which case
>>> it is not surprising that we are at the level of logic.
>>> This is something the XG should investigate.
>>>
>>>> Do you think if for example with DNS protocol while
>>>> answering your query each participating nameserver could return "syntax
>>>> not understood" error returning it to you as final answer would be good?
>>>
>>> Putting a public key in the DNS is a very different issue. DNS
>>> does not have content negotiation.
>>>
>>>> Please name some protocols which do this (syntax conneg - they are just
>>>> defined as logic - the model, like you wish).
>>>
>>> It's not because something is new that it cannot be done.
>>>
>>> But anyway, there is one: the web. The Web allows you to return different
>>> representations for the same resource. The same resource can return 
>>> jpeg, gif,... It was designed like that for precisely the reason of
>>> allowing flexibility and growth.
>>>
>>> In any case all this is moot. We interoperable implementations 
>>> in every programming language that work with at least 2 mime types. RDF/XML 
>>> and RDFa, and some even with turtle. 
>>>
>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>
> 
> Social Web Architect
> http://bblfish.net/
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101218/fee154b4/attachment.pgp 


More information about the foaf-protocols mailing list