0.3

xep-0267.xml

@@ -45,6 +45,12 @@
     <email>mwild1@gmail.com</email>
     <jid>mwild1@jaim.at</jid>
   </author>
+  <revision>
+    <version>0.4</version>
+    <date>2011-12-12</date>
+    <initials>psa</initials>
+    <remark><p>Noted that sending server can be derived from 'to' address on IQ stanza, so removed serverjid field from FORM_TYPE; defined method for determining support; added further XMPP Registrar Considerations.</p></remark>
+  </revision>
   <revision>
     <version>0.3</version>
     <date>2011-12-12</date>
@@ -93,6 +99,12 @@
           to='montague.lit'
           type='subscribe'/>
   ]]></example>
+  <p>The originating server would then approve that subscription request.</p>
+  <example caption="Services sends approval to peer"><![CDATA[
+<presence from='montague.lit'
+          to='capulet.lit'
+          type='subscribed'/>
+  ]]></example>
   <p>If an XMPP server implementation supports this usage of presence subscriptions, it MUST keep a list of approved entities, which we denote a "server roster". The implementation MAY use that roster for access control purposes defined in other specifications.</p>
 </section1>
 
@@ -128,10 +140,6 @@
       <field type='hidden' var='FORM_TYPE'>
         <value>http://jabber.org/protocol/admin</value>
       </field>
-      <field label='The domain name of your server'
-             type='jid-single'
-             var='serverjid'>
-      </field>
       <field label='The domain name of the peer server'
              type='jid-single'
              var='peerjid'>
@@ -141,7 +149,7 @@
   </command>
 </iq>
     ]]></example>
-    <p>Note: the form includes a field for the domain name of the sending server to support virtual hosting environments.</p>
+    <p>Note: In virtual hosting environments, the server can determine the the domain name from which to send the presence subscription based on the 'to' address of the &IQ; stanza.</p>
     <example caption='Admin Submits Server Buddy Form to Service'><![CDATA[
 <iq from='bard@shakespeare.lit/globe'
     id='server-buddy-2'
@@ -180,15 +188,46 @@
   <p>Notification of completion MAY include the processed data in a data form of type "result".</p>
 </section1>
 
+<section1 topic='Determining Support' anchor='support'>
+  <p>To advertise its support for the server buddy feature, when replying to service discovery information ("disco#info") requests a server MUST return a URNs "urn:xmpp:server-presence".</p>
+  <example caption="Service discovery information request"><![CDATA[
+<iq from='jabber.org'
+    id='uw72g176'
+    to='xmpp.net'
+    type='get'>
+  <query xmlns='http://jabber.org/protocol/disco#info'/>
+</iq>
+  ]]></example>
+  <example caption="Service discovery information response"><![CDATA[
+<iq from='xmpp.net'
+    id='uw72g176'
+    to='jabber.org'
+    type='result'>
+  <query xmlns='http://jabber.org/protocol/disco#info'>
+    <feature var='urn:xmpp:server-presence'/>
+  </query>
+</iq>
+  ]]></example>
+</section1>
+
 <section1 topic='Security Considerations' anchor='security'>
-  <p>Because server "buddies" might be granted greater privileges than unknown peers, care should be taken in sending or approving presence subscription requests.</p>
+  <p>Because server "buddies" might be granted greater privileges than unknown peers, care should be taken in sending or approving presence subscription requests. In particular, a server MUST NOT send a presence subscription request unless explicitly requested to do so by a server administrator.</p>
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>
   <p>This document requires no interaction with &IANA;.</p> 
 </section1>
 
-<section1 topic='XMPP Registrar Considerations' anchor='reg'>
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+  <section2 topic='Service Discovery Features' anchor='registrar-features'>
+    <code caption='Registry Submission'><![CDATA[
+<var>
+  <name>urn:xmpp:server-presence</name>
+  <desc>Support for subscriptions to server presence</desc>
+  <doc>XEP-0267</doc>
+</var>
+    ]]></code>
+  </section2>
   <section2 topic='Field Standardization' anchor='registrar-formtype'>
     <p>&xep0068; defines a process for standardizing the fields used within Data Forms scoped by a particular namespace. This registration adds two more reserved fields to the 'http://jabber.org/protocol/admin' namespace defined in XEP-0133.</p>
     <code caption='Registry Submission'><![CDATA[
@@ -197,12 +236,13 @@
   <field var='peerjid'
          type='jid-single'
          label='The Jabber ID of a peer server'/>
-  <field var='serverjid'
-         type='jid-single'
-         label='The Jabber ID of the server being administered'/>
 </form_type>
     ]]></code>
   </section2>
 </section1>
 
+<section1 topic='Acknowledgements' anchor='ack'>
+  <p>Thanks to Kim Alvefur, Waqas Hussain, and Tobias Markmann for their feedback.</p>
+</section1>
+
 </xep>