Merge pull request #222 from Flowdalic/xep355v3

Update XEP-0355: 'Namespace Delegation' to 0.3

xep-0355.xml

@@ -29,6 +29,24 @@
     <jid>goffi@jabber.fr</jid>
   </author>
 
+  <revision>
+    <version>0.3</version>
+    <date>2016-08-01</date>
+    <initials>jp</initials>
+    <remark>
+        <ul>
+            <li>added "Delegating server" in glossary</li>
+            <li>fixed <link url='#stanza_forward'>server forwarding</link> conditions</li>
+            <li>fixed missing 'jabber:client' namespaces</li>
+            <li>&lt;service-unavailable/&gt; on managing entity &IQ; error</li>
+            <li>forwarding in client mode is now specified</li>
+            <li>removed wrong 'node' attribute in disco nesting example</li> 
+            <li>disco extension explicitly need to be handled</li>
+            <li>minor typos/explanation improvments</li>
+        </ul>
+    </remark>
+  </revision>
+
   <revision>
     <version>0.2.1</version>
     <date>2015-10-15</date>
@@ -96,6 +114,7 @@
     <li><strong>Delegated namespace</strong> — the namespace being managed by an external entity.</li>
     <li><strong>Filtering attribute</strong> — an attribute which must be present in first &IQ; child element to delegate the namespace.</li>
     <li><strong>Managing entity</strong> — the entity which actualy manages the delegated namespace.</li>
+    <li><strong>Delegating server</strong> — the server which delegate the stanzas to the managing entity.</li>
     <li><strong>Managed entity</strong> — an entity which wants to have a namespace of its server delegated to a managing entity.</li>
   </ul>
 </section1>
@@ -127,7 +146,7 @@
     </section2>
 
     <section2 topic='Server Forwards Delegated &IQ; Stanza' anchor='stanza_forward'>
-        <p>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 "<em>juliet@capulet.lit/balcony</em>" and 'to' attribute is "<em>juliet@capulet.lit</em>"), it MUST forward it to the managing entity by replacing the 'to' attribute with the JID of the managing entity:</p>
+        <p>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 <em>domainpart</em> is a domain handled by the server where delegation is activated), it MUST forwards it to the managing entity:</p>
             <example caption='Juliet sends her mood to her server via PEP'><![CDATA[
 <iq from='juliet@capulet.lit/balcony'
     id='pep1'
@@ -145,7 +164,7 @@
 </iq>
 ]]></example>
 <p>The server gets this stanza, sees that this namespace is delegated to <em>pubsub.capulet.lit</em>, so it forwards it.</p>
-<p>To forward, an &IQ; stanza of type "set" is used which contain a &lt;delegation/&gt; element (with namespace<em>'urn:xmpp:delegation:1'</em>) which in turn contain a &lt;forwarded/&gt; element encapsulating the initial stanza, according to  &xep0297;:</p>
+<p>To forward, an &IQ; stanza of type "set" is used which contain a &lt;delegation/&gt; element (with namespace <em>'urn:xmpp:delegation:1'</em>) which in turn contain a &lt;forwarded/&gt; element encapsulating the initial stanza, according to  &xep0297;:</p>
 
 <example caption='server delegate the stanza to pubsub.capulet.lit'><![CDATA[
 <iq from='capulet.lit'
@@ -156,7 +175,8 @@
         <forwarded xmlns='urn:xmpp:forward:0'>
             <iq from='juliet@capulet.lit/balcony'
                 id='pep1'
-                type='set'>
+                type='set'
+                xmlns='jabber:client'>
                 <pubsub xmlns='http://jabber.org/protocol/pubsub'>
                     <publish node='http://jabber.org/protocol/mood'>
                     <item>
@@ -182,7 +202,8 @@
         <forwarded xmlns='urn:xmpp:forward:0'>
             <iq to='juliet@capulet.lit/balcony'
                 id='pep1'
-                type='result'>
+                type='result'
+                xmlns='jabber:client'>
                 <pubsub xmlns='http://jabber.org/protocol/pubsub' />
             </iq>
         </forwarded>
@@ -203,9 +224,10 @@
 
     <p>The workflow is fully transparent for Juliet.</p>
     <p><strong>N.B.&#8321;:</strong> 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 &lt;service-unavailable/&gt;</p>
-    <p><strong>N.B.&#8322;:</strong> 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</p>
+    <p><strong>N.B.&#8322;:</strong> 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 &lt;service-unavailable/&gt;</p>
+    <p><strong>N.B.&#8323;:</strong> 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</p>
     <section3 topic='Stanzas from managing entity' anchor='managing_entity_stanzas'>
-        <p>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.</p>
+        <p>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;).</p>
         <p>In the following examples, <em>juliet@capulet.lit</em> has its "<em>jabber:iq:roster</em>" namespace delegated to <em>filter.capulet.lit</em>. <em>filter.capulet.lit</em> is a server agnostic component which filters allowed entities (which can be added to a roster), and sort them in enforced groups.</p>
 
         <example caption='Juliet adds Romeo to her roster'><![CDATA[
@@ -229,7 +251,8 @@
         <forwarded xmlns='urn:xmpp:forward:0'>
             <iq from='juliet@capulet.lit/balcony'
                       id='roster1'
-                      type='set'>
+                      type='set'
+                      xmlns='jabber:client'>
                 <query xmlns='jabber:iq:roster'>
                     <item jid='romeo@montaigu.lit'
                           name='My Romeo'>
@@ -251,7 +274,8 @@
         <forwarded xmlns='urn:xmpp:forward:0'>
             <iq to='juliet@capulet.lit/balcony'
                 id='roster1'
-                type='result' />
+                type='result'
+                xmlns='jabber:client' />
         </forwarded>
     </delegation>
 </iq>
@@ -363,7 +387,14 @@
     </delegation>
 </message>
 ]]></example>
-        <p>The managing entity can now manage the namespace the same way as in <link url='#stanza_forward'>admin mode</link>.</p>
+    </section2>
+    <section2 topic='Server Forward Stanza' anchor='client_forward'>
+    <p>The managing entity can now manage the namespace in a similar way as in <link url='#stanza_forward'>admin mode</link> but with different rules:</p> 
+        <ol>
+            <li>if the stanza is directed to the delegating server (no 'to' attribute, or 'to' attribute with the server own JID), <strong>and</strong> the 'from' attribute belong to a managed entity (e.g. <em>juliet@capulet.lit/balcony</em> if <em>juliet@capulet.lit</em> is a managed entity) <strong>and</strong> the namespace of the stanza has been delegated by the managed entity, then the delegating server MUST forward it to the managing entity accepted by the managed entity, in the same way as in <link url='#stanza_forward'>admin mode</link>.</li>
+            <li>if the stanza is directed to the bare jid (and only the bare jid) of the managed entity (e.g. the 'to' attribute is set to <em>juliet@capulet.lit</em> and the namespace has been delegated by the managed entity, then the server MUST forward it to the managing entity accepted by the managed entity, in the same way as in <link url='#stanza_forward'>admin mode</link>, for any 'from' attribute but the jid of the managing entity.</li>
+            <li>in all other cases, the server MUST NOT forward the stanza</li>
+        </ol>
     </section2>
 
 </section1>
@@ -400,7 +431,7 @@
     <section2 topic='Nesting' anchor='disco_nesting'>
     <section3 topic='General Case'>
         <p>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.</p>
-        <p>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 '<strong>urn:xmpp:delegation:1::http://jabber.org/protocol/pubsub</strong>' node which reports the managed features.</p><p>The node name is obtained by concatenating this XEP namespace (<strong>urn:xmpp:delegation:1</strong>), a '<strong>::</strong>' separator, and the delegated namespace (here <strong>http://jabber.org/protocol/pubsub</strong>).<br/>The server MUST advertise the result in its own discovery answer, and MUST ignore features of its internal component (here internal PubSub service).</p>
+        <p>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 '<strong>urn:xmpp:delegation:1::http://jabber.org/protocol/pubsub</strong>' node which reports the managed features.</p><p>The node name is obtained by concatenating this XEP namespace (<strong>urn:xmpp:delegation:1</strong>), a '<strong>::</strong>' separator, and the delegated namespace (here <strong>http://jabber.org/protocol/pubsub</strong>).<br/>The server MUST advertise the result in its own discovery answer, and MUST ignore features of its internal component (here internal PubSub service).</p>
 <p>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. <br/>juliet@capulet.int asks its server what it is capable of, she is specially interested in PubSub capabilities.</p>
 <example caption="Juliet asks her server its available features"><![CDATA[
 <iq from='juliet@capulet.lit/balcony'
@@ -445,8 +476,7 @@
     id='disco1'
     to='juliet@capulet.lit/balcony'
     type='result'>
-  <query xmlns='http://jabber.org/protocol/disco#info'
+  <query xmlns='http://jabber.org/protocol/disco#info'>
-         node='urn:xmpp:delegation:1::http://jabber.org/protocol/pubsub'>
         <feature var='urn:xmpp:delegation:1'/>
         ...
         <feature var='http://jabber.org/protocol/pubsub'/>
@@ -538,6 +568,9 @@
 </example>
 
     </section3>
+    <section3 topic='Service Discovery Extensions'>
+        <p>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.</p>
+    </section3>
     </section2>
 </section1>
 
@@ -546,7 +579,7 @@
         <li>In client mode, server MAY keep delegations granted to an entity by a client from one session to an other, but if it does so, it MUST provide configuration like explained in the <link url='#configuration'>suitable section</link>. If server offers this feature, it SHOULD add a field directly in configuration commands.</li>
         <li>If a client can't check or revoke delegations (i.e. it doesn't support &xep0050;) when granting them, the server MUST NOT keep granted delegations from one session to an other, and delegations will be asked on each new session.</li>
         <li>If delegations are changed during a session, server MUST notify managing entity of the new delegations, like in <link url='#client_delegation'>client delegation request use case</link>.</li>
-        <li>If delegations are kept between sessions in client mode, and the managing entity is not available, the server MUST return an &IQ; error with condition &lt;service-unavailable/&gt; when a delegated namespace is requested, like explained in <link url='#stanza_forward'>"Server Forwards Delegated &IQ; Stanza" section</link>.</li>
+        <li>If delegations are kept between sessions in client mode, and the managing entity is not available or return an error, the server MUST return an &IQ; error with condition &lt;service-unavailable/&gt; when a delegated namespace is requested, like explained in <link url='#stanza_forward'>"Server Forwards Delegated &IQ; Stanza" section</link>.</li>
         <li>The namespace of this XEP (<strong>urn:xmpp:delegation:1</strong>) MUST NOT be delegated. If an entity requests it, the server MUST return a &forbidden; error.</li>
     </ol>
 </section1>
@@ -633,6 +666,6 @@
   <p>This XEP is linked with &xep0356; and works in a similar way.</p>
   <p>The client mode delegation mechanism is inspired from &xep0321; permission request.</p>
   <p>Thanks to Adrien Cossa for his typos/style corrections</p>
-  <p>Thanks to Philipp Hancke, Dave Cridland, Kurt Zeilenga and Sergey Dobrov for their feedbacks.</p>
+  <p>Thanks to Philipp Hancke, Dave Cridland, Kurt Zeilenga, Sergey Dobrov and Анна Мухаррам for their feedbacks.</p>
 </section1>
 </xep>