1.2pre1

xep-0068.xml

@@ -23,6 +23,12 @@
   <registry/>
   &hildjj;
   &stpeter;
+  <revision>
+    <version>1.2pre1</version>
+    <date>2011-10-18</date>
+    <initials>psa</initials>
+    <remark>Removed mandates about x- prefix.</remark>
+  </revision>
   <revision>
     <version>1.1</version>
     <date>2004-07-07</date>
@@ -83,23 +89,24 @@
           <li>If the FORM_TYPE is used in the context of a custom protocol, it MAY be registered.</li>
         </ol>
     </section2>
-    <section2 topic='Naming Convention' anchor='approach-naming'>
+    <section2 topic='FORM_TYPE Names' anchor='approach-formtypes'>
         <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".</li>
+          <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 an HTTP URI or IETF-style URN.</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>
         </ol>
     </section2>
     <section2 topic='Field Names' anchor='approach-fieldnames'>
-        <p>For FORM_TYPEs that are registered with the XMPP Registrar, the field names MUST conform to one of the following two conditions:</p>
+        <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 relevant XEP or by registration, the field name MUST be registered with the XMPP Registrar and MAY have any name (except a name that begins with "x-"), subject to approval by the XMPP Registrar.</li>
+          <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 unregistered, the field name MUST begin with "x-".</li>
+          <li>If the field name is defined outside the XSF, the field name MAY be registered with the XMPP Registrar.</li>
         </ol>
-        <p>If the FORM_TYPE is not registered, the field name MAY have any name (presumably managed by the namespace "owner").</p>
+        <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>
     </section2>
-    <section2 topic='Field Values' anchor='approach-values'>
+    <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>
     </section2>
 </section1>
@@ -132,7 +139,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', and all of the fields whose var names start with "pubsub#" would be registered with the XMPP Registrar, associated with that namespace.</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; in the field name.</p>
 
       <example caption='Message with FORM_TYPE'><![CDATA[
 <message to="node-owner" from="pubsub.jabber.org">
@@ -151,7 +158,7 @@
               label="Jabber ID of Subscriber">
            <value>sub1@foo.com</value>
        </field>
-       <field var="x-time_restrictions" type="text-multi" 
+       <field var="{http://example.com/pubsub}time_restrictions" type="text-multi" 
               label="Limit to these time ranges">
            <value>09:00-12:00</value>
            <value>13:00-17:00</value>
@@ -161,15 +168,15 @@
       ]]></example>
     </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, 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">
     <x xmlns="jabber:x:data" type="form">
        <title>Balcony Scene (Act 2, Scene 2)</title>
        <instructions>But soft! What light through yonder window breaks?</instructions>
-       <!-- Not hidden.  Treated as any other text-single field: -->
+       <!-- Not hidden.  Treated as any other text-single field. -->
        <field var="FORM_TYPE" type="text-single">
          <value>http://jabber.org/protocol/shakespeare</value>
        </field>
@@ -179,34 +186,6 @@
            <option label="Eyes">Stars</option>
        </field>
     </x>
-</message>
-      ]]></example>
-  </section2>
-  <section2 topic='Message with Bad Field' anchor='usecases-badfield'>
-    <p>When a FORM_TYPE is specified correctly, and an unknown field is found whose name does not start with "x-", a receiver MAY respond with an "Not Acceptable" error.</p>
-      <example caption='Message with bad field'><![CDATA[
-<message to="juliet@capulet.com" from="romeo@montague.net/garden">
-    <x xmlns="jabber:x:data" type="form">
-       <title>Balcony Scene (Act 2, Scene 2)</title>
-       <instructions>But soft! What light through yonder window breaks?</instructions>
-       <field var="FORM_TYPE" type="hidden">
-           <value>http://jabber.org/protocol/shakespeare</value>
-       </field>
-       <field var="light" type="list-multi">
-           <option label="Juliet">Sun</option>
-           <option lable="Maid">Moon</option>
-           <option label="Eyes">Stars</option>
-       </field>
-    </x>
-</message>
-
-<message from="juliet@capulet.com" to="romeo@montague.net/garden" type="error">
-  <error code="406" type='modify'>
-    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
-    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
-      The field "light" is not acceptable.
-    </text>
-  </error>
 </message>
       ]]></example>
   </section2>
@@ -317,16 +296,12 @@
     <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>
 
-<section1 topic='Error Codes' anchor='errors'>
-  <p>If the receiving entity believes that a specified field is invalid for the given FORM_TYPE, the receiver MAY respond to the sender with a "Not Acceptable" error; alternatively, the receiver MAY choose to ignore unknown fields.</p>
-</section1>
-
 <section1 topic='Security Considerations' anchor='security'>
-  <p>Security-conscious programs that are using this approach should be careful to process only agreed-upon fields, with agreed-upon types, or "x-" fields that are understood by a particular implementation and a user of that implementation.</p>
+  <p>Security-conscious programs that are using this approach should be careful to process only agreed-upon fields with agreed-upon types.</p>
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>
-  <p>This document requires no interaction with &IANA; for now.  However, if this document is submitted to the IETF later, IANA should be used to standardize the field names rather than the XMPP Registrar.</p>
+  <p>This document requires no interaction with &IANA; for now.</p>
 </section1>
 
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>