[Standards] Domain & JID Aliasing

Matthias Wimmer m at tthias.eu
Thu Feb 1 19:36:56 UTC 2007

Hi Chris!

(You posted this in a thread about SASL EXTERNAL. Any reason or just by 

Chris Mullins schrieb:
> Many email systems provide aliasing both of domain names, and user accounts. 
> For example, via email, I can be reached at:
> cmullins at coversant.net
> cmullins at coversant.com
> chris.mullins at coversant.net
> chris.mullins at coversant.com
> We're getting to the point in XMPP land where we need this same capability. For example, I currently give out "cmullins at coversant.net" as my XMPP address, but would prefer to give out "cmullins at coversant.com". I don't want two separate accounts, so domain aliasing is the obvious answer.

Yes, I also have to agree, that I already got often asked for that 
feature by users.

> This brings up a few problems though:
> 1 - If a user subscribes to my presence as "cmullins at coversant.net", and I send him a message, what "From" address do I stamp on it? Do I use the original address that he subscribed to? It seems like I should. This means a server would need to keep track of the "alias" that was subscribed to, so that outgoing packets to that endpoint can have the proper from address.

I see problems with this because of addresses at other places than the 
stanza addresses. To be able to update all JIDs that are contained 
inside a stanza, the server would have to know all protocols a client 
would use to know which has to be changed.

> 3 - Would we want to tickle the subscription management flow to specify a "change address" field? That is, perhaps I'm subscribed to "stpeter at jabber.org" as "cmullins at coversanet.net". It would be nice to send "<change newAddress='chrismullins at coversant.com'/> or a packet to that affect. 

Yes, changing the account addres is interesting as well.

> 4 - should there be a way for a client to "see" it's aliases? Right now, my email client can't do that (Outlook 2007), and it seems un-needed for an XMPP client as well.

In E-Mail we have only messages. They certainly do not know all 
addresses. With <iq/s> I think the client would have to know all its 
aliases. Well not only the aliases, but also which contact is expecting 
to see the user with which aliasas.

Maybe it would be easier to not implement full aliasing, but use 
redirecting if an alias is used?

E.g. someone sends a subscription request to cmullins at coversant.net and 
gets back a redirect to cmullins at coversant.com. So we would limit the 
aliases to be pure redirecters and a user would still have only one real 

And we would have to define a second (new) protocol to change the 
address of a user. (E.g. if the main domain of your company changes - or 
for private accounts if you are changing the server you are using.) So 
that you could update all subscriptions for cmullins at coversant.com to be 
for cmullins at newcompanyname.com.

Tot kijk

(Sorry for broken link-breaks in the quoted parts, but they have already 
been present in the original mail, as format=flowed is missing in the 
original content-type.)

Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4263 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070201/e852c70d/attachment.bin>

More information about the Standards mailing list