[Standards] Client Acknowledgement of Subscription State Change Notifications

Yann Le Boulanger asterix at lagaule.org
Wed Mar 28 07:13:32 UTC 2007

Peter Saint-Andre wrote:
> Joe Hildebrand wrote:
>> On Mar 21, 2007, at 4:59 PM, Peter Saint-Andre wrote:
>>> Ralph Meijer wrote:
>>>> On Tue, 2007-03-06 at 13:50 +0100, Jacek Konieczny wrote:
>>>>> On Sun, Mar 04, 2007 at 09:28:08PM +0000, Ian Paterson wrote:
>>>>>> The acknowledgement of subscription requests is clearly necessary,
>>>>>> but can anyone please tell me why servers are permitted (but not
>>>>>> encouraged) to insist on acknowledgements for the other three
>>>>>> notifications?
>>>>> So no information is lost and the user will always be informed (if he
>>>>> likes to) about subscription state changes.
>>>> It seems to me that no information is lost since the roster reflects
>>>> the
>>>> actual situation?
>>>> Like Ian, I have always found it weird that 'unsubscribed' and
>>>> 'subscribed' have grown acks/denies in XMPP. I know that jabberd 2
>>>> implements this 'feature' and it seriously messed up some clients so I
>>>> had do disable it with a patch.
>>> Yes, it's weird (and yes, I'm partly responsible for the weirdness).
>>> I think it would be good to take a hard look at these acks and figure
>>> out if we want to retain them in rfc3921bis.
>> If we do, I'd like to make sure that if clients continue to send the
>> acks, they are no-ops.
> Agreed.
>> If we still want the functionality,
> I don't see many people jumping up and down in favor.
> Who has implemented this? It seems that jabberd2 did, but people
> disabled it. And I don't know of any clients that implement it. Just
> that would tend to disqualify it (can't be tested since it's not
> implemented).

Gajim acknowledge all presences. But we had problems with some servers,
which run into a loop when doing this, so we had to detect those loop to
disable the ack.
This bring nothing to the client, it was just to be more RFC complient.


More information about the Standards mailing list