[Telepathy] Display names from SIP headers as aliases?

[Robert McQueen]

mikhail.zabaluev at nokia.com wrote:
> Hi,

Hi Mikhail,

> There has been a discussion about improving the Aliasing interface. I
> have a tangent interest here, in that I consider using the interface
> to expose display names for contacts, as sent and received with SIP
> protocol messages. Just as in RFC2822 messages, SIP addressing
> headers From: and To: may include a human-friendly name along with
> the address URI. It would be nice to extract that name from incoming
> messages and make it available to the API clients, e.g. to display in
> a chat window, or as the initial name suggestion for a new address
> book entry

Right, this is a good plan I think. Are these aliases ever used to
indicate call-specific information? ie, if the same person calls you
twice, is it reasonable to expect that the only reason they'd change
their human-readable name was because they'd decided to change it
between times, not just because it was a different call? If there's some
convention for passing extra per-call data in these names, we might need
to do something differently, otherwise each time someone calls you their
name would change.

> (OTOH that will raise more security concerns than
> displaying a bare URI).

Provided the user is shown both, there's no concern. If you took the
other end's identity claim and used it to override their real identity,
that would be bad. :)

> Also, providing our own human-friendly name
> is an additional nicety.

This can be determined from the value of SetAlias(self_handle, ...).

> If the Aliasing interface is used for that, it may necessitate
> caching display names along with contact handles for the lifetime of
> a Connection. That's the only implementation concern I have with the
> current API.

Gabble has a few sources for aliases due to the myriad ways that XMPP
gives us to find what someone's called. Some are stored on your roster,
which means they are cached for as long as that contact is on your
roster, some are derived from presence, so are cached for as long as
that contact is available, and some are extracted from essentially
static, but expensive (in terms of retreiving a lot of information and
only using one or two words of it) vCard queries so are cached very
aggressively.

The vCard-derived nicknames are stored using qdata on the contact handle
inside Gabble, which means that as long as the contact is used somewhere
by the client (eg as the participant in a channel, or just by
HoldHandles explicitly) we'll keep the alias in memory. When the
handle's internal refcount goes to zero, they are freed. Take a look at
observe_vcard() and gabble_vcard_manager_get_cached_alias() in
src/vcard-manager.c in Gabble.

If you don't have eg a roster or presence to decide if a person's still
relevant (and I don't think you do in this case?), then the handle qdata
approach is a reasonable way of associating the cached alias with the
contact handle's lifetime, and hence freeing them when they're not
relevant to the client rather than caching indefinitely.

> Your thoughts are welcome, Mikhail Zabaluev,  Nokia Multimedia 

Regards,
Rob