Ralph Meijer wrote: > On Thu, 2007-08-02 at 17:21 +0200, Robin Redeker wrote: >> It seems that at least the majority of the whidely deployed servers >> support \ in JIDs in DIGEST-MD5 SASL authentication due to faulty SASL >> DIGEST-MD5 implementations. >> >> However, using the PLAIN authentication method seems to work! > > Well yeah. As we discussed in the jdev room, the DIGEST-MD5 mechanism > keeps on piling up new issues. SASL lib devs are tired of its complexity > and incompatible implementations. > > As was suggested in March in response to the unwillingness to go further > with the DIGEST-MD5 bis RFC (following RFC 4422), we should think about > dropping DIGEST-MD5 altogether in favour of something based around > SHA256, for example.
+1 > That said, I'm wondering if we should really try to go further with > general JID escaping. I'm sure in some edge cases, you would want to be > able to use apostrophes in user ids. But I think that that is rare. I've > never seen an e-mail address with an apostrophe. I have feedback from deployment land that this is a sticking point. For a recent instance see the following three messages: http://lists.jabber.ru/pipermail/ejabberd/2007-July/002850.html http://lists.jabber.ru/pipermail/ejabberd/2007-July/002851.html http://lists.jabber.ru/pipermail/ejabberd/2007-July/002852.html > Also, why go through all the effort to sync with e-mail addresses when > we have a far richer character repertoire in terms of non-latin > characters? Note that RFC2822 doesn't even allow umlauts, for example, > so you can never translate full names to usernames in either addressing > scheme. Oh for sure. We don't care here about Jabber->email but email->Jabber because people want to re-use existing userids. > Do we really need to have these extra characters? Yes. To be clear: not everyone does. This may be a somewhat specialized deployment issue. For people with this issue, JID Escaping is very helpful. For everyone else it simply may not matter. So it is good for us to have XEP-0106 sitting around for people who need it. To me this may mean that client and server implementations that get deployed in these special environments may want to have a plugin or module that does JID Escaping (e.g. to reuse existing credentials or gateway to wacky things like Wireless Village), but that it should not be something that is supported in the core of an implementation. Which would provide an argument for removing it from the compliance suites (even at the recommended level) and clarifying the scope of applicability in XEP-0106. And maybe that would enable us to end this damn thread. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
