moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 15:18:51 -05:00
Code Issues Releases Wiki Activity

0.5

Browse Source
This commit is contained in:
Peter Saint-Andre 2012-05-29 19:08:00 -06:00
parent 1e388cd96c
commit a46bf68d67
1 changed files with 15 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
xep-0267.xml Normal file → Executable file
View File

@ -45,6 +45,12 @@
<email>mwild1@gmail.com</email>
<jid>mwild1@jaim.at</jid>
</author>
<revision>
<version>0.5</version>
<date>2012-05-29</date>
<initials>psa</initials>
<remark><p>Corrected several examples and points in the text.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2011-12-12</date>
@ -78,7 +84,7 @@
</header>
<section1 topic='Description' anchor='description'>
<p>In XMPP, rosters and presence subscriptions have been used to date only among IM users (see &xmppim;). However, nothing prevents the application of these concepts to other XMPP entities, such as components and servers. Given that a presence subscription typically indicates some level of trust in a peer, server deployments can use the sharing of XMPP presence information as a way to indicate that a given server has a trust relationship with a peer server (informally, we can say that the two servers consider each other "buddies"). The server might then share certain kinds of additional information only with its trusted peers, for example &xep0268;.</p>
<p>In XMPP, rosters and presence subscriptions have been used to date only among IM users (see &xmppim;). However, nothing prevents the application of these concepts to other XMPP entities, such as components and servers. Given that a presence subscription typically indicates some level of trust in a peer, server deployments can use the sharing of XMPP presence information as a way to indicate that a given server has a trust relationship with a peer server (informally, we can say that the two servers consider each other "buddies"). The server might then share certain kinds of additional information only with its trusted peers, for example &xep0268; and &xep0275;. The server buddy relationship can also be leveraged for additional functionality, such as &xep0309;</p>
<p>To establish such a trust relationship with a peer, a server sends a presence subscription request to the peer, just as is done between XMPP users.</p>
<example caption="Service sends subscription request to peer"><![CDATA[
<presence from='montague.lit'
@ -100,7 +106,7 @@
type='subscribe'/>
]]></example>
<p>The originating server would then approve that subscription request.</p>
<example caption="Services sends approval to peer"><![CDATA[
<example caption="Service sends approval to peer"><![CDATA[
<presence from='montague.lit'
to='capulet.lit'
type='subscribed'/>
@ -112,9 +118,9 @@
<p>This section defines an &xep0050; node scoped by the &xep0068; FORM_TYPE specified in &xep0133;. Upon advancement of this specification to Draft, this section ought to be moved to XEP-0133.</p>
<p>The command node for this use case SHOULD be "http://jabber.org/protocol/admin#server-buddy".</p>
<p>A sample protocol flow for this use case is shown below.</p>
<example caption='Admin Subscribes Server to Peer Server'><![CDATA[
<example caption='Admin Subscribes Service to Peer Server'><![CDATA[
<iq from='bard@shakespeare.lit/globe'
id='server-buddy-1'
id='nrw51vs8'
to='shakespeare.lit'
type='set'
xml:lang='en'>
@ -126,7 +132,7 @@
<p>Unless an error occurs (see the "Error Handling" section of XEP-0133), the service SHOULD return the appropriate form.</p>
<example caption='Service Returns Server Buddy Form to Admin'><![CDATA[
<iq from='shakespeare.lit'
id='server-buddy-1'
id='nrw51vs8'
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
@ -149,10 +155,10 @@
</command>
</iq>
]]></example>
<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>
<p>Note: In virtual hosting environments, the server can determine 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'
id='lk2vs82g'
to='shakespeare.lit'
type='set'
xml:lang='en'>
@ -163,9 +169,6 @@
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/admin</value>
</field>
<field var='serverjid'>
<value>shakespeare.lit</value>
</field>
<field var='peerjid'>
<value>marlowe.lit</value>
</field>
@ -175,7 +178,7 @@
]]></example>
<example caption='Service Informs Admin of Completion'><![CDATA[
<iq from='shakespeare.lit'
id='server-buddy-2'
id='lk2vs82g'
to='bard@shakespeare.lit/globe'
type='result'
xml:lang='en'>
@ -189,7 +192,7 @@
</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>
<p>To advertise its support for the server buddy feature, when replying to service discovery information ("disco#info") requests a server MUST return a URN of "urn:xmpp:server-presence".</p>
<example caption="Service discovery information request"><![CDATA[
<iq from='jabber.org'
id='uw72g176'