XEP-0001: add state transition Proposed -> Experimental

Rationale: Sometimes, XEPs linger in Last Call state. This is
probably for the same reason as XEPs which linger in Experimental
state (and then become Deferred). However, currently there is no
way to put Proposed (= Last Call) XEPs back into Experimental state
if one follows the XEP-0001 process by the letter.

This is unfortunate, because it puts council into the position to
either:

- Reject a XEP which is actually useful, but needs work before going
  to Draft, or
- Advance a XEP to Draft which isn’t ready yet, or
- Burn cycles of the Editors and Council on perpetuating a Last
  Call which won’t lead to a conclusion at the current time.

(The "burning" of "cycles" is mostly due to the noise created by
either officially extending the LC all the time, or having a zombie
Proposed XEP hanging around in the list and having to recognize it
as zombie and ignoring it.)

xep-0001.xml

@@ -21,6 +21,12 @@
   <shortname>N/A</shortname>
   &stpeter;
   &dcridland;
+  <revision>
+    <version>1.22.0</version>
+    <date>2018-11-08</date>
+    <initials>jsc</initials>
+    <remark><p>Officially allow moving XEPs back to Experimental after Last Call.</p></remark>
+  </revision>
   <revision>
     <version>1.21.1</version>
     <date>2016-11-16</date>
@@ -290,6 +296,7 @@
 <section1 topic='Approval Process' anchor='approval'>
   <p>The precise mechanism for approval depends on the Approving Body.</p>
   <p>After a XEP has been proposed to the XMPP Council, any change in its status shall be determined by a vote of the XMPP Council. All members of the Council must vote, with the possible values being +1 (approve), 0 (neutral), or -1 (disapprove, with reasons). A XEP shall not be advanced to the next stage in the approval process so long as any Council Member continues to vote -1; that Council Member's written concerns must be addressed in order for the XEP to advance. A majority of Council members must vote +1 in order for a XEP to advance. (Additional voting policies, such as voting periods and defaults if a member does not vote, may be set by the XMPP Council.) A vote of the XMPP Council is final and binding, although a XEP author is free to address the concerns of the Council and to resubmit the XEP for future consideration.</p>
+  <p>If the Approving Body decides after Last Call that the XEP is not ready for advancement yet, but nevertheless useful, it can vote to move it back to Experimental state.</p>
   <p>If the XMPP Council does not complete voting on a XEP before the end of its term, the XMPP Extensions Editor shall issue a new Last Call on the Standards list and the newly-elected Council shall vote anew on the XEP after completion of the Last Call. This provides an opportunity for any member of the previous Council who had voted -1 to voice his or her concerns in a public forum before the new Council votes on the XEP.</p>
   <p>A vote of the XMPP Council applies only to the specific revision of the XEP that has been presented to it. Further revisions may need to be re-submitted for approval.</p>
   <p>Any change in the status of a XEP must be announced on the Standards list by the XMPP Extensions Editor. If a XEP advances to a status of Final, it shall be so announced and also published as one of the official XSF protocols of the XMPP Standards Foundation.</p>
@@ -307,8 +314,8 @@
      |                |
      |                |
 Experimental ----> Proposed ----> Draft ----> Final
-                                    |           |
+     ^                |             |           |
-                                    |           |
+     +----------------+             |           |
                                     +-----------+---> Deprecated
                                                           |
                                                           +--> Obsolete