Jabber User sends IQ-get qualified by the &xep0030; information namespace to the Gateway, and/or IQ-get qualified by the &xep0094; namespace to the Gateway's parent (the latter method is deprecated but still in use).
Jabber User sends IQ-get qualified by the &xep0077; (jabber:iq:register) namespace to Gateway.
Jabber User sends IQ-set qualified by the 'jabber:iq:register' namespace to Gateway, containing information required to register.
Optionally, Jabber User sends IQ-set qualified by the 'jabber:iq:roster' namespace to its server (see &rfc3921;), containing a roster item for Gateway.
Jabber User's client SHOULD approve the subscription request (i.e., by sending a presence stanza of type "subscribed" to Gateway).
Note: As specified in RFC 3921, Jabber User's server will generate a "roster push" at this point if client did not previously perform a roster set to add Gateway to user's roster (as mentioned above).
@@ -305,7 +305,7 @@Jabber User sends subscription request to Gateway (i.e., by sending a presence stanza of type "subscribe" to Gateway).
Execute "Log In" use case.
Jabber User sends IQ-get qualified by the 'jabber:iq:register' namespace to Gateway.
Jabber User sends IQ-set qualified by the 'jabber:iq:register' namespace to Gateway, containing all information (i.e., not just the "delta").
Jabber User sends IQ-set in 'jabber:iq:register' namespace to Gateway, containing empty <remove/> element.
Jabber User's client SHOULD delete from the user's roster (1) the gateway itself, and (2) all legacy Contacts associated with the gateway.
Gateway sends presence stanza to Jabber User expressing availability.
Optionally, Gateway handles Legacy Service contact list; see the Contact Lists section of this document.
Gateway forwards current presence information from Legacy Users to Jabber User, if possible mapping availability status (e.g., "away").
Gateway forwards all subsequent presence stanzas to Legacy Users (except those of type "probe" and those addressed to the Gateway itself).
Use Case Ends.
Gateway passes through directed unavailable presence to Legacy User.
Jabber User sends presence stanza of type "subscribe" to Legacy User.
Note: As specified in RFC 3921, sending this packet will result in a "roster push" from the Server to all of the Jabber User's available resources.
@@ -626,14 +626,14 @@Gateway sends available presence stanza to Jabber User on behalf of Legacy User.
Jabber User sends presence stanza of type "subscribed" to Legacy User.
Use Case Ends unsuccessfully.
Jabber User sends IQ-set qualified by the 'jabber:iq:roster' namespace, containing subscription attribute with value of "remove".
Jabber User sends message stanza to Legacy User.
Jabber User approves subscription request by sending presence stanza of type "subscribed" to Legacy User [A1].
Jabber User's Client sends presence stanza of type "subscribe" to Legacy User.
Gateway sends Legacy User's presence information to Jabber User.
Use Case Ends.
Jabber User sends presence stanza of type "unsubscribed" to Legacy User.
Jabber User's server performs defined functionality for handling presence stanzas of type "unsubscribe" and "unsubscribed" (see RFC 3921).
Gateway transforms message and routes to Jabber User.
Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., <LegacyUser@gateway.jabberserver.com>) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in RFC 3921. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol.
-In order to inform the gateway of the user's desired roster group for the contacts to be sent, the user's client MAY include a field of "group" in the data form it sends when registering with the gateway (if the gateway provides a data form in the registration requirements stanza).
-Some legacy services maintain server-side contact lists, which are sent to the gateway when it logs in to the legacy service on behalf of the user. The gateway MAY initiate adding of the legacy contact list items to the user's Jabber roster. Some existing gateways do this by sending a presence stanza of type "subscribed" from the legacy contact's JID (e.g., <LegacyUser@gateway.jabberserver.com>) to the Jabber user; unfortunately, this behavior violates the presence stanza handling rules specified in RFC 3921. Therefore, a gateway SHOULD instead send the legacy contact list items to the Jabber User via the &xep0144; protocol.
+There are two scenarios for gateway handling of roster groups: either (1) the legacy service does not support groups or (2) the legacy service supports groups.
+If the legacy service does not support categorization of contact list items into groups (equivalent to XMPP roster groups), then a gateway that handles communications with such a legacy service SHOULD enable the user to specify his or her desired roster group for those items by providing a field of "group" in the data form it provides to the user on registration.
+When the gateway sends roster items to the user, it SHOULD then include the specified group.
+However, if the legacy service supports groups, then a gateway that handles communications with such a legacy service SHOULD enable the user to specify his or her desired roster group prefix or suffix for those items by providing fields of both "group" and "groupmodify" in the data form it provides to the user on registration.
+When the gateway sends roster items to the user, it SHOULD then include the group name from the legacy service, prepended or appended with the groupmodify value.
+The following business rules apply:
@@ -1024,6 +1149,32 @@The ®ISTRAR; includes 'jabber:iq:gateway' in its registry of protocol namespaces.
The following fields shall be added to the "jabber:iq:register" FORM_TYPE originally created per XEP-0077.
+
+ jabber:iq:register
+
+
+
+
+
+