[jdev] Necessity of stringprep support for the client

[Sergey Dobrov]

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?

> 
> 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?

> 
> Peter
> 
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
> 

-- 
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.