[Standards] JID Escaping
stpeter at jabber.org
Thu Aug 2 16:11:25 UTC 2007
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.
> 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:
> 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
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?
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards