Chen, Hao wrote:
In my previous post, I want to ask if I should let my codes do some checking after TLS negotiation and before SASL negotiation. Now my codes start SASL immediately after a successful TLS negotiation and this is what I understand from the XMPP spec.
IMHO a server implementation should not return an error if the initiating entity (e.g., client) sends something other than SASL negotiation immediately after negotiating TLS, although this depends somewhat on the implementation and deployment. For example, the server might advertise other features and the client might want to negotiate one of those first. Examples include stream compression (JEP-0138) and in-band registration (JEP-0077) (see [1] for a complete list). RFC 3920 says that the initiating entity should proceed with SASL negotiation after completing TLS negotiation, but a receiving entity that is liberal in what it accepts should not reject other negotiations at that point if it allows things like compression or in-band registration. Or so it seems to me.
Peter [1] http://www.jabber.org/registrar/stream-features.html
_______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
