[Standards] [Fwd: [Council] meeting minutes, 2007-04-10]
mridul at sun.com
Wed Apr 11 13:29:28 CDT 2007
Peter Saint-Andre wrote:
> Mridul Muralidharan wrote:
>> Actually I have a query regarding iq.
>> In some xep's (& rfcs), the iq response has just the type & id (<iq
>> type="error|result" id="id1" />).
>> Some others include the namespace.
>> While in yet others (usually in context of error), the request query
>> is also included.
>> Some api's/clients/servers refuse to behave properly if the namespace
>> is not in the iq response.
> That's a bug.
>> While some others do not generate namespace in cases.
>> Shouldn't clients/servers keep track of iq's based on from-to-id tuple
>> ? Isn't that not enough ? Or is this documented as a MUST somewhere
>> and I am missing something ?
> You are right that, in general, applications should keep track of IQs
> based on the from-to-id tuple and should be able to process an IQ-result
> or IQ-error without the original payload. For IQ-results you don't need
> the payload since you know that the IQ was processed successfully. For
> IQ-errors, it is perhaps nice for the responding entity to include the
> payload, but it is not necessary by any means.
Thanks for clarifying this.
A while back, I modified our server to always include an empty first
level child of iq just to work around this problem in case the response
is empty, like :
<iq from="jid" to="jid" type="type" id="id" > <query xmlns="req_ns" /> </iq>
With this, most of these iq issues went away.
But imo that was a hack at best.
> Section 9.2.3 of RFC 3920 states in part:
> 6. An IQ stanza of type "result" MUST include zero or one child elements.
> 7. An IQ stanza of type "error" SHOULD include the child element
> contained in the associated "get" or "set" and MUST include an <error/>
> The SHOULD in #7 is perhaps a bit misleading since as you say the
> sending application knows what it sent -- it is simply a courtesy for
> the responding application to include the original payload (and in many
> cases this could result in large stanzas). I am open to changing this in
> rfc3920bis or in various examples.
It would be great to add that it is advisible for the server's to
atleast have a single child for iq with the namespace of the request
(maybe something like above) - but clients/server MUST NOT depend on
this and SHOULD try to use from-to-id tuple for identification of
packets : primarily for helping out current clients/servers/api's which
assume this in various forms but discouraging this ...
More information about the Standards