moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 00:35:02 -05:00
Code Issues Releases Wiki Activity

[formtypes] Clarify FORM_TYPE field type on 'submit' type forms

Browse Source 
Since 'submit' type forms are allowed to omitt the explicit declartion
of the form field type, we must specify that the special FORM_TYPE
field in 'submit' forms may not carry a type declartion.

This just reflects what it is done in the wild anyways.

Co-authored-by: Marvin W <git@larma.de>
This commit is contained in:
Florian Schmaus 2020-03-25 20:53:17 +01:00 committed by Jonas Schäfer
parent b2e20eeefd
commit f78938a44f
1 changed files with 10 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
xep-0068.xml
View File

@ -23,6 +23,12 @@
<registry/>
&hildjj;
&stpeter;
<revision>
<version>1.3.0</version>
<date>2020-05-05</date>
<initials>fs</initials>
<remark>Clarify field type handling of the FORM_TYPE field on submission forms.</remark>
</revision>
<revision>
<version>1.2</version>
<date>2012-05-28</date>
@ -115,7 +121,7 @@
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Unspecified Form' anchor='usecases-unspecified'>
<p>These are forms that do not have a hidden field of name FORM_TYPE.
<p>These are forms with type=&quot;form&quot; or type=&quot;result&quot; that do not have a hidden field of name FORM_TYPE or forms with type=&quot;submit&quot; that do not have any field of name FORM_TYPE.
Existing processing rules still apply.</p>
<example caption='Message with no FORM_TYPE'><![CDATA[
<message
@ -171,7 +177,7 @@
</section2>
<section2 topic='Incorrectly Specified FORM_TYPE' anchor='usecases-incorrect'>
<p>If the FORM_TYPE field is not hidden, it MUST be ignored as a context indicator.</p>
<p>If the FORM_TYPE field is not hidden in a form with type=&quot;form&quot; or type=&quot;result&quot;, it MUST be ignored as a context indicator.</p>
<example caption='Message with bad FORM_TYPE'><![CDATA[
<message to="juliet@capulet.com" from="romeo@montague.net/garden">
@ -192,7 +198,7 @@
]]></example>
</section2>
<section2 topic='IQ Example' anchor='usecases-IQ'>
<p>The following example shows a user's interaction with a Multi-User Chat room in order to register with the room.</p>
<p>The following example shows a user's interaction with a Multi-User Chat room in order to register with the room. Note that as per &xep0004; the form field "type" attribute may be omitted in data forms of type "submit".</p>
<example caption='User Requests Registration Requirements'><![CDATA[
<iq
from='hag66@shakespeare.lit/pda'
@ -294,7 +300,7 @@
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>If the FORM_TYPE field is not type=&quot;hidden&quot;, it does not have the special meaning defined herein.</p>
<p>If the FORM_TYPE field is not type=&quot;hidden&quot; in a data form with type &quot;form&quot; or type &quot;result&quot;, it does not have the special meaning defined herein. Data forms with the type "submit" are free to omit any explicit field type declaration (as per &xep0004; § 3.2), as the type is implied by the corresponding "form"-type data form. As consequence, implementations MUST treat a FORM_TYPE field without an explicit type attribute, in data forms of type "submit", as the FORM_TYPE field with the special meaning defined herein.</p>
<p>If the form is used in an IQ, the namespace of the &lt;query/&gt; element SHOULD match the base namespace of the FORM_TYPE. (One possible way of solving this problem would have been to reuse the &lt;query/&gt; tag from the IQ form of jabber:x:data within messages, but that would have meant that existing clients would not have been able to participate in these exchanges.)</p>
</section1>