[Standards] undefined state in XEP-0050

Jonas Wielicki jonas at wielicki.name
Thu Feb 22 08:24:36 UTC 2018

On Mittwoch, 21. Februar 2018 19:50:17 CET Florian Schmaus wrote:
> On 06.08.2015 17:42, Goffi wrote:
> > G'day,
> > 
> > there is a little issue with XEP-0050: in section 3.4 bullet 3, it's is
> > said that when the <actions/> element is present:
> > 
> >     - The action "execute" is always allowed, and is equivalent to the
> > action "next".
> >     - The "next" action is typically the "next" button or option in a
> > wizard. If <next/> is not contained by the <actions/>, it is disabled.
> > 
> > So if "next" action is disabled, execute is allowed but equivalent to a
> > disabled action.
> > 
> > I have had an issue which seems related to this confusion with SleekXMPP
> > and Gajim: if the next action is disabled in sleekXMPP, Gajim still show
> > the "execute" button, but a click on it result in an error, while the
> > "finish" button act as expected.
> > 
> > My guess is that "execute" should be equivalent to "complete" when
> > "next" is not possible (but what if "complete" is disabled too ?).
> I think it is a little design weakness of XEP-0050: Ad-Hoc Commands that
> we have 'next' and 'execute'. It appears the whole protocol would be
> much simpler and less confusing if we just had 'execute'.
> But this is unlikely to change ever. So here is how I understand it:
> - 'execute' always gets you into the next stage, and iff 'next' is an
> allowed action, then 'execute' is equivalent to 'next', or otherwise it
> is equivalent to 'complete'.

>From my reading, this is equivalent to what the standard already says and a 
good clarification. +1 (also, I marked it editorial for that reason, if anyone 
is uncomfortable with that, let me know here, directly, on github or in 

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180222/a0251578/attachment.sig>

More information about the Standards mailing list