JSJaCIQ.reply cloning the request

[gavllew]

I'm not sure if this is strictly incorrect behaviour, but thought I would bring this up as a discussion point. Are there any cases where you want the contents of the request to be duplicated in the response? I've only used iq stanzas for roster operations so far, but all that seems to be needed there is an empty iq with type='result'.

Wouldn't it be better to start with an empty iq, and just set the 'to', 'type' and 'id' attributes based on the request?

Looks like the same logic may also apply to JSJaCPacket.errorReply().

[sstrigler]

Hmmm. Probably you're right, but I'm pretty sure I had sth in mind when I wrote this function (as by that time I needed it at some of my projects). Regarding errorReply the payload is definitely needed as it is common and probably good practice to send back the original request payload for easier debugging and reference.

[gavllew]

OK, I agree with the error replies - RFC 6120 section 8.3.1. specifies that implementations MAY include the original XML, and this makes sense.

As for normal replies, maybe provide a parameter, or a pair of helper functions - one that prepares an empty reply, and another that prepares a cloned reply.