Re: #URIs and redirections

On 29 Nov 2012, at 22:08, Nathan <nathan@webr3.org> wrote:

> Kingsley Idehen wrote:
>> On 11/29/12 3:42 PM, Henry Story wrote:
>>> On 29 Nov 2012, at 19:36, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>> 
>>>> On 11/28/12 3:25 PM, Ted Thibodeau Jr wrote:
>>>>> But the following, which Henry initially seemed to be
>>>>> suggesting as better (though his conclusion seems otherwise)?
>>>>> 
>>>>>>> -http://xmlns.com/foaf/0.1/knows#•
>>>>>>> -http://xmlns.com/foaf/0.1/mbox#•
>>>>>>> -http://xmlns.com/foaf/0.1/Person#•
>>>>>>> -http://xmlns.com/foaf/0.1/Agent#•
>>>>> These URIs don't look right in Mail.app.
>>>>> 
>>>>> The URI highlighting stops at the last solidus ("/"), so
>>>>> they all look like links to the same page --
>>>>> <http://xmlns.com/foaf/0.1/>  -- and that is where clicking
>>>>> them takes me.
>>>>> 
>>>>> (I am then redirected to the same<http://xmlns.com/foaf/spec/>  as above -- but again, if the redirections were handled as
>>>>> I suggest above, this end result would be very wrong.)
>>>>> 
>>>>> Be seeing you,
>>>>> 
>>>>> Ted
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> A: Yes.http://www.guckes.net/faq/attribution.html
>>>>> | Q: Are you sure?
>>>>> | | A: Because it reverses the logical flow of conversation.
>>>>> | | | Q: Why is top posting frowned upon?
>>>>> 
>>>>> Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
>>>>> Senior Support & Evangelism  //mailto:tthibodeau@openlinksw.com
>>>>>                              //http://twitter.com/TallTed
>>>>> OpenLink Software, Inc.      //http://www.openlinksw.com/
>>>>>          10 Burlington Mall Road, Suite 265, Burlington MA 01803
>>>>>      Weblog   --http://www.openlinksw.com/blogs/
>>>>>      LinkedIn --http://www.linkedin.com/company/openlink-software/
>>>>>      Twitter  --http://twitter.com/OpenLink
>>>>>      Google+  --http://plus.google.com/100570109519069333827/
>>>>>      Facebook --http://www.facebook.com/OpenLinkSoftware
>>>>> Universal Data Acchess, Integration, and Management Technology Providers
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> To cut a long story short, I've generated a certificate and produced a screenshot [1] from my keychain instance. I have a hash URI denoting the certificate issuer's alternative name (IAN) and a hashless URI denoting the certificate subject's alternative name (SAN). Clicking on the IAN leads to a 404 since the # was transformed into %23,  a decision out of my hands as the end-user i.e., a bug in keychain.
>>>> 
>>>> As you know, we (historically) have little interest is going around asking vendors to fix bugs in their products, on their on schedules etc.. It's utterly impractical and a complete waste of time.
>>>> 
>>>> Links:
>>>> 
>>>> 1. https://dl.dropbox.com/u/11096946/WebID/keychain-http-hash-versus-slash-uri-issue-interop-showcase.png -- maybe a link for the relevant section of the for and against Wiki, for future reference.
>>> I can't remember if I put a bug report to apple for that. It's still worth doing it I think.
>>> 
>>> In any case those types of bugs are not relevant to our hash uri issue. So I'll remove that
>>> from our hash wiki later.
>>>   http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash
>> I am running out of patience with these kinds of comments from you.
>> You have an argument you don't like, then feel you have the unilateral right to remove it from the debate? Why open up a Wiki at all?

The wiki is there to help us see the points on a particular issue. I have removed points that had no bearing on the issue at hand. In the future I'll point out removals I make to the list. 

Debates have to come to a conclusion at some point, and for that there have to be some processes on what is in and what is out. I won't remove things without justification. We will also have time to discuss this during the teleconf.

> 
> +1 I'm afraid, if fragments aren't supported everywhere we need them to be, then that's an issue we need to consider - I know it's been mentioned before in other contexts and with other tooling by harry halpin.

In the case of the Apple keychain, there is a well known way to get that fixed: send them a bug report.
The reason it has not been fixed yet, is perhaps that you have not, and secondly that very very very few poepl e - including the Apple testers have thought of clicking on that link I presume. 

> 
> I believe it would be in everybody's best interests to keep it in there and discuss this thing with eyes wide open.
> 
> Best,
> 
> Nathan
> 

Social Web Architect
http://bblfish.net/