Bug 26591

Summary: Clarify what InitiatorHandle means
Product: Telepathy Reporter: Simon McVittie <smcv>
Component: tp-specAssignee: Simon McVittie <smcv>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium CC: mikhail.zabaluev
Version: git masterKeywords: patch
Hardware: Other   
OS: All   
URL: http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/initiator-clarification
Whiteboard: review+
i915 platform: i915 features:

Description Simon McVittie 2010-02-16 05:43:54 UTC
Consider the following situation:

* Rob created a persistent chatroom, say #telepathy, on a server
* Simon is not in the chatroom
* Will invites Simon to the chatroom, creating a Channel in Simon's CM

The spec doesn't make it entirely clear whether Simon should see Will or Rob as the InitiatorHandle. In Gabble, Will would be the InitiatorHandle.

wjt, mikhailz and I agree that Gabble's implementation is correct: for invitations, the InitiatorHandle should be the contact who caused the Telepathy Channel to be created (i.e. the inviter).

The contact who caused the underlying protocol construct to be created is a distinct concept which should be in o.fd.T.Properties (or in future, the replacement requested by Bug #23151).

Rationale: the room creator is much less interesting than the inviter, is less likely to be available at invitation time (i.e. can't necessarily be an immutable property), and is less likely to be available at all.

The current text "For channels requested by the local user, this MUST be the value of Connection.SelfHandle  at the time the channel was created" agrees with this interpretation, and contradicts the other option.
Comment 1 Simon McVittie 2010-03-11 07:57:17 UTC
r+ from wjt
Comment 2 Simon McVittie 2010-03-11 09:40:55 UTC
Fixed in git, will be in 0.19.2

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.