(picture)

April 20, 2003

Presence, revisited

A couple of days after writing up my "presence in RSS", I still haven't written any software, although I'm sure a Groove-based backend would be quite straightforward, and that various other backends would be really easy. Still thinking.

Some interesting comments, a couple of which missed my mark. I want RSS to have "presence without identity".

On the RSS-DEV list, Roy Silvernail points to RFC2779 (IM/presence protocol requirements) and would like to see attribute-type data. Thanks - I hadn't read the RFC and it's relevant, even if not particularly specific. The XMPP <presence> element is more directly important. I don't actually like the enumeration choices in the XMPP <show> tag (schema here, page 69); they're too application-specific, and at the same time not specific enough. My "icon" element can map the "show" semantic. For other attributes, the status field is deliberately vague. Vague enough?

Mike Amundsen suggests including the vCard by reference. In a related vein, Phil Hart posted some great comments:

Ideally, an "RSS Client" (for want of a better expression) should be presence-enabled, so that all Identity/Presence/Availability information can be retrieved from the corresponding "presence server" at the very moment the document is retrieved and read.
...which is exactly what I'm hoping for. But he also notes
by the simple expedient of including only the Identity of the document creator, the rest of the elements can be obtained from the presence server.
which is very true, but I deliberately tried to avoid. My proposal has no "identity" in it, and that's intentional. For several reasons, including plain laziness: identitiy unification is a really important project, but it's a big one, and I'm not going to go there. But you can do presence without identity, by building a really simple presence-polling mechanism which is agnostic about your claims to identity or the various identity-resolution methods.

So, rather than including in my RSS feed some information which says "I am xxxx", which indirects to "you can query presence server yyy for my status using protocol zzz", it just says: "you can query this webserver for my status using HTTP GET, and expect a response in this XML format".

The RSS document could include the actual presence information, and/or (more usefully, I think) a pointer to the presence source.

Actually this proposal does ignore one of the more difficult parts of presence, which is: "who wants to know?". I show different online presence information to different people. But implicitly, the "who's asking" is "John Doe", and you'll get my public presence status.