RE: FOAF SSL success, form windows RDFa (via linked data)

few more updates.

 

First, an example of a (http) proxy-profile URI that proxying an (https) original profile works nicely. I made a cert with 2 SAN URIs (http) proxy URI wrapping an http original URI, and same (http) proxy stem wrapping the related https original URI.

 

I will now expose multiple CNAMES for the same resource, and multiple sets of secure name authority metadata (known as cert chains), and see what happens. I will be using equivalencies to ensure all are deemed the same.

 

Second, an example run of OpenLink CORRECTLY rejects an (non proxied) https profile (in windows blob storage) that, however, FCNS accepts. The underlying issue is http/hjttps namespace confusion. The spec is missing specificity.

 

Third. the OpenLink accepts the http (not https) version of the windows blob storage profile (and URL). FCNS comes to the complementary decision. I suspect FCNS is correct. I suspect OpenLink is using cached copy, of data with a mod that has since changed.

 

Finally, I made a long uri into a tiny URI, with nice QR code. Is the point that this COULD be pointing at my proxy URI (and the cRUI could be going in the cert SAN URI?) If so, this bvegs the redirects question I posed a while ago. Are validators supposed to following redirects (or not).

Received on Monday, 9 January 2012 23:21:11 UTC