Bug 17324

Aliasing is this interface. The implementation of Aliasing should mangle the SIP address in the ways you suggest, if appropriate, whenever it is used as a fallback.

Gabble's implementation of Aliasing has the JID as the final fallback, but it could equally well use (for instance) just the part before the "@".

IMO, telepathy-sofiasip should strip off "sip:" or "sips:" or "tel:", and any "?query=misc", from the SIP address when returning it as a fallback alias, so it would just look like "mikhail@example.com" or "+441223362967" (of course, ideally for tel: URIs it would also insert some dashes - but the conventional way to space out phone numbers is country-specific, so it might well be considered too hard to implement this).

In MSN with Yahoo interop (Butterfly), the handles currently look like foo@passport.com#1 for MSN users and foo@yahoo.com#42 (or something) for Y! users, but the fallback alias should be "foo@passport.com" or "foo@yahoo.com" (I don't know whether this is in fact true).

What about the case when you don't want to mingle the user alias with address representation? E.g. the UI displays the alias name which might have been set by the remote party, but as a caveat against fraud, it can also display the address, which supposedly has better authenticity guarantees (not the case with basic SIP, admittedly).

Splitting user-assigned aliases and nicknames (by introducing new AssignedNames and Nicknames interfaces on the Connection, probably) is bug #14540. I think the assigned-name should fall back to (possibly a simplified form of) the handle, and the nickname should fall back to the empty string (meaning "no nickname, use the assigned name instead").

UIs should display both, ideally - <http://www.xmpp.org/extensions/xep-0165.html> has some more thoughts on this.

The point of the handle is that it represents an unambiguous representation - if what you want is actually an *entirely* unambiguous representation, at *that* point you should be using the string corresponding to the handle.

It's possible that some of the info in the SIP URI is irrelevant for the purposes of handle identity, in which case your handle normalization algorithm should perhaps change - as a general principle, the stringified handle should contain all the information necessary to uniquely identify a contact, and no more.

For instance, in XMPP, we normalize both of the JIDs user@example.com/Laptop and user@example.com/N810 into user@example.com - the resource (Laptop) is not relevant for handle identity (user@example.com/Laptop and user@example.com/N810 are meant to be seen as the same account).

Similarly, in SIP you might be able to delete some of the ?misc=foo stuff during handle normalization - if two SIP URIs are guaranteed to point to the same user or account (possibly using different UAs), you could normalize them to the same handle. sip:user@example.com?transport=tcp and sip:user@example.com?transport=udp should probably both normalize to sip:user@example.com for instance.