Sticky Buddy Authorizations

[Christoph Petersen]

Hi Etan,

Etan Reisner wrote:
> On Tue, Nov 25, 2008 at 09:55:21AM +0100, Christoph Petersen wrote:
> <snip>
>> A new friend of mine just asked to authorize her and then
>> my Pidgin disconnected. This shouldn't be a problem itself but when I
>> reconnected the authorization request was gone. Maybe this is a protocol
>> thing not sure about that.
>>
>> Is it possible to implement something like sticky authorizations? So
>> that when you don't actively deny or accept a request the request will
>> show up again on next login of the service in question?
>>
>> BR
>> Christoph
> 

Thanks for your reply.

> That depends entirely on the protocol. XMPP servers are supposed to
> repeatedly deliver subscription authorization requests until they are
> either accepted or denied (the client doesn't need to do anything but log
> in again to get them). I don't know whether other protocols have such a
> system in place. I'm also not at all sure that all XMPP servers actually
> do that correctly.

The protocol in question is ICQ. So I take that as that AIM/ICQ protocol 
doesn't support that "feature"...

> 
> Whether pidgin can 'store' the auth request for a later answer also
> depends on the protocol involved and whether the servers are willing to
> accept 'unsolicited' authorization granting. XMPP was not set up to accept
> this and only in one of the most recent draft versions of the
> specification was support for this sort of scenario even mentioned, and
> even now support for pre-emptive authorization (which is what it would be
> if the server had forgotten the request was sent) is (I believe) optional.
> Prior to this draft an unsolicited authorization was to be dropped
> silently by the server.

I know this is a bit schizophrenic because with Yahoo I have a problem 
of huge amounts of unsolicited buddy requests from within the Yahoo 
network and from MSN endpoints.

I just wanted to know why this is. My actual problem was solved simply 
through asking again so this was solved neatly :)

> 
>     -Etan

BR
Christoph