[jdev] Figuring out what a client thinks its JID is
stpeter at stpeter.im
Mon Apr 5 22:02:15 CDT 2010
On 4/5/10 4:01 PM, Aaron Kryptokos wrote:
> Nathan Fritz wrote:
>> By not using the same node as the authentication user, you're going
>> against two SHOULD suggestions in the RFC
> I can't find anything in RFC 3920 about this case. Can you help me find
> these two recommendations?
>> I would recommend against doing this on a public
>> service where you expect any IM client.
> The authentication and authorization system already exists, so my hands
> are mostly tied. I'm open to any reasonable implementation that will
> make this work. The one design restriction imposed on me is that the
> authenticating client must some sort of way provide the authentication
> username as part of the process; mapping from the node to auth
> credentials is not acceptable.
Hi Aaron, I took another look at your original message in this thread:
We had some discussions about a related issue recently on the XMPP WG list:
The conclusion we came to is that the authentication identity is indeed
not necessarily the same as the localpart of a JID. We mostly glossed
over this issue in RFC 3920, but the replacement RFC will make it clear
that this is a matter for the SASL mechanism or local deployment policy,
not the core XMPP RFC.
> If it's true that the RFC discourages this practice, then I think the
> RFC may need to be revised. For people who are running simple
> stand-alone Jabber servers, this sort of thing doesn't matter. But for
> organizations like mine that are trying to embrace XMPP by adding an
> XMPP interface to existing infrastructure, this is a major issue. GTalk
> has a variation of the same problem, except with domain instead of
> username. I think the real long-term solution here is that the RFC
> needs to firmly instruct clients to not make assumptions about their
See http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-05 (section 7.2.7).
> and instead accept (or reject) what they are given at resource
We could probably strengthen the text about that.
>> are, again, in violation of the spec by delivering stanzas where the
>> bare jid does not match their bound name, and you could cause
>> unintended consequences on the client (crashes or strange behavior) by
>> simply pinging them in this way.
> I can't find any prohibition like this in RFC 3920 or the draft. Can
> you point out a specific passage that prohibits this sort of probing?
I don't see any need for this -- the client needs to get its JID from
>> I really don't see either of these options being viable as the client
>> is simply broken if it doesn't respond to it's bound fulljid and you
>> risk greater consequences if you try to "adjust" at the protocol
> My main goal is for a short-term, practical improvement in functionality
> for as many users as possible.
I agree with Fritzy here -- better to file bug reports or provide
patches to the clients you care about. Supposedly short-term fixes have
a way of lasting for a long time, people start to depend on the fix and
it will never disappear.
> As an alternative, I'm thinking about perhaps having the user do
> something special to indicate that 'JID masquerading' should be
> performed, such as placing a special character in their username.
> Another option is to try to detect specific versions that are broken
> using XEP-0092: Software Version, and apply the workaround for just
> those. This would get correct operations to the largest groups of
> users, and prevent breaking people whose clients were in fact operating
Do you have a list of broken clients? Let's figure out what they are and
start the process of reporting bugs and fixing code.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the JDev