[Standards] [Fwd: [Council] meeting minutes, 2007-04-10]

[Mridul Muralidharan]

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/> 
> child....
> 
> ******
> 
> 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 ...


Thanks,
Mridul

> 
> Peter
>