Just mentioning a basic problem which was discussed at jdev.
If two 1.0 server move to 1.1, all the 'older' 1.0 jid's will become
unroutable - which are present in user roster/affiliations/privacylists/etc.
Regards,
Mridul
Robin Redeker wrote:
(Warning, long mail ahead! Get a coffee and some time first :-)
On Thu, Aug 02, 2007 at 03:34:30PM -0600, Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
The problem essentially is that any place where we have a JID persisted
in the backend (user roster, acl's, affiliations, privacy lists/block
lists, etc), it will become incompatible change.
For example, what used to be [EMAIL PROTECTED] will now become
contact&[EMAIL PROTECTED] - causing incompatibilities.
Well we're having a looooong discussion about this in the jdev room
right now:
http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-02.html
I volunteer elmex for posting a summary once we're done. :)
Yes, basically Mridul is completly right, we can't do much about the
already deployed backslashes in JIDs. Especially in 1.0 server rosters.
But...
First we have to wonder whethere there are actually people with
[EMAIL PROTECTED] in their roster, as registering a JID with a \ in
the username is a considerable problem with XMPP 1.0 servers with SASL
and DIGEST-MD5 (see some older message from me in the JID escaping
thread).
Of course that should be further investigaged as old-style IQ auth works
with [EMAIL PROTECTED] and also some jabberd2 servers allow
authentication as [EMAIL PROTECTED] without problems.
But there exists a possibility to migrate our old JIDs to the 1.1 world
and staying interoperable with 1.0 servers:
First: A 1.1 server that is going to communicate with 1.0 server will
escape the JIDs from his userbase when he SENDS to a 1.0 entity.
Escaping can be performed as described in XEP-0106 (after dropping the
silly \20 escaping rule).
That will work great if the 1.1 server has NO old userbase.
If we have for example jabber.org, a large userbase, and there is
actually [EMAIL PROTECTED] as registered user in. And we want to
upgrade to a 1.1 server then we will run into the problems Mridul
pointed out:
1.0 servers have [EMAIL PROTECTED] in their roster, and if we have
now 'stpeter @jabber.org' registering a new account he will collide with
that, because his JID will be escaped to the in the 1.0 servers roster
existing [EMAIL PROTECTED] Bang, we got a collision.
There exists no real easy way to prevent that except just not allowing
'stpeter @jabber.org' to register. To detect a case like this, that a
new user with a colliding JID registers, the 1.1 server needs to keep
track of the old JIDs in his database.
If the 1.1 server knows that [EMAIL PROTECTED] is a JID from the
pre-1.1 times, he can assume that [EMAIL PROTECTED] is already in
some rosters out there. So he MUST NOT allow anyone who might collide
with that to register at jabber.org after the migration to 1.1.
So when upgrading jabber.org could just mark all JIDs with a \ in their
name to be a pre-1.1 JID and disallow anyone to register who might
collide with one of the registered JIDs.
This way ' [EMAIL PROTECTED]' can register if no
'[EMAIL PROTECTED]' existed before (he knows that from his
database with the marks of old JIDs).
If ' [EMAIL PROTECTED]' now wants to talk with '[EMAIL PROTECTED]', it
would look like this:
<message from=" [EMAIL PROTECTED]" to="[EMAIL PROTECTED]" />
As jabber.org (1.1) knows that chrome.pl (1.0) is in fact 1.0 he escapes
like XEP-0106 recommends and sends actually:
<message from="[EMAIL PROTECTED]" to="[EMAIL PROTECTED]" />
In [EMAIL PROTECTED]'s client will now popup a message from
"[EMAIL PROTECTED]" and except some weird JID he can talk with him.
Because if he sends a message back:
<message from="[EMAIL PROTECTED]" to="[EMAIL PROTECTED]" />
Then jabber.org will unescape the to-field and deliver the message to
' [EMAIL PROTECTED]'.
Of course this solution is not a perfect one for the end-users as I will
describe below, but I argue that the incompatibilities will increase
the pressure on developers a bit and on administrators to adapt XMPP
1.1. And thus that might speed up the migration while providing a
compatibility-workaround for maybr 98-99% of the cases, or maybe even
99,9999% (this needs to be investigated a big IMO, maybe my assumptions
are completly wrong).
So much for the server-to-server interoperability.
========================================
Now about 1.1 clients and 1.0 clients. 1.0 clients will have no way
to reach ' [EMAIL PROTECTED]', which is fine, either the user knows
that guy's JID needs to be escaped because he uses an old client, or he
has to upgrade to a client with 1.1 capabilities (what this means is
described below).
Not being able to send a message to ' [EMAIL PROTECTED]' will increase
the pressure on the client developers as stated above.
So 1.0 clients are basically out of luck if the user don't know how to
escape, however, tell em: "get a new client".
Of course it's blunt to say that, but I guess we can assume that not our
WHOLE old userbase without spaces and all those fancy characters in
their JID are NOT GOING TO signup a new account. So the users with
spaces and & or whatever in their JID will probably come as slow as the
XMPP world migrates to 1.1, and thus not experience any weird things.
Lets assume now our guy, eg. [EMAIL PROTECTED] got a new client, fancy new
tkabber with 1.1 support. Now he enters ' [EMAIL PROTECTED]' in the
client and wants to send that. Now we assume that chrome.pl is still
version 1.0. Ok. Our 1.1 client has to escape (back to JID escaping in
clients here, eh? :-).
Ok, our client escapes the user entered JID ' [EMAIL PROTECTED]' when
sending it to a 1.0 server.
Please note here that there MUST NOT BE ANY ESCAPING PERFORMED BETWEEN
1.1 ENTITIES (that means servers AND clients). Escaping should ONLY
HAPPEN on the border between a 1.1 entity and a 1.0 entity.
Such borders are 1.1 <-> 1.0 server2server connections and 1.1 <-> 1.0
client2server or server2client connections.
Also note that a 1.1 server speaking with a 1.0 client ALSO has to
perform escaping!
========================================
Phew, I hope you got the idea :-)
And with this all being said I want to point out again that this all is
only really going to work in the realworld out there if servers that
migrate their userbase perform the "do we already have a pre-1.1 JID
with \ in their nodepart in our database and is it possible he is in
some roster out there?"-check and do not allow accounts with eg. spaces
(or whatever new characters we are going to allow in the nodepart) to be
created after the 1.1 change.
If you are interested in further discussion of this topic I also want to
point out the past discussion which lead to this mail in the jdev@ room:
http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-02.html#15:07:48
It might show you how this idea evolved and maybe prevents unneccessary
misunderstandings in further discussions :-)
Tomasz Sterna (smoku) pointed out that he as jabberd2 developer would consider
this compatibility-escaping-with-xep-106 as unneccessary :-)
And I strongly recommend to talk with the server developers and admins
about the consideration of a 1.1<->1.0 interoperability spec. Maybe
it's good enough to not do any escaping and just don't allow
' [EMAIL PROTECTED]' to talk with people on 1.0 servers. I'm just a
client developer :-)
Robin
