When a server receives a stanza for a delegated namespace which is either directed to him (no 'to' attribute, or 'to' attribute with its own JID), or directed to the bare JID of the sender (e.g. if 'from' attribute is "juliet@capulet.lit/balcony" and 'to' attribute is "juliet@capulet.lit"), it MUST forward it to the managing entity by replacing the 'to' attribute with the JID of the managing entity:
+When a server receives a stanza for a delegated namespace which is either directed to him (no 'to' attribute, or 'to' attribute with its own JID), or directed to any bare jid (and only bare jid) that it manages (i.e. the domainpart is a domain handled by the server where delegation is activated), it MUST forwards it to the managing entity:
The server gets this stanza, sees that this namespace is delegated to pubsub.capulet.lit, so it forwards it.
-To forward, an &IQ; stanza of type "set" is used which contain a <delegation/> element (with namespace'urn:xmpp:delegation:1') which in turn contain a <forwarded/> element encapsulating the initial stanza, according to &xep0297;:
+To forward, an &IQ; stanza of type "set" is used which contain a <delegation/> element (with namespace 'urn:xmpp:delegation:1') which in turn contain a <forwarded/> element encapsulating the initial stanza, according to &xep0297;:
The workflow is fully transparent for Juliet.
N.B.₁: If the server encounter a delegated namespace and the managing entity is not available, it MUST return an &IQ; stanza of type "error" with an error condition of <service-unavailable/>
-N.B.₂: If the server encounter a delegated namespace but the filtering attribute does not match, it MUST follow its normal behaviour, i.e. it must follow the same behaviour it would have had if the namespace was not delegated at all
+N.B.₂: Similarly, if the managing entity return an &IQ; stanza of type "error", the server must return itself an &IQ; stanza of type "error" with an error condition of <service-unavailable/>
+N.B.₃: If the server encounter a delegated namespace but the filtering attribute does not match, it MUST follow its normal behaviour, i.e. it must follow the same behaviour it would have had if the namespace was not delegated at all
If a stanza is sent by the managing entity on a managed namespace, the server MUST NOT forward it. This way, the managing entity can use privileged entity to do special treatments.
+If a stanza is sent by the managing entity on a managed namespace, the server MUST NOT forward it. This way, the managing entity can use privileged entity to do specific treatments, a kind of universal plugin (i.e. working with all servers implementing &xep0355; and &xep0356;).
In the following examples, juliet@capulet.lit has its "jabber:iq:roster" namespace delegated to filter.capulet.lit. filter.capulet.lit is a server agnostic component which filters allowed entities (which can be added to a roster), and sort them in enforced groups.
The managing entity can now manage the namespace the same way as in admin mode.
+The managing entity can now manage the namespace in a similar way as in admin mode but with different rules:
+When a server delegates a namespace to a managing entity, the later can have particular features which must be advertised by the former with disco protocol.
-This is done by using a disco node, which is done the following way: if pubsub.capulet.int manages pubsub namespace, it MUST report that fact in discovery feature, and have a 'urn:xmpp:delegation:1::http://jabber.org/protocol/pubsub' node which reports the managed features.
The node name is obtained by concatenating this XEP namespace (urn:xmpp:delegation:1), a '::' separator, and the delegated namespace (here http://jabber.org/protocol/pubsub).
The server MUST advertise the result in its own discovery answer, and MUST ignore features of its internal component (here internal PubSub service).
This is done by using a disco node, which is built in the following way: if pubsub.capulet.int manages pubsub namespace, it MUST report that fact in discovery feature, and have a 'urn:xmpp:delegation:1::http://jabber.org/protocol/pubsub' node which reports the managed features.
The node name is obtained by concatenating this XEP namespace (urn:xmpp:delegation:1), a '::' separator, and the delegated namespace (here http://jabber.org/protocol/pubsub).
The server MUST advertise the result in its own discovery answer, and MUST ignore features of its internal component (here internal PubSub service).
In the following example, the capulet.int server delegates its internal PEP component to pubsub.capulet.int. capulet.int only supports REQUIRED PubSub features and auto-create, while pubsub.capulet.int supports REQUIRED PubSub features and publish-options, but not auto-create.
juliet@capulet.int asks its server what it is capable of, she is specially interested in PubSub capabilities.
Extensions of Service Discovery as specified in &xep0128; follow the same rules: for the delegated namespace, internal extensions MUST be removed and extensions of managing entity MUST be included instead.
+This XEP is linked with &xep0356; and works in a similar way.
The client mode delegation mechanism is inspired from &xep0321; permission request.
Thanks to Adrien Cossa for his typos/style corrections
-Thanks to Philipp Hancke, Dave Cridland, Kurt Zeilenga and Sergey Dobrov for their feedbacks.
+Thanks to Philipp Hancke, Dave Cridland, Kurt Zeilenga, Sergey Dobrov and Анна Мухаррам for their feedbacks.