[rdfweb-dev] IM URIs

Bill Kearney wkearney99 at hotmail.com
Sat Aug 2 10:20:38 UTC 2003

> MSN is via Passport which is always an email address.

Actually, no, a Microsoft messenger account /may/ be an e-mail address.

The format used for MSN's messenger is the same format used by Exchange's
instant messenger.  To make matters more interesting is the latter's support for
MX-record-like functionality for people.

As in,
    Joe User has an e-mail address of joe at example.com
    The DNS has an MX record that handles it via the host gateway.example.com
    Mail software thus understands that mail to joe should actually get
delivered via that box.

With the MS IM protocol the same thing is possible
    Joe User has an IM address of joe at example.com
    The DNS has a record that handles it via the host im.example.com
    IM can software thus understand that joe's IM messages are handled via that

THIS is why I've complained that using service-specific structures for handling
IM accounts is an evolutionary dead-end.  When I have a person's IM info and
want to contact them I have to understand what protocol they're using.  That,
however, may not be enough.  I have to then be able to ascertain what path to
take to actually reach them.  For IRC there's just one network.  For AIM and Y!
this is also true.  For IRC there are thousands.  For MSN there's one.  But for
services that use the same protocol as MSN there can be more than one.  This
begs the question of if there /happened/ to appear more than one way to use an
ICQ, AIM or Y! service would it have been a /bad idea/ to have used a model that
didn't support that extensibility?

To complicate this even further an account that uses the public MSN service is
indeed based on an e-mail address OF YOUR OWN CHOOSING.  This instead of your
software doing an MX-like lookup (joe at example.com begets an MX search on
example.com resulting in im.example.com being resolved).  MSN accounts are via
the MSN service regardless of what domain the account itself uses.  BUT the
protocol being used is exactly the same as that being used for privately hostabl
e solutions.  The fortunate thing here is MS has published all this and the
various tools are out and working today.

What I'm *really* sensing here is we need some reliable universal way to swap
data publicly that's been hashed or otherwise obfuscated that allows our
software to untangle all this.  As in, use a group resource of some kind that
understands the private hashes and helps act as an intermediary between you and
the resource to with you want to connect.  A server that, when you give it a
hash and it authenticates you, can either tell you the real address or sends
some sort of notification to the intended recipient that expresses your

The question then becomes is how to do we effectively markup that we're using
hashed values and those values can be resolved via a 'known' mechanism of some

-Bill Kearney

More information about the foaf-dev mailing list