[Standards] Domain & JID Aliasing

[Rachel Blackman]

> 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/