Links, rels, and profiles
Caveat: I’m not at all sure I know what I’m talking about here. If you do, feel free (as always) to set me straight.
HTML defines a link element to express metadata about the relationship between the current document and other documents. The rel attribute expresses what sort of relationship the current document has to the linked document. Its value is a link type.
That’s where the concrete aspects of the HTML rec stop, and the handwaving begins. The link types section lists some standard types, things you’ve probably seen like alternate, prev and next, and then says that:
Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.
Combine that “should” (note the lower-case: this is not a spec-language SHOULD, where you either do it or know why and suffer the consequences) with the handwaving about the meaning of rel that came before:
User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar.
and you have an unspecified, wide open field that’s ripe for me to muck about with :)
If you choose to follow a lower-case should, the profile attribute is mentioned twice: when it’s the profile attribute it’s a list of one or more URIs, separated by whitespace, but when it’s a metadata profile it’s just one, which user agents may either recognize as a known URI, or dereference (which means assume the URI is a URL, and go grab whatever the server there feels like providing) and er, um, do some stuff with. I can just feel the @@FIXME! that there must not have been time enough to deal with. At any rate, although I can’t find it to point at, that’s taken to mean that there’s some magic meaning to the first URI in a profile attribute. You have been warned. Also, because “the same profile applies to all META and LINK elements in the document head,” by defining one you could wind up confusing some hypothetical thing which treats a profile URI (presumably the first, magic, one) as a sort of namespace, and decides that since you have one, your otherwise-well-known meta and link attributes don’t mean what they usually do. You have been warned: here there be probably imaginary dragons.
So, why am I going on about this? If you want to have your posted PGP public key autodiscovered by weblogs that accept signed comments (my guess would be that Jacques is going to get to autodiscovery first), you need a <link rel=”pgpkey” type=”application/pgp-keys” href=”…”>, and for that you should have a <head profile=”…”>, and for that I’ve got http://purl.org/net/pgpkey/ (not linked, because there’s nothing to speak of there, and I can’t quite imagine what there will or could be there, so the search engines can mind their own business for now). Use it, enjoy it, if you’ve got a document you would like it to point to let me know. (And note that you really do want to be delivering your public key with that MIME-type, so that people can automatically pass it off from their browser to their PGP application.)
Umh, well you could define a ”helper-app” for that MIME-type.
Me, I’ve chosen GPGKeys.app (on MacOSX) as the helper application, and clicking on such a link automatically imports the associated key to my keychain.
MIME-types are your friends.
Oh, you mean behave like I’ve got a tiny bit of sense, not like I’ve never used a browser before? Heh. I’ve got such a mental block about application/foo from all the times that someone has said ”my RSS feed is broken” and I’ve had to save it/open it just to see why, that it never occurred to me that this was an application where I wanted to use, well, an application. And of course, PGP/Win is delighted to accept such a thing.
Now that you’ve (re)discovered the joys of MIME-types, you probably want to serve your public key that way.
Just a thought …
I am (or at least I think I am - I must be, that’s why I know it works with PGP/Win) - looks like for Firefox at least, a change in mime-type isn’t something that the cache notices. I just cleared my cache as the easiest way around it.
http://bitworking.org/news/Atom_Auto_Sub_How_To
Of course, since it’s the right thing to do and the way the web has worked for over a decade now, it will never catch on.
But it’s not a new MIME-type.
RFC 3156 defines what a resource of MIME-type application/pgp-keys is supposed to contain:
And, as Phil and I have noted, applications aready know what to do with it.
You know, I never quite grasped why I couldn’t just tell my aggregator to subscribe to a thing of type application/hooha - it’s because all it gets is a temp file, not the URI! D’oh. (Not that it would help me in my usual case, since aggregators tend not to have a ”view unaltered source” feature, but I know I’m an edge case frequently needing to see other people’s RSS/Atom source.)
But as Jacques says, in the case of PGP keys, it works a treat, far better than what I was doing (view raw key, tray icon, current window, ”Decrypt and verify” which in the case of a key means ”Add”).
Correct, but only because I’m one of the few people with a working copy of
Crypt::OpenPGPon my webserver. Srijith actually did most of the coding.For what it’s worth, it looks like the XFN people have put some effort into defining a simple XHTML metadata profile format. XMDP, they call it.
Coverage of PGP commenting idea
Some good coverage and discussion on the idea of PGP signing comment posts: PGP-Signed Comments - A good introduction by Jacuqes Distler on why comments should be signed. Notes…