On 28 Feb 2018, at 19:13, Florian Schmaus <f...@geekplace.eu> wrote: > >>> 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.
I think (3) is what we already have, we just don’t call attention to is. That is - with the current text, if you (as a responder) send no execute attribute, and next is disabled, you’ve sent a broken form. So I think it’s sufficient to say “And obviously if you send …, you’ve sent a broken form”. This is no change in behaviour, and so no need for bumps, etc. I’ve just opened this in my editor to have a bash at it, but then realised I’m about to (virtually) walk into a meeting. I’ll try to have a bash later this afternoon. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
