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 ll...@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 <j...@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 > >
