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="f...@bar" id="jcl_37" type='subscribe'/> > RECV: <iq from='m...@local/Exodus' to='m...@local/Exodus' id='push' > type='set'><query xmlns='jabber:iq:roster'><item ask='subscribe' > subscription='none' jid='f...@bar'/></query></iq> > RECV: <presence from='f...@bar' to='m...@local/Exodus' type='error' > id='jcl_37'><error code='404' type='cancel'><remote-server-not-found > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence> > > after relogin and roster fetch: > RECV: <iq from='m...@local/Exodus' to='m...@local/Exodus' id='jcl_40' > type='result'><query xmlns='jabber:iq:roster'><item ask='subscribe' > subscription='none' jid='f...@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 > state.
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. > subscription state is "both" initially: > SENT: <iq id="jcl_50" type="set"><query xmlns="jabber:iq:roster"><item > jid="s...@jid" subscription="remove"/></query></iq> > RECV: <iq from='m...@local/Exodus' to='m...@local/Exodus' id='push' > type='set'><query xmlns='jabber:iq:roster'><item subscription='remove' > jid='s...@jid'/></query></iq> > RECV: <iq from='m...@local/Exodus' to='m...@local/Exodus' id='jcl_50' > type='result'/> > RECV: <presence from='s...@jid' to='m...@local/Exodus' type='error'><error > code='404' type='cancel'><remote-server-not-found > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence> > RECV: <presence from='s...@jid' to='m...@local/Exodus' type='error'><error > code='404' type='cancel'><remote-server-not-found > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></presence> > > The subscription state is "none" afterwards - which is the users intention. > The presence errors are replies to unsubscribe/unsubscribed stanzas > generated by the server and should imo never have been sent to the > client. Agreed -- the server should eat those. > The question is: how do error replies to presence subscription > stanzas affect the subscription state? That's up to the server. Smart servers will do the right thing. So we need smarter servers (and to provide some advice in rfc3921bis). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
