[Standards] Client Acknowledgement of Subscription State Change Notifications
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
>>>> 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
> Maybe a stream feature, and an IQ to turn it on?
Possible. If we decide to keep this functionality.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards