[Standards] Domain & JID Aliasing

Mridul mridul at sun.com
Fri Feb 2 02:51:31 UTC 2007

Chris Mullins wrote:
> Sparks Wrote:
>> And really, the server is the /only/ thing that has all the  
>> information necessary; for clients to handle this, you'd need to  
>> define several new XEPs to map aliases to remote contacts, and then  
>> rely on clients actually supporting those.  
> We're in complete agreement here. I'm just trying to mentally work out
> what it'll take for this to "just work". I don't want users having to
> know about aliasing, I don't want client developers to need to care - I
> want it to just work seamlessly.
>> Which seems less likely  
>> to lead to any sort of adoption.
> I'm actually not that worried about adoption, as most of the people who
> will want this are more of the EIM flavor, which tend to be closed
> shops. My overriding concern is end-user transparency and simplicity. 
> I think overall the rules will break down to:
> - server needs to track the alias any particular remote address is
> subscribed to.
> - anytime a message/presence/iq is sent to that contact, the server
> stamps the right "aliased from address" onto the packet. 
> - anytime a message/iq/presence comes in to an aliased address, the "to"
> address is swapped out from with the "real" account name.
> - S2S connections would be accepted on either the real domain or an
> aliased domain (coversant.net / coversant.com).
> - Outgoing s2s connections would need to be made from the aliased domain
> that matches the "from" address of the packet being sent.
> ... and the one that's bound to cause controversy: 
> - The server MUST deny login to an alias name (either JID or domain). I
> could "only" log in as "chris.mullins at coversant.com". This makes the
> above rules much more enforceable. The "deny" could be done with an XMPP
> Redirect to the right alias domain & jid though. 
> --
> Chris Mullins

Hi Chris,

  The roster could be extended to contain the alias the contact has 
added the user as.
This should be the only information required by the hosting server.
Whenever any stanza is outbound from user, server will check roster and 
modify 'from' in case there is an alias.
For any inbound stanza, it is anyway simple : you will just map to the 
primary alias of the user.

Only drawback here is you need to subscribe before you can communicate : 
which sort of breaks a bunch of things.


More information about the Standards mailing list