From a46bf68d67270ad0dec79c8e7e8bb82f2e4d7ca1 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 29 May 2012 19:08:00 -0600 Subject: [PATCH] 0.5 --- xep-0267.xml | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) mode change 100644 => 100755 xep-0267.xml diff --git a/xep-0267.xml b/xep-0267.xml old mode 100644 new mode 100755 index a80fae97..1025bd0e --- a/xep-0267.xml +++ b/xep-0267.xml @@ -45,6 +45,12 @@ mwild1@gmail.com mwild1@jaim.at + + 0.5 + 2012-05-29 + psa +

Corrected several examples and points in the text.

 + 0.4 2011-12-12 @@ -78,7 +84,7 @@ -

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;.

+

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;

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.

]]>

The originating server would then approve that subscription request.

- @@ -112,9 +118,9 @@

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.

The command node for this use case SHOULD be "http://jabber.org/protocol/admin#server-buddy".

A sample protocol flow for this use case is shown below.

- @@ -126,7 +132,7 @@

Unless an error occurs (see the "Error Handling" section of XEP-0133), the service SHOULD return the appropriate form.

@@ -149,10 +155,10 @@ ]]> -

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.

+

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.

@@ -163,9 +169,6 @@ http://jabber.org/protocol/admin - - shakespeare.lit - marlowe.lit @@ -175,7 +178,7 @@ ]]> @@ -189,7 +192,7 @@ -

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".

+

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".