[Standards] Domain & JID Aliasing

[Tim Brennan]

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,

--tim



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