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

1.2rc3

This commit is contained in:
Peter Saint-Andre 2012-05-09 09:27:54 -06:00
parent 02a95e5f11
commit 3863423fd8
1 changed files with 8 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
xep-0068.xml
View File

@ -25,8 +25,8 @@
&hildjj;
&stpeter;
<revision>
<version>1.2rc2</version>
<date>2012-04-17</date>
<version>1.2rc3</version>
<date>2012-05-09</date>
<initials>psa</initials>
<remark>Removed mandates about x- prefix in accordance with IETF recommendations.</remark>
</revision>
@ -98,11 +98,12 @@
<section2 topic='Field Names' anchor='approach-fieldnames'>
<p>For FORM_TYPEs that are registered with the XMPP Registrar, the following rules apply:</p>
<ol>
<li>If the field name is defined by the XSF (i.e., in a XEP), the field name MUST be registered with the XMPP Registrar.</li>
<li>If the field name is defined outside the XSF, the field name MAY be registered with the XMPP Registrar.</li>
<li>If the field is defined by the XSF (i.e., in a XEP), the field name SHALL be determined in accordance with the usual XSF consensus process and the field MUST be registered with the XMPP Registrar.</li>
<li>If the field is defined outside the XSF, the field name SHALL follow the extension rules described below and the field MAY be registered with the XMPP Registrar.</li>
</ol>
<p>If the FORM_TYPE is not registered, the field MAY have any name (managed by the namespace owner).</p>
<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>
<p>For FORM_TYPEs that are not registered with the XMPP Registrar, the field name SHALL follow the extension fules described below and the field typically will not be registered with the XMPP Registrar.</p>
<p>The "namespace" of a field is assumed to be inherited from the FORM_TYPE. When an organization or project defines a field that is used in the context of a FORM_TYPE it does not manage (e.g., a non-XSF field contained in a form whose FORM_TYPE is managed by the XSF, or a third-party field contained in a form whose FORM_TYPE is managed by some other organization), the name of the field MUST be namespaced with a URI controlled by the extending organization or project, where the namespacing mechanism MUST be &clark;, e.g., a field name of "{http://example.com/pubsub}time_restrictions".</p>
<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. However, existing "x-" field names are acceptable and can be registered with the XMPP Registrar as described above.</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>
@ -137,7 +138,7 @@
]]></example>
</section2>
<section2 topic='Correctly Specified FORM_TYPE' anchor='usecases-correct'>
<p>In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', all of the fields whose names start with "pubsub#" are registered with the XMPP Registrar (see &xep0060;), and the custom "time_restrictions" field defined by the organization at example.com uses &clark; in the field name.</p>
<p>In the following example, the FORM_TYPE is 'http://jabber.org/protocol/pubsub', all of the fields whose names start with "pubsub#" are registered with the XMPP Registrar (see &xep0060;), and the custom "time_restrictions" field defined by the organization at example.com uses Clark Notation in the field name.</p>
<example caption='Message with FORM_TYPE'><![CDATA[
<message to="node-owner" from="pubsub.jabber.org">