[Standards] Domain & JID Aliasing

Rachel Blackman rcb at ceruleanstudios.com
Thu Feb 1 20:55:48 UTC 2007

> OK, so this is additional persistent data that has to be stored for  
> every entry on my Roster -- basically a "tojid" for every roster  
> entry -- except updated/owned by the server itself (since the  
> server is the one that writes the "from")...
> This is probably analogous to IP NAT -- it will work as long as  
> there is nowhere else in the protocol where we encode our own  
> address, aside from the rewritable "from" header.
> Not incredibly pretty, but doable.  Thanks,

No, it isn't terribly pretty, I grant.  Basically, it's one more bit  
of data that has to be maintained per-subscription.

However, relying on client implementation isn't a great idea either.   
If a client hasn't updated to add support for some new 'aliasing'  
XEP, what happens if they try to subscribe to tim.brennan at zimba.com,  
and get back an approval from 'tim at zimba.com' with some unsupported  
marker, like:

<presence from='tim at zimba.com' id='c08' type='subscribed'><alias  
xmlns='http://jabber.org/protocol/alias'>tim.brennan at zimba.com</ 

Sure, a client that knows the 'alias' protocol can go, "oh, okay,  
that subscription request I gave for tim.brennan actually came back  
as tim, no worries."  But a client that doesn't know the protocol  
will go, "who the hell is tim at zimba.com?  I never made a subscription  
to that." and ignore it.  Moreover, a /server/ that doesn't know the  
alias protocol could keep marking that as an unapproved subscription  
in the roster, leading to the request being sent repeatedly, etc.

Let's say I block people not on my list... and that  
'tim.brennan at zimba.com' IS on my contact list.  So I expect messages  
from tim.brennan to get through.  But then I get an incoming message  
from 'tim at zimba.com' -- which isn't on my contact list -- so my  
client (as it was told) ignores that as someone not on my contact list.

I know it's uglier to support on servers, but I think you'll have a  
cleaner experience for end-users if it's handled on the server side,  
internal to any server that supports aliases.  After all, any XMPP- 
based system to contact a given JID has to go through the server; <iq/ 
 > and <message/> both will go through the zimba.com server to reach  
you, so there's no reason zimba.com wouldn't forward an <iq/> for  
'tim.brennan at zimba.com' or one to 'tim at zimba.com' to your system  
directly, after all.  Or translate the 'from' on the outgoing packet,  
which also still has to go through the server.

Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/

More information about the Standards mailing list