[Bug 24909] Anonymity API (e.g. suppressing caller-ID)

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Mar 31 01:05:56 CEST 2010


http://bugs.freedesktop.org/show_bug.cgi?id=24909





--- Comment #21 from Andres Salomon <dilinger at collabora.co.uk>  2010-03-30 16:05:55 PST ---
(In reply to comment #20)
> From a spec meeting:
> 
> Connection interface:
> 
> • SupportedAnonymityModes should be documented to only be stable once
>   you've connected. Should x-ref the type.

Thanks, fixed.


> 
> • Should SetAM just be a writeable D-Bus property? Maybe not if it
>   involves talking to the sky on GSM. But it needs to be a writeable
>   D-Bus so that it can be a connection parameter which is also a D-Bus
>   property using the DBus_Property Conn_Mgr_Param_Flag, allowing Mission
>   Control to update it on the fly when you change the corresponding
>   Account's parameters.

Huh?  I don't see why it would be controlled by mission-control; it's something
for the CM/connection to export letting the client/UI know the connection's
capabilities.  If there's some policy that requires one to disable anonymity
modes, that's something that should be handled on the (SIP, or other VOIP)
server.

> 
> • Will wonders if this interface might be overly tinfoil hatty and
>   support features no-one will ever use, and maybe we should just have a
>   HideCallerID: b property?

That depends upon the SIP folks; exactly how much control do you want to
provide to a UI when allowing modification of SIP anonymity modes?  For GSM,
HideCallerID would be just fine of course.
I'm not sure how much of the original rtcom privacy spec had actually been used
by CMs, as well as how much of it had actually been used by clients/UIs. 
Answering that question would probably give us a good idea of the answer to
your question.



>   · Others think that supporting these other flags is fine, but we
>     should order the flags by how obscure they are, so that the one you
>     actually care about — OriginatorInfo, aka caller-id — is first, and
>     then the introduction can say "If you just care about hiding your
>     caller ID, call Set("Flags", 1)".

Sure, the ordering is arbitrary atm (as the modes have changed quite a bit).  
A client who just wants to set caller-id shouldn't make assumptions about the
CM, though; the process should be something like -

SetAnonymityMode(GetProperty("SupportedAnonymityModes"));
SetProperty("Mandatory", true);

Likewise, turning caller-id back off should be -

SetAnonymityMode(0);

If the client actually cares about a various subset of anonymity settings (ie,
they only want to turn off caller-id, but leave hide-trust-domain turned off)
is going to need to look at individual mode flags anyways.

> 
> • Capitalization is wrong. smcv or similar needs to do an editorial
>   pass-through.
> 
> Channel interface:
> 
> • Properties don't need to be Initial*, they're immutable. Should be
>   AnonymityModes, AnonymityMandatory
> • Should say that those two are requestable.

Thanks, fixed.

> • AnonymizedDisplayName: this isn't a display name, it's an Identifier.

Hm, my understanding was that it was literally the name that was displayed to
the remote client.  In the case of GSM, this would be a phone number (an
identifier); in the case of SIP, this would be "Anonymous"
<sip:anonymous at anonymous.invalid>.


>   Say that it's not requestable.
> 

Done.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the telepathy-bugs mailing list