Bug #963
subscription replies sent to wrong jid
| Status: | New | Start: | ||
| Priority: | Normal | Due date: | ||
| Assigned to: | Justin Karneges | % Done: | 0% |
|
| Category: | Backend/Core | |||
| Target version: | 0.14 | |||
| Operating System: | All |
Reported in: | 0.12 |
|
Description
I recently used JID escaping feature in my transport and found the bug in Psi that is rather annoying. Here is it:
* Server sends subscription request:* Psi shows "123456789\40icq.d..." in the roster with exclamation mark (Psi MUST should it as "123456789@icq.darkk.net.ru@meta.darkk.net.ru" according to the XEP-0106) * User clicks and sees subscription request coming from "123456789\x5C40icq.darkk.net.ru@meta.darkk.net.ru" (Double-escaping is a bad thing to do) * User clicks "Deny" button and Psi sends following stanza: <presence type="unsubscribed" to="123456789\x5c40icq.darkk.net.ru@meta.darkk.net.ru" /> (Double-escaping without unescaping is not good to) So, "to" attribute of the last stanza is obviously wrong, the subscription request is not answered and the user is asked for it again on the reconnection. Multiply that by ~100 subscription requests and that gets annoying. :-)
History
Updated by Justin Karneges 241 days ago
Psi doesn't support XEP-106, and there is no immediate plan to. XEP-106 is a spec to allow certain characters in jids when they would otherwise not be allowed. This is done by coming up with encodings for the disallowed characters using sequences of allowed characters, and then having clients display jids with the disallowed characters (for example, "user@host@example.com"). I see no problem with standardized escaping for disallowed characters in usernames (after all, every server implementation that supports integration with existing user databases will need an escaping scheme in order to create jids, and standards are nice), however I disagree with the idea that the unescaped forms of usernames should ever be displayed as part of a jid. At most, a smart client could decode the node portion of a jid and display it separately. But displaying user@host@example.com as a "jid" is not a road we should go down.
That all said, Psi does have an escaping mechanism, but it's proprietary for Psi and it serves a completely different purpose than XEP-106. The escaping in Psi is meant to disallow characters in jids that are otherwise normally allowed, so that these characters can be used as delimiters when the jid is displayed to the user. If Psi does not unescape when replying to a subscription request then that's a bug.