[jdev] ejabberd & feature advertisement

[Eric Will]

According to RFC3920, section 6.2, entry number 2:

... If Use of TLS needs to be established before a particular
authentication mechanism may be used, the receiving entity MUST NOT
provide that mechanism in the list of available SASL authentication
mechanisms prior to TLS negotiation...

However, ejabberd promptly offers up <mechanism> elements before TLS
has been established.

$ nc malkier.net 5222
<stream:stream xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:client' version='1.0' to='malkier.net'>
<?xml version='1.0'?><stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' id='258335359'
from='malkier.net' version='1.0'
xml:lang='en'><stream:features><starttls
xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><mechanisms
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechanisms><register
xmlns='http://jabber.org/features/iq-register'/></stream:features>

Or is this a technicality, since TLS isn't "required" (ejabberd allows
legacy auth to any client it seems)? The jabber.org server returns
only starttls.

--
Eric Will -- http://www.ericw.org/
xmpp:rakaur at malkier.net
mailto:rakaur at malkier.net