[Operators] Google Talk federation problems (still)
jeffm at iglou.com
Thu Feb 28 14:44:41 CST 2008
Justin Uberti wrote:
> There was an email from Adam Fass earlier this week explaining the nature of
> the issue. Basically when Google Apps Team Edition was launched, it caused
> routing for some federated domains to be affected. This was an accident and
> federation should now be restored; work is also being done to prevent this
> from occurring for any future federated domains.
Ok, then apparently there are other problems as I'm having difficulties
connecting to domains that *are* validly hosted on Google Talk hosted,
and at least one of them has been for months and months and just broke
This is not related to Team Edition, and its not domains where the XMPP
hosting is outside of Google.
> Are there other concerns that you have with the Google Talk service? XMPP is
> very important to us, and we want to make sure we maintain a positive dialog
> with other XMPP operators.
One of the things that has always annoyed me about the Google Talk
server is the appending of crap onto the end of the resource string.
Initially, it would seem that this isn't a big deal to admins of other
servers, but it causes a significant amount of annoyance when you're
dealing with MUC when you have connectivity interruptions somewhere
along the way.
In general, however, it seems that Google has played fast and loose with
the spirit of XMPP overall. Its hard to point to specific issues, and I
definitely don't think I can point to any particular issues where I can
really claim that you're out of spec, but it seems like its perennially
Google that is pushing the edge of the envelope on interoperability and
interpretation of the specs.
I'm just a bit frustrated trying to deal with the corner case that
Google always seems to be in the XMPP world. Your participation here is
welcomed, but let me urge Google (and not just in the XMPP world) to
step out of behind the Google reality distortion field (did you all
license that from Steve Jobs? or did you invent your own? ;) and
re-enforce the idea of interoperability considerations when developing
your services. Following the specs is good, following the specs and
collaborating with the rest of the world on interoperability before
putting something into production (or as Google calls it "Beta") would
be nice as well.
> On Thu, Feb 28, 2008 at 7:41 AM, Jeff McAdams <jeffm at iglou.com> wrote:
>> I just sent a couple of messages to xmpp at google.com, but I'm
>> experiencing the same sort of federation issues with google talk hosted
>> domains that other people have experienced here the past week or so.
>> I'm, in particular, dealing with two domains that are hosted at Google
>> Talk, one is new, and one has been on Google Talk hosted for many months.
>> I am able to send messages to the hosted domains from my server, but
>> they are not able to send messages back. Presence doesn't seem to be
>> correctly being sent either, although I'm not as sure on the details on
>> Server dialback seems to be succeeding (based on what I can tell in my
>> logs) in both directions.
>> The domain that has been hosted on Google Talk for a while has been
>> successfully in use for months and months, including this federation.
>> Any chance we can get a bit more transparency from the Google folks
>> about what has changed in s2s handling on the Google side in the past
>> couple of weeks? With some specificity maybe?
>> I'm trying to be positive and productive, here, but Google seems to be
>> playing fast and loose with at least the spirit of the XMPP standards in
>> a couple of places here and its starting to cause some problems. And to
>> say that its frustrating is quite a bit of an understatement.
>> Jeff McAdams
>> "They that can give up essential liberty to obtain a
>> little temporary safety deserve neither liberty nor safety."
>> -- Benjamin Franklin
"They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety."
-- Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://mail.jabber.org/pipermail/operators/attachments/20080228/9b3ce450/attachment.pgp
More information about the Operators