RE: neither FCNS nor FOAFSSL can read a new foaf card (hosted in Azure). RDFa validators at W3C and RDFachecker say its fine...

The history is obviously convoluted, as usual with tech. I know 2 facts: Kingsley as an experienced person with semweb in enterprise theatres implies that  linked data clients are proper for putting fragments on the wire (and Henry's server is proper for NOT implementing the SHOULD reject rules in the RFC). I could not make a trivial RDFa page on a windows website (after 15 years of doing the same thing...) working with both cases Jurgen suggested (implying I need to act my basic act together, rather than solve an insoluble-for-me windows problem) Now, Im giving folks a break. my normal  CISO/CIO management position in this situation is... I go away for 5 more years (till microsoft makes the platform that fits, us, as a windows shop, and its 3+ years old, since we only adopt a version out of date). We pay Microsoft to make and support stuff that fits our interests (working as we do in the commodity world, needing low error rates and very HIGH stability). I also expect them to meet internet standards with hardware and OS solutions (in which IS status is a longterm goal track, in which HTTP still has not made "internet standard"). Obviousy, HTTP has good reasons for not being an internet standard yet: it aint stable, and hardware-ready. I wont be the same in 10 years time...(yet). I give the break as I see a community on the trasition from R&D to mass commercialization, and that needs some support. it nt proiper that one of the most late-adopters (realty) is a driving use case, but I have not see any others...come to the fore as NEEDING a distributed, de-centralized identity management solution. Everyone else is perfectly happy with hub-and-spoke.      > Date: Thu, 29 Dec 2011 11:46:56 -0500
> From: kidehen@openlinksw.com
> To: Mo.McRoberts@bbc.co.uk
> CC: home_pw@msn.com; public-xg-webid@w3.org
> Subject: Re: neither FCNS nor FOAFSSL can read a new foaf card (hosted in           Azure). RDFa validators at W3C and RDFachecker say its fine...
> 
> On 12/29/11 4:04 AM, Mo McRoberts wrote:
> > hold on a second.
> >
> > is somebody saying fragment identifiers SHOULD be included in a request somewhere?
> >
> > HTTP/1.0 and HTTP/1.1 very explicitly say otherwise (and as far as I can tell, HTTPbis WG outputs haven't changed that), and last I checked nothing about linked data changes that? part of the point of linked data is that it doesn't require anything "special"
> >
> > AFAICT, a server is perfectly within its rights to return a 4xx response to request containing a fragment, and that includes a 400 (Bad Request), given that an unescaped '#' isn't permitted in a Request-URI.
> 
> Its a loooong story.
> 
> Fragment Identifiers not going of the wire arose from a typo (I hear) a 
> long time ago during spec development. It lead to the common (and 
> eventually accepted) practice of not sending Fragment Identifiers over 
> the wire, but Microsoft didn't initially adopt this i.e., they stuck to 
> pre typo definition.
> 
> Its also one of the reasons why DBpedia adopted slash rather than hash 
> URIs since the project's goal was about: just working, in a browser 
> agnostic way.
> 
> >
> > if there's a spec somewhere which says otherwise, I'd love to know about it (not least so I can tweak my own servers), but the current httpbis-p1-messaging draft even goes as far as to say:
> >
> > "Note: Fragments ([RFC3986], Section 3.5) are not part of the request-target and thus will not be transmitted in an HTTP request."
> >
> > To the best of my knowledge this is a point of clarification, rather than a change in specification, it's just that some folk hadn't read the URI ABNF properly.
> 
> It's a mess. But for now, I think Microsoft has tweaked its HTTP 
> products (browers, servers, and proxies) thereby reducing perpetuation 
> of this problem. They were the last hold out.
> 
> I might dig up some reference links if I get some time.
> 
> Kingsley
> >
> > M.
> >
> 
> 
> -- 
> 
> Regards,
> 
> 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
> 
> 
> 
> 
> 
>