[Standards] undefined state in XEP-0050

Florian Schmaus flo at geekplace.eu
Wed Feb 28 19:13:59 UTC 2018


On 22.02.2018 10:28, Kevin Smith wrote:
>> On 21 Feb 2018, at 18:50, Florian Schmaus <flo at geekplace.eu> wrote:
>> On 06.08.2015 17:42, Goffi wrote:
>>> 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’.
> 
> Execute is convenient - it’s not an action of its own per se, it’s just saying which of the provided actions is used by default (e.g. will be run when the user hits Enter), but allowing it to be sent as an action= value could have been better thought-out, I suspect (even then, it’s useful for the first stage of the form). So I suspect the underlying issue described here is UIs wrongly showing independent buttons for Execute and whatever Execute should mean.

No, it is about simplicity and that I don't see why there shouldn't be a
combined *action* of 'next' and 'execute'. It is not about and unrelated
to the existence of the 'execute' attribute.
>> 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 think that if we follow what 50 says, we actually reach the conclusion that if execute isn’t set on actions, it’s equivalent to next, which may be disabled. Which basically means that an actions list not including next and not including an execute value is saying “The default is next, and it’s disabled”, which is more or less a broken xep 50 command so the responder shouldn’t send it. Changing to have the default switch to complete if there’s no next is probably not harmful, although is a change in behaviour from what we have.

The question is: (1) Do we want to allow 'execute' to be at a given
point equivalent to a disabled action, which, when used, would result in
a bad-command error response, *or* do we want to avoid that by either

(2) Specifying that execute → next, if 'next' is not disabled
                            → complete, otherwise
(3) Specifying that the responder must always provide an 'execute'
attribute if 'next' is a disabled action.

I'd love to go with either (2) or (3), but if you assume that (1) is
currently xep50 compliant, then this means a backwards incompatible
change, which would require a namespace bump.

A compromise would probably be only recommending (3) in the XEP.

- 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/20180228/30fcac23/attachment.sig>


More information about the Standards mailing list