[Standards] Client Acknowledgement of Subscription State Change Notifications
hildjj at gmail.com
Thu Mar 22 22:36:33 UTC 2007
If we do, I'd like to make sure that if clients continue to send the
acks, they are no-ops.
If we still want the functionality, I can imagine a couple of new
presence types that were explicitly acks; of course the server would
have to declare support for them somehow. As well, it would be cool
if clients that didn't know about the new presence types a) didn't
receive them and b) didn't have to send acks to turn off the
Maybe a stream feature, and an IQ to turn it on?
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.
> Peter Saint-Andre
> XMPP Standards Foundation
More information about the Standards