[Standards] Client Acknowledgement of Subscription State Change Notifications

Peter Saint-Andre 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.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- 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/20070305/57f99cb7/attachment.bin>


More information about the Standards mailing list