As of version 0.17.9, the Telepathy specification provides two sorts of displayable representations for contact handles: ID strings obtainable using Connection.InspectHandles, and aliases from the Aliasing interface. There are use cases that aren't served well by either. If the alias name is not available for a contact, the UI should display the address. Normalized handle IDs may have details that obscure the bits relevant for the user, but are important for correct identification in the protocol or connection manager implementation. A good example is URI parameters in SIP addresses such as "user=phone"; technically part of address identity, but practically the user shouldn't have to care about them in most cases. It's useful to have a way to retrieve string representations for contacts satisfying the following requirements: 1) Display-friendly so as to omit technical details (e.g. URI parameters, the default scheme prefix) non-essential for making the contact's address practically identifiable to the user. 2) Not suitable to uniquely identify a handle. For string s retrieved using the proposed API, conn.InspectHandles(conn.RequestHandles([s])) will not necessarily return s, moreover, such strings are not expected to be usable for requesting handles. 3) Not intended for long-term storage or indexing. The normalized handle ID should be used for that. 4) Available for retrieval at all connection states, without network roundtrips. The default implementation (and the client-side wrapper) could fall back to retrieving handle IDs.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.