On Mon Feb 27 10:04:17 2012, Björn Kempén wrote:
Thanks, I was not aware of this issue, and I'll file an internal
bug for it :)
Also, I've sent out private emails in response to some of the people
offering to help out with the server-to-server debugging.
Thanks a lot for offering to help us out with debugging this issue.
Currently, our server fails a lot of attempted dialback for "real"
reasons, such as domains lacking SRV records, which can make it very
hard to detect regressions in the dialback code.
I'm hoping to have the issues reported here resolved as soon as
possible.
The newer dialback spec - XEP-0220 - does include error support,
which'd allow you to hand the server a textual error reason for
failure when you reject a <db:result/>, as well as machine-readable
error conditions.
Would that help admins get a diagnosis of why the dialback is failing
(in common cases) without you having to manually chase up each case?
If there's anything we could do on a protocol/standards front to make
self-diagnosis of S2S failure easier, I'd be willing to push for
that. (And in my guise as M-Link guy, make sure we implement it).
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
