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

[Peter Saint-Andre]

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.

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.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070411/9eacce8c/smime-0001.bin