[Standards] Domain & JID Aliasing

Chris Mullins chris.mullins at coversant.net
Thu Feb 1 20:57:54 UTC 2007


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





More information about the Standards mailing list