[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.

-- 
Yann



More information about the Standards mailing list