> > You can't really assume that the client will do SASL after
successful
> > TLS negotiation. They might negotiate compression, ACK,
registration,
> > non-sasl auth, dialback, or some other stream feature.
> >
> > In all the implementations I've seen this is allowed and SASL is not
> > necessarily even required on an XMPP stream.
>
> RFC 3920 requires SASL authentication. Many existing Jabber ("XMPP
0.9")
> servers will also accept JEP-0078 authentication but that is not part
of
> RFC 3920.
True. However, the text does leave the impression that SASL is the next
thing you do after TLS, when in fact there could be quite a few stream
features you choose to put into place prior to authenticating(register,
compression, for example). Perhaps we should attempt to loosen this
wording a bit in the next round?
-JD
_______________________________________________
jdev mailing list
[email protected]
http://mail.jabber.org/mailman/listinfo/jdev
