[jdev] Necessity of stringprep support for the client

Peter Saint-Andre stpeter at stpeter.im
Fri Aug 17 15:43:13 UTC 2012

Hash: SHA1

On 8/17/12 9:31 AM, Sergey Dobrov wrote:
> On 08/17/2012 10:13 PM, Peter Saint-Andre wrote:
>> On 8/17/12 9:10 AM, Sergey Dobrov wrote:
>>> On 08/16/2012 09:24 PM, Peter Saint-Andre wrote:
>>>> On 8/16/12 6:42 AM, Sergey Dobrov wrote: Although a service
>>>> like that would be helpful, it might be more productive to
>>>> work on better i18n support in JavaScript.
>>> JS i18n native support is a great thing but we can't influence
>>> on it, but we can invent an XEP for such conversion service,
>>> should we do that?
>> Maybe. :)
>> Before going down that path, it would be good to poll some
>> server implementers to see if they would add support for it.
> I think that it would not be a problem to write a mod for ejabberd,
> for example :)) I don't see a problem here...

One appealing aspect of this approach is that it would lighten the
load on clients (in terms of both code and processing). Especially for
web clients and mobile clients that would be a good thing.

> Furthermore, it can be done with a XEP-0114 as component maybe...

Sure, it could be a component or the server itself.

We'd probably want two modes (one for stringprep and one for PRECIS,
perhaps even two separate namespaces for those two modes) and the
ability to request transformation of domain names, localparts,
resourceparts, or complete JIDs. Given that locale can be significant
here (e.g., dotless "i" in various Turkic locales), the client would
also need the ability to specify an xml:lang.

Heck, it sounds like a simple little spec, maybe I'll write it up over
the weekend. ;-)


- -- 
Peter Saint-Andre

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


More information about the JDev mailing list