[Standards] undefined state in XEP-0050

Florian Schmaus flo at geekplace.eu
Wed Feb 21 18:50:17 UTC 2018


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'.

I've submitted https://github.com/xsf/xeps/pull/591

Discuss :)

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180221/1021d360/attachment.sig>


More information about the Standards mailing list