[Standards] Client Acknowledgement of Subscription State Change Notifications

Peter Saint-Andre stpeter at jabber.org
Wed Mar 28 04:25:32 UTC 2007

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.


 > 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 

 > I can imagine a couple of new
 > presence types that were explicitly acks;

Presence via IQ? ;-)

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

For sure.

 > Maybe a stream feature, and an IQ to turn it on?

Possible. If we decide to keep this functionality.


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070327/77c6407b/attachment.bin>

More information about the Standards mailing list