[Standards] Inconsistent Subscriptions in XMPP
stpeter at stpeter.im
Mon Jun 1 21:42:39 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 4/10/09 4:40 PM, Peter Saint-Andre wrote:
> On 4/7/09 12:45 AM, Philipp Hancke wrote:
>> hijacking the thread... two concrete examples where error handling
>> is needed:
>> subscription state is "none" initially:
>> SENT: <presence to="foo at bar" id="jcl_37" type='subscribe'/>
>> RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='push'
>> type='set'><query xmlns='jabber:iq:roster'><item ask='subscribe'
>> subscription='none' jid='foo at bar'/></query></iq>
>> RECV: <presence from='foo at bar' to='me at local/Exodus' type='error'
>> id='jcl_37'><error code='404' type='cancel'><remote-server-not-found
>> after relogin and roster fetch:
>> RECV: <iq from='me at local/Exodus' to='me at local/Exodus' id='jcl_40'
>> type='result'><query xmlns='jabber:iq:roster'><item ask='subscribe'
>> subscription='none' jid='foo at bar'/>
>> The presence error (which, as can be by looking at the id attribute,
>> is a reply to the initial subscribe) does not affect the subscription
> IMHO the server needs to periodically resend the subscribe to the
> contact if the state remains ask="subscribe" (no reply received from the
> contact). I'm pretty sure that I added something about this to rfc3921bis.
Yes, I did:
"If the contact does not approve or deny the subscription request within
some configurable amount of time, the user's server SHOULD resend the
subscription request to the contact based on an implementation-specific
algorithm (e.g., whenever a new resource becomes available for the user,
or after a certain amount of time has elapsed); this helps to recover
from transient, silent errors that might have occurred in relation to
the original subscription request."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards