[Standards] Re: [Standards-JIG] ad-hoc commands questions

Peter Saint-Andre stpeter at jabber.org
Thu Jan 18 19:03:30 UTC 2007

On 2006-10-13, Gaston Dombiak wrote:

> Some time ago we implemented XEP-50 into Wildfire and we are now slowly 
> implementing XEP-133. While implementing XEP-133 (btw, I tend to keep 
> writing JEP instead of XEP :) ) I noticed two differences that I think are 
> not clear when reading XEP-50.
> In XEP-50 commands are executed using IQ stanzas of type SET. The XEP does 
> not explicitly specify that they MUST be of a certain type but that is what 
> you infer from the examples. 

That seems correct. Executing a command is always a SET.

> On the other hand XEP-133 is using IQ stanzas 
> of type GET to run commands (e.g. 4.7 Change User Password). It seems that 
> XEP-133 is using GET to "get" the form and "set" to finally execute the 
> command. I think that in order to make things simple I prefer the option of 
> just using SET instead of a mix of GET/SET. What do you think?

Agreed. XEP-0133 needs to be updated accordingly.

> The other question is related to errors while executing commands. For 
> instance, how should the answer be when a supplied user JID does not exist 
> while trying to change a user password? XEP-50 is using the <note/> element 
> of type "error" to indicate that there was an error. But what type of IQ 
> packet should the be returned (i.e. "error"  or "result")? 

I think "error".

> BTW, example 23 
> in XEP-20 is using type SET while I guess the author wanted to use ERROR.

Fixed in XEP-0050.

> Answering to my last question and after reading section 4.4 Possible Errors 
> in XEP-50 I think that IQ packets should be of type ERROR and probably we 
> should use the condition <cmd:bad-payload/> for those cases. Is this 
> correct? 

I think so.

> May be adding a few examples of errors while executing commands in 
> XEP-50 and XEP-133 would help implementers to more easily understand.

Yes, I think both of those specs need some attention. The XEP-0050 
author mentioned to me the other day that he saw some things in the spec 
that needed to be corrected...


Peter Saint-Andre
XMPP Standards Foundation

-------------- 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/20070118/954875b3/attachment.bin>

More information about the Standards mailing list