Most recent attached from https://raw.githubusercontent.com/buddycloud/buddycloud-xep/gh-pages/buddycloud.xml
Simon, I assume this is correct? _____________________________________________________ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP [email protected] (email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI & DDRC - 15th December 2013 - NDAC, Chepstow On 28 April 2014 17:52, Matthew A. Miller <[email protected]>wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Please send the Editor the canonical XML file as an attachment, and we'll > get the inbox proto-XEP updated. > > - -- > - - m&m > > Matthew A. Miller > < http://goo.gl/LK55L > <http://goo.gl/LK55L> > > > On 4/28/14, 10:45 AM, Steven Lloyd Watkin wrote: > > Here's the version the script builds - > http://buddycloud.github.io/buddycloud-xep/ > > > > I think the problem might be between the user and the mail queue :) > > > > _____________________________________________________ > > > > Steven Lloyd Watkin > > Software Engineer > > PHP ::: Java ::: Ruby ::: Node.js ::: XMPP > > [email protected] > > <mailto:[email protected]><[email protected]>(email+jid) ::: > http://www.evilprofessor.co.uk > > Facebook / Twitter / Flickr: lloydwatkin > > > > Organiser of WORLD RECORD breaking charity event: > > Scuba Santas ::: http://www.scuba-santas.co.uk > > Supporting the RNLI & DDRC - 15th December 2013 - NDAC, Chepstow > > > > > > On 28 April 2014 17:39, Ashley Ward <[email protected] > <mailto:[email protected]> <[email protected]>> wrote: > > > > On 28 Apr 2014, at 17:11, XMPP Extensions Editor <[email protected] > <mailto:[email protected]> <[email protected]>> wrote: > > > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > > > Title: Buddycloud Channels > > > > > > Abstract: This document describes a profile and conventions for > usage > > > of the PubSub protocol in the context of a > new type of communication. > > > > > > URL: http://xmpp.org/extensions/inbox/buddycloud-channels.html > > > > > > The XMPP Council will decide in the next two weeks whether to > accept this proposal as an official XEP. > > > > > > > Looks surprisingly short... I think possibly there's something gone > wrong with Lloyds build script! > > > > — > > Ash > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTXocwAAoJEOz0ck4QngW7qBYIAKtAHwDcewKi4QkUrwu+r2oI > NbHAK2zVeqxm0UHCOpMG+MABiAJQUiCUtRJKOCX/Rz7+d46+MduxVQsAbTBC5eb0 > pXW/oNdm3GAUnXu8rIVLp2jpCzlEWL0sIdb/G9RR8WqcBiZScI0e/hfwhd6+qsXu > f0TCxjp+YOdBZPSQIRugu80turdx6seN7FD4VVx0okVxg7BEyQtbxXTrvfcb26iM > Lg8gcwNp2qheMbiqQdSSxXCEE0Epo9C2ehqcXwMlyrLmfyi1ab/paLQBd7/Jt7rl > wN2OIwN5YbdP1XLdbWqkA9ex749HwL6F1iHYbkinTh6dOgZpNm8vuVp+EtAeJ5c= > =DInJ > -----END PGP SIGNATURE----- > >
<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE xep SYSTEM 'xep.dtd' [ <!ENTITY % ents SYSTEM 'xep.ent'> %ents; <!ENTITY actor "<actor/>"> <!ENTITY invalidactor "<invalid-actor/>"> <!ENTITY invalidnode "<invalid-node/>"> ]> <?xml-stylesheet type='text/xsl' href='xep.xsl'?> <xep> <header> <title>Buddycloud Channels</title> <abstract>This document describes a profile and conventions for usage of the PubSub protocol in the context of a new type of communication.</abstract> <legal> <copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2014 by the XMPP Standards Foundation (XSF). </copyright> <permissions> Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. </permissions> <warranty> ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ## </warranty> <liability> In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. </liability> <conformance> This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at < <link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link> > or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). </conformance> </legal> <number>xxxx</number> <status>ProtoXEP</status> <type>Standards Track</type> <sig>Standards</sig> <approver>Council</approver> <dependencies> <spec>XMPP Core</spec> <spec>XEP-0059</spec> <spec>XEP-0060</spec> <spec>XEP-0313</spec> <spec>XEP-0255</spec> <spec>XEP-0107</spec> </dependencies> <supersedes /> <supersededby /> <shortname>NOT_YET_ASSIGNED</shortname> <author> <firstname>Simon</firstname> <surname>Tennant</surname> <email>[email protected]</email> <jid>[email protected]</jid> </author> <author> <firstname>Ashley</firstname> <surname>Ward</surname> <email>[email protected]</email> <jid>[email protected]</jid> </author> <author> <firstname>Lloyd</firstname> <surname>Watkin</surname> <email>[email protected]</email> <jid>[email protected]</jid> </author> <revision> <version>0.0.1</version> <date>2014-01-29</date> <initials>sdt</initials> <remark> <p>First draft.</p> </remark> </revision> </header> <section1 topic='Introduction to Buddycloud' anchor='intro'> <p>Buddycloud is a collection of servers, running as XMPP components that enable rich, federated communications for groups and individual users. users uses and groups. Buddycloud builds on XMPP's native federation and pub-sub principles to connect to and synchronise updates with other Buddycloud servers. </p> </section1> <section1 topic='Channel Introduction' anchor='intro'> <p>Channels are a bundle of pub-sub nodes that have the same owner, folllowers and access permissions. There are two types of channel: user channels (named after the user's JID), for example [email protected]) and topic channels, for example [email protected]) which are owned by the channel creator. Content posted into channels is automatically synchronised to the correct followers on other Buddycloud servers. </p> </section1><section1 topic='Service Discovery' anchor='servicediscovery'> <p>Service discovery happens per domain, and is a multi step process. </p> <p>To discover the channels component for a domain, the entity first sends an items discovery request to the domain to discover all the available components. </p> <example caption="The Entity sends a disco#items request to the domain"> <![CDATA[ <iq type='get' from='[email protected]/balcony' to='capulet.lit' id='items1'> <query xmlns='http://jabber.org/protocol/disco#items'/> </iq> ]]> </example> <p>The server replies with the list of available components, along with their associated JIDs. </p> <example caption="The server replies with a list of available components."> <![CDATA[ <iq type='result' from='capulet.lit' to='[email protected]/balcony' id='items1'> <query xmlns='http://jabber.org/protocol/disco#items'> <item jid='muc.capulet.lit' name='Chatrooms' /> <item jid='buddycloud.capulet.lit' name='Buddycloud Server' /> </query> </iq> ]]> </example> <p>The entity then iterates through the <item/> elements, sending an info discovery request to each jid. </p> <example caption="The Entity sends a disco#info request to each component"> <![CDATA[ <iq type='get' from='[email protected]/balcony' to='buddycloud.capulet.lit' id='info1'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq> ]]> </example> <p>Each component replies with its identity. The channels component has an identity of category 'pubsub' and type 'channels'. </p> <p> A domain MUST only host one component with an identity of category 'pubsub' and type 'channels'. </p> <example caption="The Buddycloud component replies with its identity"> <![CDATA[ <iq type='result' from='buddycloud.capulet.lit' to='[email protected]/BuddycloudApp' id='info2'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='pubsub' type='channels' /> <identity category='pubsub' type='inbox' /> <feature var='jabber:iq:register' /> <feature var='http://jabber.org/protocol/disco#info' /> <feature var='jabber:iq:search' /> </query> </iq> ]]> </example> <section2 topic='DNS Discovery' anchor='servicediscovery-dnsdiscovery'> <p>Buddycloud components can also be discovered using a DNS SRV record formatted as follows. </p> <example caption="SRV record for channel server didsovery"> <![CDATA[ _buddycloud-server._tcp.EXAMPLE.COM. IN SRV 5 0 5269 buddycloud.EXAMPLE.COM. ]]> </example> </section2> <section2 topic='Discovery priority' anchor='servicediscovery-which-is-more-secure'> <p> In the case of conflicting answers, the DNS result is authoritative. This permits domain owners to run Buddycloud on domains on "chat only" domains such as google hosted apps. </p> </section2> </section1> <section1 topic='Register' anchor='register'> <p>Upon connection to the buddycloud server a user should send a register stanza.</p> <example caption="The Entity sends a register request to the domain"> <![CDATA[ <iq type='set' from='[email protected]/balcony' to='channels.capulet.lit' id='register1'> <query xmlns='jabber:iq:register'/> </iq> ]]> </example> <p>The register request creates the user's personal channels on first use and has the additional benefit of creating additional new channel nodes as they become available on the server (e.g. 'status' node, 'geoloc' nodes). </p> </section1> </xep>
