[Standards] XEP 313 error handling

Kim Alvefur zash at zash.se
Thu Dec 4 17:07:57 UTC 2014

On 2014-12-04 15:11, Kamil Kisiel wrote:
> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland <dave at cridland.net
> <mailto:dave at cridland.net>> wrote:
>     On 3 Dec 2014 21:11, "Kurt Zeilenga" <kurt.zeilenga at isode.com
>     <mailto:kurt.zeilenga at isode.com>> wrote:
>     >
>     > How does the server, after it has responded to the IQ with a type=result stanza, communicate errors in processing the query to the client that might subsequently occur.   What if the server is unable to send any subsequent stanzas associated with the query?  Is the server expected to hold off sending the IQ response until it is reasonable assured that no subsequent errors will occur?  That is, to the time in which has compiled all the stanzas to sends to the client and is ready to put them to XMPP stream?
>     >
>     > It seems to me that the IQ response really should come last so that the server is able to indicate to the client whether or not is has successfully completed the request or failed.   If sent last, then there’s really no need for a separate <fin/>.
>     >
>     > If the IQ response is not last, there there really needs to be some method for the server to indicate that it’s not able to provide further results.
>     >
>     I think I agree with everything written here. Sending the iq last
>     would be best, I think, though I appreciate that's likely to be a
>     protocol bump.
>     Dave.
> That's how it was specified in version 0.2, it seems it was changed to
> <fin/> in 0.3

I remember someone argued very persistently that this change was needed
because their code had timeouts for iq requests that could trigger if
there is rate limiting or a slow connection before all the messages and
the iq-reply was received.

Or something.  Personally I prefer having the iq-result sent last, it
makes client code (Verse in my case) simpler.

Kim "Zash" Alvefur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141204/fba2ac66/attachment.sig>

More information about the Standards mailing list