moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

0.3

Browse Source
This commit is contained in:
stpeter 2011-12-12 16:25:57 -07:00
parent 7b644b95cf
commit 488f039137
1 changed files with 50 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
xep-0267.xml
View File

@ -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>