[Standards] Domain & JID Aliasing
m at tthias.eu
Thu Feb 1 19:36:56 UTC 2007
(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.
(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
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...
Size: 4263 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards