Re: Documenting implicit assumptions?

On Mon, 2011-01-31 at 19:59 +0000, Nathan wrote:
> subjectAltName tightly binds WebID to x509v3 certificates, x509v3 
> certificates with subjectAltName extensions are very hard to produce 
> with common libraries (unless you have a custom setup - e.g.
> openssl). 

Point and click certificate generation (on Linux and similar - requires
OpenSSL and Gambas):

http://buzzword.org.uk/2008/foaf_ssl/MakeWebIDCert/

> is subjectAltName IRI compatible?

HTTP isn't IRI compatible. Very few protocols are. But luckily that
doesn't matter because there is a mapping from IRIs to URIs - for every
valid IRI you can calculate an equivalent URI. In fact the only official
syntax definition for IRIs exclusively defines them in terms of a
mapping to URIs. (To paraphrase, "if a Unicode string processed this way
results in a valid URI, then what you started with was an IRI".)

> use of content negotiation on webid URI dereferencing limits usage to 
> HTTP.

Who says you need to conneg? A WebID profile with a single
representation is perfectly fine. This could be an "ftp:" URI, or even
(potentially) a "data:" URI. (Anyone played around with "data:" WebIDs
yet? I've been thinking about them for some time, but my OpenSSL
wizardry is not quite up to it yet.)

> use of RDF requires RDF support, use of XML requires XML support, use 
> of HTML+RDFa requires DOM and RDFa support.

Use of the network stack requires an Internet connection. So what?
Virtually any technology these days has a long list of dependencies. The
number of people programming on bare metal these days is not
statistically significant. libxml + librdf + libraptor comes in pretty
small compared to the amount of code needed to, say, playback video
found on the web.

> no required serialization makes interoperability nigh on impossible.

Yes, I agree here. My stance on it is that WebID profiles MUST be
available in at least one W3C Recommended serialisation of RDF. If
they're available in other formats too, and if consumers of the profiles
prefer the other formats, then more power to them.

Mandating that they be available in one blessed serialisation of RDF is
not a big ask. It's not like the W3C comes up with new ones every day -
there was the XML one back in the 1990s; and there was RDFa[1] in 2008.
That's two.

Yes, there will probably be a few more over the next few years, with the
RDFa working group expecting to publish an RDFa 1.1 Recommendation real
soon now, and the RDF working group expected to publish Turtle and some
sort of JSON serialisation.  But we'll still be able to count them on
one hand. If we think this is too uncontrolled we could stipulate that
the mandated list of serialisations for WebID is the list of W3C
Recommended RDF serialisations at the time of WebID's publication. So
serialisations recommended after WebID is published don't get on the
list.

____
1. One could argue that RDFa is not a single serialisation, but a family
of them. XHTML+RDFa and SVG+RDFa are already Recommendations, HTML+RDFa
is on the Rec track, and I'm personally trying to get Atom+RDFa
published as a working group note.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Tuesday, 1 February 2011 10:58:28 UTC