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.
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.
Clarified the extensibility rules; removed expiration date; modified schema to document optional inclusion of jabber:x:data and jabber:x:oob information.
Per a vote of the Jabber Council, advanced status to Final; also specified that by server is meant an instant messaging server.
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.
Specified server handling of requests from unregistered entities.
Removed conformance language regarding servers and services (belongs in a protocol suite specification).
Added text about redirection to web registration.
Documented use of <key/> element; added optional stream feature; added XMPP error handling; specified handling of empty passwords.
Moved change password use case from XEP-0078.
Per a vote of the Jabber Council, advanced status to Draft.
Changes to address Council concerns.
Restored the <misc/> and <text/> elements; added the old <key/> element; specified these three elements as obsolete.
Added <registered/> element; specified FORM_TYPE for x:data form; clarified that support for the extensibility mechanism is optional; removed the <misc/> and <text/> elements (not necessary given extensibility option); added <nick/>, <first/>, and <last/> elements that were traditionally documented as part of jabber:iq:register.
Removed XMPP-style error conditions until formats are stable.
Removed "encrypted secret" content, added information about expiration date.
Added "encrypted secret" content.
Slight editorial revisions.
Fixed schema, made minor editorial changes.
Initial version.
The host MUST perform the remove based on the 'from' address of the IQ set, usually matching based on bare JID (<user@domain>). If the entity cancels its registration with a server (not a service), the server SHOULD then return a <not-authorized/> 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).
-Several error cases are possible:
+There are two scenarios:
+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 <not-authorized/> 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).
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 XMPP Core 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.
As specified below, several error cases are possible.
| Condition | Description |
|---|---|
| &badrequest; | The <remove/> element was not the only child element of the <query/> element. |