In <https://bugs.freedesktop.org/show_bug.cgi?id=23155#c8> Will wrote:
> Brainstorming this with Rob, Pekka and Aki at the MeeGo Conference led to the
> following rough proposal for 1.0:
> 
>   • In the D-Bus API, replace handles with (ss) tuples, where the first field
> is the vCard field, and the second field is the contact ID.
>   • Cellular conference call-style meaningless channel-specific-handles could
> have a dummy namespace and look something like this: ("meaningless",
> "1234:really:tel:+441234567890").
>   • General channel-specific handles could have some similar convention. Or
> maybe we could use (sss) throughout.
> 
> Using tuples rather than just strings makes Addressing more native than it
> will be in 0.x; it also makes it more obvious to applications that they
> should only store things that the CM has normalized. The argument that
> applications will confuse normalized and non-normalized strings is fair,
> but applications not using bindings mess up handles, too, and in
> applications using bindings we can use the host language's type system
> to distinguish the two.
>
> Using strings throughout would make dbus-monitor traffic easier to read,
> would remove a whole section of Telepathy that currently needs
> explaining, and would also remove the memory-leak objection to
> immortal handles: CMs could forget contact ID tuples when they're done
> with them, safe in the knowledge that they can re-create them if a
> client uses one.
>
> (Internally, telepathy-glib's API could replace TpHandle with GObjects
> that get passed around implementing a particular interface...
> TpSvcContact, say. This preserves fast comparisons and so on.)

I agree with this proposal, except that I'm not sure about making the namespace portion be a vCard field. Normatively referencing vCard for ContactInfo is fine, but I'm not sure that our entire addressing model should be vCard when most of the protocols we deal with don't have an official vCard field.

Alternatives include: another externally-defined thing (URI scheme?), a string chosen by the CM (with "" denoting the protocol's "native" namespace perhaps), or the Telepathy name of the protocol (defined by tp-spec with scope for CM-specific extensions).

(In reply to comment #1)
> or the Telepathy name of the protocol (defined by tp-spec with scope for
> CM-specific extensions).

I find this more consistent with other parts of the spec, such as Protocol.I.Addressing (e.g., you can easily map a contact to its corresponding protocol). I guess we'll need to keep the Addressing interfaces to maintain the conceptual barrier between non-normalized vCard and URI addresses and normalized contact tuples.

(In reply to comment #1)
> I agree with this proposal, except that I'm not sure about making the namespace
> portion be a vCard field. Normatively referencing vCard for ContactInfo is
> fine, but I'm not sure that our entire addressing model should be vCard when
> most of the protocols we deal with don't have an official vCard field.

At least there is no stigma in inventing your own X- vCard fields as needed, such as there is with URL schemas. I think having one, standard-compliant where applicable, registry common between the handle namespace, the vCard part of Addressing, and ContactInfo is a big enough advantage.
Maybe it would be prudent to make a reservation that any X-names introduced in the Telepathy spec can be deprecated in favor of official vCard property names once those are standardized.

I think removing handles completely from the spec is a huge work that probably won't happen for 'next'. However in tp-glib's high-level API we already got ride of them all.

So I suggest removing this bug from blocking tp-spect-1.0

(In reply to comment #4)
> I think removing handles completely from the spec is a huge work that probably
> won't happen for 'next'. However in tp-glib's high-level API we already got
> ride of them all.
> 
> So I suggest removing this bug from blocking tp-spect-1.0

I completely agree. I'm removing the blocker now.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/33.