[jdev] gmail + non-SASL

[Nathan Fritz]

On Feb 24, 2010, at 1:11 AM, Yann Leboulanger <asterix at lagaule.org>  
wrote:

> Nathan Fritz wrote:
>> You must be referring to the 5223 service? The resource hex values
>> indicate the cluster node your session data. I imagine only one of  
>> the
>> servers handles old-style jabber connections if it doesn't rewrite  
>> your
>> resource.
>>
>> Using the old style auth is NOT xmpp 1.0 compliant while the server
>> rewriting resouces is acceptable in the spec and I think a really  
>> neat
>> solution for cluster optimization.
>>
>> Another reason for the lack of resource rewrite in old style jabber  
>> is
>> that resource binding didn't exist. In short those connections are  
>> not
>> xmpp.
>
> No no I mean connected on port 5222, with TLS (not SSL). I'm only
> talking about the authentication mechanism. Once connected and tls
> proceeded, I send:
>
> <iq xmlns="jabber:client" type="get" id="1"><query
> xmlns="jabber:iq:auth"><username>XXX</username></query></iq>
>
> instead of
>
> <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="DIGEST- 
> MD5" />
>
> Maybe it's convenient for server admin to have those cluster node in
> resource, but as a user, I really don't care and don't want to see  
> that.
>
> Now the problem is not that the client doesn't support resource  
> binding,
> just that it's not nice from a user point of view.
>
I didn't realize that Google Talk supported the old auth that way.  
It's not part of the RFC. I wouldn't use it as it's probably just  
there for compatibility with old clients. The hex value in the  
resource is just the reality of using GTalk. It is questionable  
whether it's meant for the user to see it anyway.

I also wouldn't be surprised to see more servers use this clustering  
strategy in the future. (I know of one that is planning it)

Perhaps some client driven pep is in order for showing a user facing  
unique name for individual sessions.

-Nathan Fritz (cellphone)