[jdev] Necessity of stringprep support for the client

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/16/12 6:13 AM, Sergey Dobrov wrote:
> On 08/16/2012 06:57 PM, Peter Saint-Andre wrote:
>> On 8/16/12 2:41 AM, Sergey Dobrov wrote:
>>> On 08/16/2012 03:33 PM, Kevin Smith wrote:
>>>> On Thu, Aug 16, 2012 at 9:23 AM, Sergey Dobrov 
>>>> <binary at jrudevels.org> wrote:
>>>>> Can XMPP work in conformity with XMPP Core if it can't do 
>>>>> stringprep? The question has arisen because of js that
>>>>> doesn't have a possibility to do stringprep transformations
>>>>> and it's hard to do in script because we will need to
>>>>> download huge tables to the client.
>>>> 
>>>> Without stringprep, various things aren't going to work - at
>>>> its worst, you could be sending illegal data to the server
>>>> and getting disconnected.
>> 
>>> Yeah, that's the exact thing I wanted to hear, thanks.
>> 
>>>> 
>>>> More subtle and much harder to debug is that you may be
>>>> comparing JIDs using string comparisons that are the same JID
>>>> in a different representation.
>> 
>>> So we can continue our talk about how to solve the problem?
>>> Look, the js clients became to be used wider and wider and no
>>> one who write them don't care about the problem (I have posted
>>> a ticket to jappix, for example, but nothing), so we have to
>>> force the solution maybe, uh?
>> 
>>> What is our options then? Write a library that will fetch
>>> tables from some location that can be cached on client side and
>>> do fair transformation on client side. The problems are: it
>>> will be downloading long at the first time, it will be
>>> downloading long always on mobile devices.
>> 
>>> Or we can make a XEP to provide a possibility to make 
>>> transformations on client side, so each server will be able to 
>>> provide the possibility and we will get rid of the necessary 
>>> dependence I said before.
>> 
>>> Other options?
>> 
>> First of all, stringprep is being replaced by the PRECIS
>> framework:
>> 
>> http://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/
> 
> oh, so I need time to take a look on the framework... Will it be 
> backwards compatible?

Yes. Naturally we need to do some testing, but the intent is for the
PRECIS framework (and the XMPP usage of that framework) to be backward
compatible.

Basically, PRECIS (and IDNA2008) bases its rules on the
characteristics of Unicode code points and applies to any version of
Unicode (currently 6.1), whereas stringprep (and IDNA2003) used a
giant lookup table derived from Unicode 3.2.

>> I am pushing to get that done sooner rather than later.
>> 
>> For JavaScript, there is an ECMAScript Internationalization API
>> in the works:
>> 
>> 
>> http://norbertlindenberg.com/2012/02/ecmascript-internationalization-api/index.html
>>
>>
>> 
http://wiki.ecmascript.org/doku.php?id=globalization:globalization
>> 
>> 
>> http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
>>
>>
>> 
http://wiki.ecmascript.org/doku.php?id=strawman:unicode_normalization
>> 
>> That should help quite a bit (although I still don't see much
>> about normalization there).
> 
> Unfortunately, that seems no usable at the moment. But we have no
> any js library or client that conforms with XMPP Core now, that's
> terrible, I think. Except of habahaba.im which uses the approach I
> described earlier, but it has defects I also described. So, can we
> invent any temporary solution or we should wait again while
> necessary functions will be implemented in js engines?

Agreed, I don't think the ecma thing is usable yet, but I wanted
people here to know that folks are working on solutions.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAs6XwACgkQNL8k5A2w/vxXJQCcDv2DZdq0sXw4nbrdfiwb1NhQ
KCoAoOILaCd7Eg7n13o+hxbmBiAcfXGj
=KQ5P
-----END PGP SIGNATURE-----