Robin Redeker wrote: > On Fri, Jul 27, 2007 at 02:32:39PM -0600, Peter Saint-Andre wrote: >> Matthias Wimmer wrote: >>> Robin Redeker schrieb: >>>> I propose to rename the XEP to make clear that this escaping/unescaping >>>> should >>>> only happen in very rare cases (only at gateways or heavily specialized >>>> client >>>> frontends). And that the terms 'escaping' and 'unescaping' are replaced by >>>> 'mapping' and 'unmapping', because thats what is happening here. >>> +100 >> Well, it's interesting, on the ejabberd list today someone said they >> have an existing database of 45k email users and they want to offer >> Jabber services to that user population, but re-use the same usernames. >> I'm sure they have some users in there with addresses containing >> characters like single quote, e.g., tim.o'[EMAIL PROTECTED] In which >> case I bet that they'll be interested in using JID Escaping. > > If they can live with the fact that clients like: psim gajim, kopete, > pidgin, tkabber, ... http://www.jabber.org/software/clients.shtml > > That clients like those display the guy as [EMAIL PROTECTED] > And if they can teach their userbase that their JID contains \27 instead > of '.
Or do what this person is going to do -- prevent people who have ' in their email address from using Jabber! (Sorry, no address mapping for you!) >> I really feel that this discussion is not going anywhere. The spec is >> IMHO pretty clear. If you don't like the spec, don't implement it. > > I _certainly_ won't. But you are aware that you recommend every client > author to implement XEP-0106? (Hint: > http://www.xmpp.org/extensions/xep-0211.html ) Shockingly, I do tend to be aware of what is in the specifications I write. > XEP-0106 is certainly useful, and noone says it should go away, I would > just know WHO is supposed to implement it and in WHICH cases. In a client, the first thing to support is at least to transform the mapped characters to their unmapped equivalents on receipt. So show \27 as ' and so on. The second thing to support is: if the user attempts to add a buddy (or register an account etc.) whose JID has a node identifier containing ' or one of the other prohibited characters, transform the character to the mapped equivalent; alternatively, the client could reject the attempt ("sorry, those characters are disallowed") since that is what clients do now -- be conservative in what you send, liberal in what you accept. It is possible that a server could perform the mapping as well, depending on the authentication mechanisms in use. E.g., let's say that at a certain deployment, the user's authzid is derived from the email address in the user's X.509 certificate or LDAP record. In this case, if the user's email address is tim.o'[EMAIL PROTECTED] then the server would specify the user's JID as [EMAIL PROTECTED] Would it help to clarify this handling further in the spec? /psa
smime.p7s
Description: S/MIME Cryptographic Signature
