[Standards] Domain & JID Aliasing
tim at zimbra.com
Thu Feb 1 20:41:41 UTC 2007
OK, so this is additional persistent data that has to be stored for every entry on my Roster -- basically a "tojid" for every roster entry -- except updated/owned by the server itself (since the server is the one that writes the "from")...
This is probably analogous to IP NAT -- it will work as long as there is nowhere else in the protocol where we encode our own address, aside from the rewritable "from" header.
Not incredibly pretty, but doable. Thanks,
----- "Rachel Blackman" <rcb at ceruleanstudios.com> wrote:
> > 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)
> > OR
> > -- 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.
> My theory is that, as I said, this is up to the server.
> Basically, let's say I (sparks at jabber.org) add a subscription request
> to tim.brennan at zimbra.com. Your server knows that I've made this
> request -- it has to, after all -- and so when you send an
> 'approved,' it would be up to the server to send back an approval
> that matches the address I subscribed to. Similarly, since the
> server has your outgoing subscriptions (again, it has to, to know who
> to send your presence data to!), AND is responsible for sending on
> the message stanzas, the server has all the information necessary to
> know if a <message/> should have a from of 'tim at zimbra.com' or
> 'tim.brennan at zimbra.com' for a given end-point.
> It's already up to the server to forward the subscription approval
> back, after all. And servers already have to track login and JID
> separately -- some servers have you authenticate against an LDAP
> login, but show your JID as something entirely different. So the
> server has the information needed to alias a user to multiple JIDs.
> Further, all the re-mapping between alias and login happens at either
> the origin (for outgoing) or end-point (for incoming) server; there
> doesn't need to be a communication standard for this, because it's
> entirely internal to a given server.
> 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. Which seems less likely
> to lead to any sort of adoption.
> That's my take, anyway. :)
> Rachel Blackman <rcb at ceruleanstudios.com>
> Trillian Messenger - http://www.trillian.cc/
More information about the Standards