On 5 Mar 2018, at 14:21, Kevin Smith <[email protected]> wrote: > > > On 28 Feb 2018, at 19:13, Florian Schmaus <[email protected]> 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.
In the end I decided that while the words were convoluted, that’s because the underlying logic is convoluted. I’ve got some suggested words up at https://github.com/xsf/xeps/pull/598 that might or might not make things better. They are intended to be consistent with what’s already there, but just draw to attention the discussed invalid state. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
