[Standards] Client Acknowledgement of Subscription State Change Notifications
stpeter at jabber.org
Mon Mar 5 22:24:59 UTC 2007
Ian Paterson wrote:
> Section 9.4 of RFC 3921 (Appendix B.4 of RFC 3921bis) states that "A
> server MAY require the recipient to acknowledge receipt of all state
> change notifications... In order to require acknowledgement, a server
> SHOULD send the request or notification to the recipient each time the
> recipient logs in, until the recipient acknowledges receipt".
> 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?
IIRC it was all a matter of keeping subscription states in sync.
> A couple of suggestions for 3921bis:
> 1. Since a client has no way of discovering if the server requires an
> acknowledgement or not,
Sounds like a good thing to specify. A stream feature perhaps? Or
(probably better) service discovery.
> it should always acknowledge notifications. So
> perhaps RFC 3921bis could highlight the importance of clients responding
> by also specifying something like: "The recipient SHOULD/MUST affirm or
> deny every notification to prevent some servers flooding it with an
> ever-increasing number of notifications upon each login."
Presumably the server could figure out (via entity capabilities) whether
the client supports a yet-to-be-defined feature of acking notifications.
> 2. Hopefully someone will enlighten me, but if not, perhaps we could
> also consider depricating this repeated notification behaviour?
For subscription requests or the other notifications?
> Apologies in advance if this subject has already been discussed with
> regard to 3921bis.
It was discussed a bit in the run-up to publishing RFC 3921.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards