diff --git a/xep-0320.xml b/xep-0320.xml index 6dae5254..58412a49 100644 --- a/xep-0320.xml +++ b/xep-0320.xml @@ -9,8 +9,8 @@
Initial published version approved by the XMPP Council.
First draft.
It's often desirable for some XMPP based services to make it possible to manage user's roster to provide some contacts there. The most obvious example of such kind of service is a gateway to some legacy IM system (see &xep0100;). The current way that's recommended by the &xep0100; is to use the &xep0144; to synchronize items that's not sutiable in certain situations.
-This document addresses the following requirements:
-In order to be able to make any changes to the user's roster the remote entity MUST ask permission to do so first.
-NOTE: in order to be able to perform the query, the remote entity MUST have a presence subscription to the User
-If the presence subscription is absent, the server MUST NOT proceed with the request but MUST respond with the "forbidden" error:
-The user's server SHOULD then generate a form request using &xep0004; to client in order to ask user if he's OK with granting the permission to the remote entity. The "challenge" form field is generated by the server and is used to identify the client's response. The server also MUST immediatly answer to the request IQ.
-NOTE: if the entity is already granted with the permission, the server SHOULD immediatly answer with a success response and skip querying the user.
-The client can answer by submit the form or with a text message response:
-If the user allowed the roster management then the server MUST inform the remote entity that it has been granted the permission:
-If the user disallowed the roster management then the server MUST inform the remote entity that it hasn't been granted the permission:
-In order to reject the permission to manage roster it's enough to reject entity's presence subscription:
-If the presence subscription is restored then the permission is needed to be rerequested as defined above.
-The remote entity being granted the permission to manage roster can request it from the User's server using usual jabber:iq:roster protocol to be able to edit it:
-The server MUST then answer with User's roster including there only the items that belongs to the entity's hostname:
-If client updates roster and this update affects the remote entity's contacts (i.e. belongs to it's hostname) then the server MUST forward these items to the remote entity:
-The remote entity can also send the push query to the roster with the same semantics as specified for the jabber:iq:roster protocol described in the &rfc6121;:
-The server MUST then inform the remote entity of success or an error and in the case of success also forward the push request to all connected User's resources.
-If the entity tries to make changes into the items it's not allowed to, the server MUST NOT do any changes in the User's roster but respond to the entity with an error:
-User can ask the server to provide a list of components or servers which have permissions to edit their roster.
-In this case, server responds with list of components or servers which can edit user's roster.
-Eventually, user can reject permission granted to component to edit their roster.
- -
-
-
-
-
-
- The protocol documented by this schema is defined in
- XEP-XXXX: http://www.xmpp.org/extensions/xep-xxxx.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ]]>
-Initial published version approved by the XMPP Council.
First draft.
It's often desirable for some XMPP based services to make it possible to manage user's roster to provide some contacts there. The most obvious example of such kind of service is a gateway to some legacy IM system (see &xep0100;). The current way that's recommended by the &xep0100; is to use the &xep0144; to synchronize items that's not sutiable in certain situations.
+This document addresses the following requirements:
+In order to be able to make any changes to the user's roster the remote entity MUST ask permission to do so first.
+NOTE: in order to be able to perform the query, the remote entity MUST have a presence subscription to the User
+If the presence subscription is absent, the server MUST NOT proceed with the request but MUST respond with the "forbidden" error:
+The user's server SHOULD then generate a form request using &xep0004; to client in order to ask user if he's OK with granting the permission to the remote entity. The "challenge" form field is generated by the server and is used to identify the client's response. The server also MUST immediatly answer to the request IQ.
+NOTE: if the entity is already granted with the permission, the server SHOULD immediatly answer with a success response and skip querying the user.
+The client can answer by submit the form or with a text message response:
+If the user allowed the roster management then the server MUST inform the remote entity that it has been granted the permission:
+If the user disallowed the roster management then the server MUST inform the remote entity that it hasn't been granted the permission:
+In order to reject the permission to manage roster it's enough to reject entity's presence subscription:
+If the presence subscription is restored then the permission is needed to be rerequested as defined above.
+The remote entity being granted the permission to manage roster can request it from the User's server using usual jabber:iq:roster protocol to be able to edit it:
+The server MUST then answer with User's roster including there only the items that belongs to the entity's hostname:
+If client updates roster and this update affects the remote entity's contacts (i.e. belongs to it's hostname) then the server MUST forward these items to the remote entity:
+The remote entity can also send the push query to the roster with the same semantics as specified for the jabber:iq:roster protocol described in the &rfc6121;:
+The server MUST then inform the remote entity of success or an error and in the case of success also forward the push request to all connected User's resources.
+If the entity tries to make changes into the items it's not allowed to, the server MUST NOT do any changes in the User's roster but respond to the entity with an error:
+User can ask the server to provide a list of components or servers which have permissions to edit their roster.
+In this case, server responds with list of components or servers which can edit user's roster.
+Eventually, user can reject permission granted to component to edit their roster.
+ +
+
+
+
+
+
+ The protocol documented by this schema is defined in
+ XEP-XXXX: http://www.xmpp.org/extensions/xep-xxxx.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+Initial published version approved by the XMPP Council.
Thanks to Joachim Lindborg, Yusuke Doi, Takuki Kamiya, Tina Beckman, Karin Forsell, Jeff Freund and Rumen Kyusakov for all valuable feedback.
Initial published version approved by the XMPP Council.
Thanks to Joachim Lindborg, Karin Forsell, Tina Beckman, Kevin Smith and Tobias Markmann for all valuable feedback.
Initial published version approved by the XMPP Council.
Thanks to Joachim Lindborg and Karin Forsell for all valuable feedback.