[jdev] Necessity of stringprep support for the client

Peter Saint-Andre stpeter at stpeter.im
Sun Aug 19 02:13:16 UTC 2012

Hash: SHA1

On 8/17/12 5:57 PM, Ralph Meijer wrote:
> On 2012-08-17 18:22, Peter Saint-Andre wrote:
>> On 8/17/12 10:16 AM, Jack Moffitt wrote:
>>>> Heck, it sounds like a simple little spec, maybe I'll write
>>>> it up over the weekend. ;-)
>>> I suggest that the JavaScript side API be the same as the W3C
>>> one, so that this can act as a shim for browsers that don't yet
>>> have that support.
>>> If we made it an HTTP API, then people outside the XMPP world 
>>> could use the same thing. The only thing we'd really need is
>>> some modification of the stream features to include the API
>>> endpoint so that clients can find it.
>> Well, I'd see HTTP and XMPP as two different ways of accessing
>> the same service. Given that such a service could be
>> resource-intensive to run (in fact, the XEP would need some
>> security considerations about denial of service attacks), I would
>> think that client authentication or registration would be
>> necessary or strongly suggested. In the case of XMPP, the server
>> is in charge and I expect that it would offer this service only
>> to its registered users (and any abusive users from its domain
>> could be easily disabled). In the case of HTTP, the story is less
>> clear to me.
> What about stringprepping (parts of) the JIDs used to connect to
> the server? I.e. before feature negotiation is complete and the
> client may start sending stanzas? I'm thinking of the stream's
> addressing attributes, username (SASL) and resource (resource
> binding).

Right, but the server will correct your full JID during
authentication. After that, you could check every non-ASCII JID or
JID-part with the server-side prepping service.


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