Here is Vivek's branch implementing the property.

I have a branch at http://git.collabora.co.uk/?p=user/wjt/telepathy-mission-control-wjt.git;a=shortlog;h=refs/heads/sso-updates%2Bservice-property which updates mc-tool to support setting the Service property, just as it supports setting Icon and friends.

The spec doesn't say that Account.Service should fall back to the protocol; it says that if it's the empty string, the service is determined by the protocol name. I'm inclined to think that MC should report service-less accounts with Account.Service = "".

The test doesn't test specifying Service at account creation time.

The patch named 'ibid' should be squashed into the preceding patch (which it fixes).

+    assert account_props.Get(cs.ACCOUNT, 'Service') == 'fu-bar'

assertEquals

+    # OK, let's go online

but that's not what happens next in the test.

There are a load of unused imports in the test.

(I have not reviewed the branch on which this branch is stacked.)

+        g_set_error (error, TP_ERRORS, TP_ERROR_INVALID_ARGUMENT,
+                     "Service cannot be set to '%s' (%s)",
+                     g_value_get_string (value),
+                     G_VALUE_TYPE_NAME (value));

What's the point of including the type name? we know it's a string (don't we? doesn't MC's property fu ensure that? if it doesn't we'll already have critical'd from the g_value_get_string()s). And this error would be more useful if it said something like "'%s' is an invalid service name; service names consist only of ASCII letters, numbers and hyphen/minus signs, and start with a letter".

+    /* fall back to the protocol if nothing is explicitly set, as per spec */
+    if (g_value_get_string (value) == NULL)
+        g_value_set_string (value, "");

Comment no match code.

This appears to have been released in 5.5.3.