1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1032 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-07-10 21:24:20 +00:00
parent c75b4bd708
commit d5571c441e

View File

@ -23,119 +23,125 @@
<url>http://www.xmpp.org/schemas/iq-register.xsd</url>
</schemaloc>
&stpeter;
<revision>
<version>2.3pre1</version>
<date>in progress, last updated 2006-07-10</date>
<initials>psa</initials>
<remark><p>Clarified handling of cancellation requests depending on whether receiving entity is a server or a service; corrected mismatch between example and text for cancellation use case.</p></remark>
</revision>
<revision>
<version>2.2</version>
<date>2006-01-24</date>
<initials>psa</initials>
<remark>Further specified integration with data forms, specifically if needed to require additional information when cancelling an existing registration (e.g., username and password) or changing a password (e.g., old password); also clarified server handling of cancelled registrations.</remark>
<remark><p>Further specified integration with data forms, specifically if needed to require additional information when cancelling an existing registration (e.g., username and password) or changing a password (e.g., old password); also clarified server handling of cancelled registrations.</p></remark>
</revision>
<revision>
<version>2.1</version>
<date>2005-07-14</date>
<initials>psa</initials>
<remark>Clarified the extensibility rules; removed expiration date; modified schema to document optional inclusion of jabber:x:data and jabber:x:oob information.</remark>
<remark><p>Clarified the extensibility rules; removed expiration date; modified schema to document optional inclusion of jabber:x:data and jabber:x:oob information.</p></remark>
</revision>
<revision>
<version>2.0</version>
<date>2004-08-30</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced status to Final; also specified that by server is meant an instant messaging server.</remark>
<remark><p>Per a vote of the Jabber Council, advanced status to Final; also specified that by server is meant an instant messaging server.</p></remark>
</revision>
<revision>
<version>1.6</version>
<date>2004-08-23</date>
<initials>psa</initials>
<remark>In order to address Council concerns, clarified precedence order of x:data, iq:register, and x:oob; further specified server handling of initial registration requests from unregistered entities.</remark>
<remark><p>In order to address Council concerns, clarified precedence order of x:data, iq:register, and x:oob; further specified server handling of initial registration requests from unregistered entities.</p></remark>
</revision>
<revision>
<version>1.5</version>
<date>2004-07-21</date>
<initials>psa</initials>
<remark>Specified server handling of requests from unregistered entities.</remark>
<remark><p>Specified server handling of requests from unregistered entities.</p></remark>
</revision>
<revision>
<version>1.4</version>
<date>2004-05-10</date>
<initials>psa</initials>
<remark>Removed conformance language regarding servers and services (belongs in a protocol suite specification).</remark>
<remark><p>Removed conformance language regarding servers and services (belongs in a protocol suite specification).</p></remark>
</revision>
<revision>
<version>1.3</version>
<date>2004-02-24</date>
<initials>psa</initials>
<remark>Added text about redirection to web registration.</remark>
<remark><p>Added text about redirection to web registration.</p></remark>
</revision>
<revision>
<version>1.2</version>
<date>2003-11-26</date>
<initials>psa</initials>
<remark>Documented use of &lt;key/&gt; element; added optional stream feature; added XMPP error handling; specified handling of empty passwords.</remark>
<remark><p>Documented use of &lt;key/&gt; element; added optional stream feature; added XMPP error handling; specified handling of empty passwords.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2003-10-02</date>
<initials>psa</initials>
<remark>Moved change password use case from XEP-0078.</remark>
<remark><p>Moved change password use case from XEP-0078.</p></remark>
</revision>
<revision>
<version>1.0</version>
<date>2003-06-18</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced status to Draft.</remark>
<remark><p>Per a vote of the Jabber Council, advanced status to Draft.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2003-06-18</date>
<initials>psa</initials>
<remark>Changes to address Council concerns.</remark>
<remark><p>Changes to address Council concerns.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2003-06-13</date>
<initials>psa</initials>
<remark>Restored the &lt;misc/&gt; and &lt;text/&gt; elements; added the old &lt;key/&gt; element; specified these three elements as obsolete.</remark>
<remark><p>Restored the &lt;misc/&gt; and &lt;text/&gt; elements; added the old &lt;key/&gt; element; specified these three elements as obsolete.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2003-06-12</date>
<initials>psa</initials>
<remark>Added &lt;registered/&gt; element; specified FORM_TYPE for x:data form; clarified that support for the extensibility mechanism is optional; removed the &lt;misc/&gt; and &lt;text/&gt; elements (not necessary given extensibility option); added &lt;nick/&gt;, &lt;first/&gt;, and &lt;last/&gt; elements that were traditionally documented as part of jabber:iq:register.</remark>
<remark><p>Added &lt;registered/&gt; element; specified FORM_TYPE for x:data form; clarified that support for the extensibility mechanism is optional; removed the &lt;misc/&gt; and &lt;text/&gt; elements (not necessary given extensibility option); added &lt;nick/&gt;, &lt;first/&gt;, and &lt;last/&gt; elements that were traditionally documented as part of jabber:iq:register.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2003-06-06</date>
<initials>psa</initials>
<remark>Removed XMPP-style error conditions until formats are stable.</remark>
<remark><p>Removed XMPP-style error conditions until formats are stable.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2003-05-30</date>
<initials>psa</initials>
<remark>Removed "encrypted secret" content, added information about expiration date.</remark>
<remark><p>Removed "encrypted secret" content, added information about expiration date.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2003-05-28</date>
<initials>psa</initials>
<remark>Added "encrypted secret" content.</remark>
<remark><p>Added "encrypted secret" content.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-05-20</date>
<initials>psa</initials>
<remark>Slight editorial revisions.</remark>
<remark><p>Slight editorial revisions.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-04-29</date>
<initials>psa</initials>
<remark>Fixed schema, made minor editorial changes.</remark>
<remark><p>Fixed schema, made minor editorial changes.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2003-04-06</date>
<initials>psa</initials>
<remark>Initial version.</remark>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
@ -311,8 +317,12 @@
<example caption='Host Informs Entity of Successful Cancellation'><![CDATA[
<iq type='result' to='bill@shakespeare.lit/globe' id='unreg1'/>
]]></example>
<p>The host MUST perform the remove based on the 'from' address of the IQ set, usually matching based on bare JID (&lt;user@domain&gt;). If the entity cancels its registration with a server (not a service), the server SHOULD then return a &lt;not-authorized/&gt; stream error and terminate all active sessions for the entity. If the server is an instant messaging and presence server that conforms to &rfc3921;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).</p>
<p>Several error cases are possible:</p>
<p>There are two scenarios:</p>
<ol>
<li><p>If the entity cancels its registration with its "home" server (i.e., the server at which it has maintained its XMPP account), then the entity SHOULD NOT include a 'from' or 'to' address in the remove request the server SHOULD then return a &lt;not-authorized/&gt; stream error and terminate all active sessions for the entity. The server SHOULD perform the remove based on the bare JID (&BAREJID;) associated with the current session or connection over which it received the remove request. If the server is an instant messaging and presence server that conforms to &rfc3921;, the server SHOULD also cancel all existing presence subscriptions related to that entity (as stored in the entity's roster).</p></li>
<li><p>If the entity cancels its registration with a service other than its home server, its home server MUST stamp a 'from' address on the remove request, which in accordance with <cite>XMPP Core</cite> will be the entity's full JID (&FULLJID;). The service MUST perform the remove based on the bare JID (&BAREJID;) portion of the 'from' address.</p></li>
</ol>
<p>As specified below, several error cases are possible.</p>
<table caption='Unregister Error Cases'>
<tr><th>Condition</th><th>Description</th></tr>
<tr><td>&badrequest;</td><td>The &lt;remove/&gt; element was not the only child element of the &lt;query/&gt; element.</td></tr>
@ -328,10 +338,10 @@
</error>
</iq>
]]></example>
<example caption='Host Informs Client of Failed Cancellation (Not Authorized)'><![CDATA[
<example caption='Host Informs Client of Failed Cancellation (Forbidden)'><![CDATA[
<iq type='error' from='shakespeare.lit' to='bill@shakespeare.lit/globe' id='unreg1'>
<error code='401' type='cancel'>
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>