[Standards] undefined state in XEP-0050

Kevin Smith kevin.smith at isode.com
Mon Mar 5 16:11:01 UTC 2018


On 5 Mar 2018, at 14:21, Kevin Smith <kevin.smith at isode.com> wrote:
> 
> 
> On 28 Feb 2018, at 19:13, Florian Schmaus <flo at 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.

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


More information about the Standards mailing list