[Standards] summary: allowable characters
mridul at sun.com
Sun Aug 5 07:20:15 UTC 2007
Robin Redeker wrote:
> On Sun, Aug 05, 2007 at 05:10:13AM +0530, Mridul Muralidharan wrote:
>> Robin Redeker wrote:
>>> On Fri, Aug 03, 2007 at 04:29:15AM +0530, Mridul Muralidharan wrote:
>>>> 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
>>> Yes, this sounds like the death blow for escaping for backward
>>> compatibility. It will poison the old 1.0 servers and make whole roster
>>> subscriptions unusable once that server upgrades to 1.1. (Not to mention
>>> the JIDs in the private XML storage or other places you mentioned).
>>> Do you see any problem in just disallowing incompatible 1.1 JIDs to be
>>> able to communicate with 1.0 JIDs? The old 1.0-compatible JID accounts
>>> on a 1.1 server will of course still be able to talk with people on 1.0
>> The problem is 1.1 JID's cant communicate with 1.1 contact JID's -
>> if user has cont\26ct at domain, what will the 1.1 server do ? It could
>> either be pointing to a 1.1 cont\26ct at domain (route as-is), was a 1.0
>> jid - convert to cont&ct at domain (needs transformation) or continues to
>> be 1.0 cont\26ct at domain (route as-is) (all three as different cases,
>> though 1 and 3 look the same).
> I don't know exactly what you mean. There MUST NOT be done any escaping
> between two 1.1 servers. So a 1.1 contact on server A and another 1.1
> contact on server B are communicating nicely with each other. And also
> the JIDs in their rosters will be a 1.1 JID.
> Escaping only happens between 1.1 and 1.0 servers, and only on those
> 1.1 vs. 1.0 borders.
> But the problem that we have then is that a 1.0 server, which will only
> receive escaped JIDs, stores those (escaped) 1.1 JIDs in the 1.0 contacts
> roster as escaped JIDs (because he doesn't even know they are escaped
> That means that after migration (1.0 server upgrades software to a 1.1
> capable one) those JIDs are still in their escaped form in the roster.
> And because there doesn't happen any escaping between 1.1 servers our
> recently upgraded 1.0 server has broken rosters.
Yes, I am refering to this case above. 1.0 roster, 1.1 server.
It is not always practical to say - do full user data migration before
moving to 1.1 (not always possible).
>>> The network won't be split the day servers start speaking XMPP 1.1.
>>> By preventing people with JIDs with incompatible characters to speak
>>> with 1.0 servers the 1.1 servers can prevent that split.
>> Existing data will be present - and without jid meta-data, we cant
>> associate encoding info.
>> One possible option would be to move to use uri scheme for jid's - (and
>> so this could be the differentiator for 1.1 vs 1.0).
>> More importantly, it would help in case of interop with other protocols.
>> Last time I brought this up, it was considered a bit too disruptive, and
>> so dropped :-) Since Peter was considering 1.1 of xmpp, maybe this would
>> be a good time to rethink this idea !
> You mean if a 1.1 server speaks with a 1.0 server it gives him an URL
> instead of an escaped JID? How will 1.0 servers handle that? They will
> have to code a little to handle that, don't they?
At the boundary, the 1.1 server will convert from/to uri form to current
(1.0) form while talking to an 'older' (1.0) server, and will continue
with uri form for a 1.1 server..
> (I like the idea of URLs btw., but changing a whole culture from their
> JIDs to URIs will be quite hard I guess :-)
More information about the Standards