On Fri, Mar 2, 2012 at 12:46 PM, Peter Saint-Andre <[email protected]>wrote:
> On 3/2/12 8:59 AM, Kevin Smith wrote: > > On Fri, Mar 2, 2012 at 3:57 PM, Mark Rejhon <[email protected]> wrote: > >> I am seriously considering making disco#info section 5 optional, and > making > >> REQUIRED an alternate backup capabilities-detection mechanism: > > > > That's very not-XMPPish, though - you're not likely to need to do any > > work with xep30 or 115, the library/client will already be > > implementing that, will have a easy way to add a feature and to check > > that a remote contact supports a feature. > > +1 > Point taken -- I am leaving section 5 unmodified. I agree it is not very XMPP-ish, but there were a couple other rationales to the idea" -- I remain concerned that not all platforms that I will be working on, provides an easy/trivial way to query for this feature. I also fear that I may run into XMPP implementations that isn't transparent to <iq> but lets through unfamiliar stanzas (such as <message> <rtt> </message> etc.) ... Although that hasn't happened yet, I've seen some XMPP implementations filter unfamiliar stanzas (i.e. Facebook XMPP server). -- As long as section 5 is required, it means the server must have fully working <iq> transprency _AND_ transparency on <rtt/> elements. Two potential weak links in a 'half-hearted' XMPP implementation. However, this can be revisited for subsequent revisions, if it becomes a pressing need. For now, I will attempt to comply with section 5 in all implementations, and see what the real-world experience is, first. Mark Rejhon
