[jdev] Necessity of stringprep support for the client

[Ralph Meijer]

On 2012-08-17 18:22, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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).

-- 
ralphm