This is a bit of a geeky post, but it captures something I've thought about as I've been working on rfc3920bis and rfc3921bis of late: namely, that there are several layers in XMPP technologies. In particular:
In RFC 3920 ("XMPP Core") we defined the presence, messaging, and request-response services, but the XML schemas for that functionality were specified in RFC 3921 ("XMPP IM") because there are some IM-specific semantics defined in those schemas. Now I'm wondering whether it makes more sense to define only XML streams (and associated features like TLS for channel encryption and SASL for authentication) in rfc3920bis and to define everything related to the jabber:client and jabber:server namespaces in rfc3921bis.
(One reason for doing so would be to make it clear that people could use XML streams with default namespaces other than jabber:client and jabber:server -- e.g., someone could define a specialized default namespace for synchronization of Atom feeds or SVG images or somesuch.)
The major documentation challenge here is that resource binding in a client-to-server stream uses the <iq/> element, which is qualified by the jabber:client namespace. If resource binding stays in rfc3920bis, then we would require a normative reference from rfc3920bis to rfc3921bis. If resource binding moves to rfc3921bis, then rfc3920bis might lose the distinction between c2s and s2s streams. But I think that's surmountable
Whether it's worth the effort to refactor the specs in this way is open to argument. But given that I expect rfc3920bis and rfc3921bis to define XMPP for a long time to come, it might make sense for the layering to be as clear as possible.