[Standards] Proposed XMPP Extension: Buddycloud Channels

Steven Lloyd Watkin lloyd at evilprofessor.co.uk
Tue Apr 29 08:14:26 UTC 2014

In the latest spec we use a PTR record - but that's not so important.

The DNS look up is optional. DISCO response SHOULD always take priority.
The DNS look up is for s2s communications and a client is not involved at
all. A client always talks to its "home" buddycloud server.

The addition of a DNS lookup is for users like Simon T who use google apps
and so their main XMPP server (google) won't allow them to add components.

We still use DISCO as its the standard way of performing discovery.  DNS is
just an additional nice mechanism.


Steven Lloyd Watkin
Software Engineer
PHP ::: Java ::: Ruby ::: Node.js ::: XMPP
lloyd at evilprofessor.co.uk (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 21:53, Edwin Mons <jsf at edwinm.ik.nu> wrote:

> On 28/04/14 18:11, XMPP Extensions Editor 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.
> >
> Does para 3.2 imply that you should always do the DNS lookup, or should
> a client that tries to find a Buddycloud pubsub domain only try this as
> a fallback mechanism?  If the former, why do the disco#info at all if an
> SRV record is found?  If the latter, how could the results be conflicting?
> Edwin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140429/3a5a4c28/attachment.html>

More information about the Standards mailing list