[Standards] undefined state in XEP-0050

Kevin Smith kevin.smith at isode.com
Thu Feb 22 09:29:18 UTC 2018


On 22 Feb 2018, at 08:24, Jonas Wielicki <jonas at wielicki.name> wrote:
> 
> 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 
> editor@).

FWIW, I think this isn’t what the standard already says, although may be sensible.

/K


More information about the Standards mailing list