moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

Merge branch 'feature/xep-0050' into premerge

Browse Source
This commit is contained in:
Jonas Schäfer 2020-10-14 12:58:54 +02:00
commit fdaee2da8f
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
xep-0050.xml
View File

@ -25,6 +25,12 @@
<url>http://www.xmpp.org/schemas/commands.xsd</url>
</schemaloc>
&linuxwolf;
<revision>
<version>1.3.0</version>
<date>2020-06-09</date>
<initials>kis</initials>
<remark>Clarify illegal uses of 'execute'.</remark>
</revision>
<revision>
<version>1.2.3</version>
<date>2019-03-26</date>
@ -370,6 +376,7 @@
</iq>
]]></example>
<p>The &lt;command/&gt; SHOULD include an &lt;actions/&gt; element, which specifies the details of what the allowed actions are for this stage of execution. Each element within &lt;action/&gt; matches a possible value for the &lt;command/&gt; element's "action" attribute. The "execute" attribute defines which of the included actions is considered the equivalent to "execute" for this stage. In the above example, the only allowed action is to progress to the next stage, which is also the default.</p>
<p class="box"><strong>Note:</strong> The "execute" action (not the attribute) is ambiguous and may have undefined behaviour in some implementations. Relying on the specific behavior of the execute action is discouraged, especially in cases where the "complete" action is not allowed and the "execute" attribute is not specified (see also <link url="#impl-actions">Command Actions</link>.</p>
<p>The requester then submits the form, maintaining the command node and sessionid:</p>
<example caption='Execute command request (stage 2)'><![CDATA[
<iq type='set' to='responder@domain' id='exec2'>
@ -526,17 +533,19 @@
</li>
<li>If there is an &lt;actions/&gt; element, the user-agent usually uses a multi-stage dialog or view, such as a wizard.
<ul>
<li>The action "execute" is always allowed, and is equivalent to the action "next".</li>
<li>The action "execute" is equivalent to the action specified in the "execute" attribute. If the "execute" attribute is absent, it defaults to "next". A form which has an &lt;actions/&gt; element and an "execute" attribute which evaluates (taking the default into account if absent) to an action which is not allowed is therefore invalid.</li>
<li>The "prev" action is typically the "back" or "previous" button or option in a wizard. If &lt;prev/&gt; is not contained by the &lt;actions/&gt;, it is disabled.</li>
<li>The "next" action is typically the "next" button or option in a wizard. If &lt;next/&gt; is not contained by the &lt;actions/&gt;, it is disabled.</li>
<li>The "complete" action is typically the "finish" or "done" button or option in a wizard. If &lt;complete/&gt; is not contained by the &lt;actions/&gt;, it is disabled.</li>
<li>If the &lt;actions/&gt; possesses the "execute" attribute, that value is the default button or option. If the &lt;actions/&gt; does not possess the "execute" attribute, there is no default button or option.</li>
<li>As the "execute" command is equivalent to another command ("next" in the absence of an "execute" attribute), it is not suggested that a user-agent shows both the "execute" and the command that "execute" is an alias of in their interface.</li>
</ul>
</li>
</ol>
<p>Responders SHOULD use the following guidelines when providing &lt;actions/&gt;:</p>
<ul>
<li>The "execute" attribute SHOULD NOT specify a value that does not match one of the allowed actions.</li>
<li>As user-agents treat the absence of an "execute" attribute as equivalent to "next", when the &lt;actions/&gt; element is provided, it is invalid to return a command that has no "execute" attribute, an actions element, and no &lt;next/&gt; action</li>
</ul>
</section2>
<section2 topic='Command Payloads' anchor='impl-payloads'>