moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

1.2rc2

This commit is contained in:
Peter Saint-Andre 2012-04-17 20:46:27 -06:00
parent d7e0493cf4
commit 6e38e498ba
1 changed files with 12 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
xep-0068.xml Normal file → Executable file
View File

@ -25,10 +25,10 @@
&hildjj;
&stpeter;
<revision>
<version>1.2pre1</version>
<date>2011-10-18</date>
<version>1.2rc2</version>
<date>2012-04-17</date>
<initials>psa</initials>
<remark>Removed mandates about x- prefix.</remark>
<remark>Removed mandates about x- prefix in accordance with IETF recommendations.</remark>
</revision>
<revision>
<version>1.1</version>
@ -62,25 +62,22 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Now that &xep0004; has been finalized, several uses of jabber:x:data forms have been put on the standards track, including &xep0045;. These protocols typically need a way to gather data from both humans (using a GUI format) and computer processes (using a pre-defined but flexible format).</p>
<p>The 'jabber:x:data' namespace provides an adequate mechanism for both of these uses, as long as computer processes can rely on the var=&quot;&quot; names on a particular type of form.</p>
<p>This document proposes a specific mechanism for the &REGISTRAR; to standardize these form field variable names. Thus this document enables existing clients to process forms as they have to this point, but enables protocol authors to specify a mechanism for non-GUI processors of those forms to determine the semantic meanings of those forms.</p>
<p>XMPP extensions that reuse &xep0004;, such as &xep0045; and &xep0050;, typically need a way to gather data from both humans (using a GUI format) and computer processes (using a pre-defined but flexible format). The 'jabber:x:data' namespace provides an adequate mechanism for both of these uses, as long as computer processes can rely on the var=&quot;&quot; names on a particular type of form. This document defines a mechanism for the &REGISTRAR; to standardize the field names in such forms, thus enabling XMPP clients to process forms as they have to this point while giving protocol authors a way to specify a mechanism for non-GUI processors to determine the semantic meanings of forms and their constituent fields.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ol>
<li>Forms must continue to be presentable to humans for data entry.</li>
<li>Jabber clients that know how to process generic jabber:x:data messages must be supported; the basic format of jabber:x:data must not change.</li>
<li>XMPP clients that know how to process generic jabber:x:data messages must be supported; the basic format of jabber:x:data must not change.</li>
<li>If a form type is used in the context of a standards-track protocol, it should be standardized and registered; however, there is no requirement that all form types must be registered (e.g., form types used in custom applications).</li>
<li>If a form type is standardized and registered, field names used in the context of that form type must either be standardized as well or else be clearly labeled as unregistered.</li>
<li>Forms that are not directed <em>to</em> an entity must be able to traverse the entity (e.g., a form sent to a MUC room, intended for the participants of the room, and not the room itself).</li>
<li>Forms must continue to be flexible for implementations; unknown future expansion fields must not be limited.</li>
<li>The chosen approach must work for forms embedded in messages as well as in IQs.</li>
<li>The chosen approach must work for forms embedded in &MESSAGE; stanzas as well as in &IQ; stanzas.</li>
</ol>
</section1>
<section1 topic='Approach' anchor='approach'>
<section2 topic='Overview' anchor='approach-overview'>
<p>Within Jabber, namespaces are used to scope data that conforms to a schema (often data that extends the core protocol in some fashion). In addition, namespaces can also provide context for the field variable names used in jabber:x:data forms and reports. This proposal makes that link explicit by defining a mechanism for linking a namespace name with a form and the field names and types used in that form. Specifically, the namespace name is specified in the form as the value of a hidden variable called "FORM_TYPE".</p>
<p>Within XMPP, namespaces are used to scope data that conforms to a schema (often data that extends the core protocol in some fashion). In addition, namespaces can also provide context for the field variable names used in jabber:x:data forms and reports. This proposal makes that association explicit by defining a mechanism for linking a namespace name with a form along with the field names and types used in that form. Specifically, the namespace name is specified in the form as the value of a hidden variable called "FORM_TYPE".</p>
</section2>
<section2 topic='Whether to Register' anchor='approach-register'>
<p>The first decision-point is whether a FORM_TYPE needs to be registered with the XMPP Registrar. The following rules apply:</p>
@ -94,8 +91,8 @@
<p>While the value of the FORM_TYPE attribute SHOULD be considered an opaque string from the application perspective, the following rules apply:</p>
<ol>
<li>For custom protocols, the name SHOULD be an HTTP URI that is managed by the namespace owner (e.g., "http://example.com/foo").</li>
<li>For all new protocols approved by the XSF, the name MUST be a "urn:xmpp:*" URN in accordance with Section 4 of &xep0053;.</li>
<li>For "legacy" protocols managed by the XSF, the name SHOULD use the old-style "jabber:*:*" format.</li>
<li>For all new protocols approved by the XSF, the name MUST be a "urn:xmpp:*" URN in accordance with &rfc4854; and Section 4 of &xep0053;.</li>
<li>For "legacy" protocols managed by the XSF, the name SHOULD use the old-style "jabber:*:*" or "http://jabber.org/protocol/*" format.</li>
</ol>
</section2>
<section2 topic='Field Names' anchor='approach-fieldnames'>
@ -108,7 +105,7 @@
<p class='box'>Note: Older versions of this specification mandated that unregistered field names had to begin with the prefix "x-". In accordance with &xdash;, that mandate has been removed.</p>
</section2>
<section2 topic='Field Values' anchor='approach-fieldvalues'>
<p>Field values may also be registered; refer to the <link url='registrar'>XMPP Registrar</link> section of this document.</p>
<p>Field values MAY also be registered; refer to the <link url='registrar'>XMPP Registrar</link> section of this document.</p>
</section2>
</section1>
@ -302,7 +299,7 @@
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA; for now.</p>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
@ -322,7 +319,7 @@
label='natural-language description of field'/>
</form_type>
]]></code>
<p>The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate &lt;form_type/&gt; element. The registrant MAY also register more than one field at a time, each contained in a separate &lt;field/&gt; child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the XEP number or other document identifier). Note that for ease of use the format for the &lt;field/&gt; element in the registry submission is the same as that defined in XEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in that XEP-0004.</p>
<p>The registrant MAY register more than one FORM_TYPE at a time, each contained in a separate &lt;form_type/&gt; element. The registrant MAY also register more than one field at a time, each contained in a separate &lt;field/&gt; child element. Registrations of new fields within an existing FORM_TYPE MUST include the full XML snippet but SHOULD NOT include the FORM_TYPE description (only the name and the XEP number or other document identifier). Note that for ease of use the format for the &lt;field/&gt; element in the registry submission is the same as that defined in XEP-0004; in addition, the value of the 'type' attribute MUST be one of those defined in XEP-0004.</p>
<p>In addition, a registrant MAY also register particular field option values for fields of type 'list-single' and 'list-multi'. The format for such submissions is as follows:</p>
<code><![CDATA[
<form_type>