[Standards] Domain & JID Aliasing
tim at zimbra.com
Thu Feb 1 20:07:33 UTC 2007
I might be missing something, but it isn't clear to me how to solve this "within the server." I'm playing catchup a bit on the XMPP game, so there could very well be some spec that addressed this.
As an example, I have two email addresses: "tim at zimbra.com" and "tim.brennan at zimbra.com" -- and just like with email, I really expect people on to be able to add me as a buddy using both addresses, even people connecting from other services. My "real" account is tim at zimbra.com.
Imagine I get a subscribe request from foo at jabber.org for tim.brennan at zimbra.com? I want to accept this (send a subscribed response). Do I:
-- return a subscribed response with the from="tim at zimbra.com"? Is the client expected to handle that seamlessly (the from of the subscribed packet doesn't match the to of the request?). This would seem to conflict with rfc, since the external client (or the server on their behalf) has already done an iq:set with the jid=tim.brennan at ....and spec says to ignore the subscribed message if the contact isn't already in your roster with the correct state (which it won't be in this case)
-- return a subscribed response with the from="tim.brennan at zimbra.com", and now for everyone I talk to, track the address they "think" I'm using, and always set my From: appropriately whenever I send that client a message.
I suspect I'm missing something here: please enlighten me.
----- "Rachel Blackman" <rcb at ceruleanstudios.com> wrote:
> On Feb 1, 2007, at 11:15 AM, Chris Mullins wrote:
> > 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 would argue that most of these are entirely up to the server to
> determine; the most you could XEP of it would be a "best practices"
> guideline document. Managing what the outgoing address is,
> determining the 'master' account to send from, and so on, are all
> really something the server can do without needing input from the
> client or remote systems.
> They're useful, no question, but they're server-internal
> > 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.
> THIS is the one exception. This, if there was a way to do it
> securely, would be WONDERFUL. Not so much as a way to handle aliases
> as, rather, a way to say "This account is outdated, I'm moving
> addresses." Sort of like a postal change-of-address form. There's
> obviously potential for abuse (hijacking of contacts) if it's not
> implemented properly, but I think this is the one bit really worth
> XEP'ing separately. :)
> Rachel Blackman <rcb at ceruleanstudios.com>
> Trillian Messenger - http://www.trillian.cc/
More information about the Standards