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.)

10 Comments

Comment by Jacques Distler #
2004-02-29 23:53:06

And if you’ve got thoughts about the relative merits of using type=”application/pgp-keys”, with or without actually delivering the key as that type, which will be the same annoying thing as delivering RSS as application/foo, forcing you to save it and open it (in a text editor, mind you) just to see it, I’d be interested in hearing about that, too.

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.

Comment by Phil Ringnalda #
2004-03-01 00:35:29

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.

Comment by Jacques Distler #
2004-03-01 06:29:02

Now that you’ve (re)discovered the joys of MIME-types, you probably want to serve your public key that way.

Just a thought …

Comment by Phil Ringnalda #
2004-03-01 09:19:38

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.

 
 
 
 
Comment by Mark #
2004-03-01 03:59:30

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.

Comment by Jacques Distler #
2004-03-01 06:20:02

But it’s not a new MIME-type.

RFC 3156 defines what a resource of MIME-type application/pgp-keys is supposed to contain:

7.  Distribution of OpenPGP public keys
Content-Type: application/pgp-keys
Required parameters: none
Optional parameters: none
A MIME body part of the content type "application/pgp-keys" contains
ASCII-armored transferable Public Key Packets as defined in [RFC 2440],
section 10.1.

And, as Phil and I have noted, applications aready know what to do with it.

 
Comment by Phil Ringnalda #
2004-03-01 09:17:04

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”).

 
 
Comment by Jacques Distler #
2004-03-02 23:17:07

[M]y guess would be that Jacques is going to get to autodiscovery first.

Correct, but only because I’m one of the few people with a working copy of Crypt::OpenPGP on my webserver. Srijith actually did most of the coding.

 
Comment by jacob #
2004-03-03 12:36:49

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.

 
2004-03-05 18:49:45

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…

 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <del datetime="" cite=""> <dd> <dl> <dt> <em> <i> <ins datetime="" cite=""> <kbd> <li> <ol> <p> <pre> <q cite=""> <samp> <strong> <sub> <sup> <ul> in your comment.