Sending features — TLS and SASL at once?

I’'m seeing that Wildfire sends the TLS and SASL features in the same features stanza directly after the initiating entity has opened the stream. However, it seems that maybe it should only send the TLS feature (and not SASL) if TLS is required by the server. RFC 3920 has this to say: “If the initiating entity chooses to use TLS, TLS negotiation MUST be completed before proceeding to SASL negotiation; this order of negotiation is required to help safeguard authentication information sent during SASL negotiation, as well as to make it possible to base the use of the SASL EXTERNAL mechanism on a certificate provided during prior TLS negotiation.” Is there a specific reason Wildfire also sends the SASL mechanisms at that time?

I think its an ease of implmentation. If the server requires TLS before SASL, the server will simply reject any SASL auth if TLS has not occured. I think the impact here is pretty minimal, too. Most legit clients will start TLS first anyway, since that is the logical thing to do. You only need to worry about broken clients and people with too much time on their hands. The broken clients are easy enough- just switch clients or track down the author and tell them to fix it. The people with too much time on their hands, well, SASL will fail anyway. I admit there is a slight security risk since the username and password may have been transmitted in cleartext, but it seems pretty dumb to want to do auth before TLS.