W3C home > Mailing lists > Public > public-webid@w3.org > November 2012

Re: #URIs and redirections

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 30 Nov 2012 07:42:06 -0500
Message-ID: <50B8A99E.2040804@openlinksw.com>
To: public-webid@w3.org
On 11/30/12 7:33 AM, Henry Story wrote:
>> >Yes, and in my world of software production and delivery, I don't look to waiting for Apple if the technology in question provides me with a workaround. That's my fundamental point.
> Ok, so can we remove those finger-pointing-at-apple examples?

Why, I don't know how you've triangulated that conclusion. They stay 
because they showcase a user experience problem with hash style of HTTP 
URI for Mac OS X platform users.

> Or is there some use case you
> absolutely need the user to click on the WebID in the key chain for?

Er.. open up the certificate used to sign this email, go to the SAN 
slot, click on the URI serving as a WebID and see what happens. Beyond 
that, working with Keychain is natural end-user interaction once working 
with WebID. Same thing applies to testing and implementing WebID.

> And what has that got
> to do with WebID spec we are writing.


It has everything to do with making the case for interoperability in a 
Wiki document that supposed to capture arguments.

> This is not about WebID-TLS right?

Did I say it was?

As far as I recall, this has everything to do with the subject of this 
mail and the section in the Wiki about pros and cons of hash HTTP URIs.

> And even in WebID-TLS
> clicking on the URI in the keychain is part of what use case?

See my comments above.



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Friday, 30 November 2012 12:42:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:46 UTC