PRO
The bis drafts incorporate errata and corrections, refer to updated IETF specs (e.g., SASL and TLS), reflect 3 years of implementation and deployment experience with XMPP as defined in RFCs 3920 and 3921, and in general are the most up to date definition of the core XMPP protocols. In addition, the next (-03) versions of the bis drafts will be much easier to read since I am in the process of adding more examples, splitting longer sections into subsections, etc. It seems good for developers to code from the best specifications we can produce.
CONThe RFCs are more stable. The bis drafts are officially works in progress and therefore are subject to change. Developers hate coding to a spec that is a moving target (on the other hand, they hate coding to a spec that will soon be obsolete, too).
SO...My sense is that the bis drafts are stable with respect to substantive matters. I am working to clean them up editorially right now, but those modifications are not substantive and will just make the specs easier to read and code from. That said, you never know what could happen during IETF Last Call, so it is still possible that the bis drafts could change in substantive ways.
(See the end of this message for the substantive diffs so far.)The intent is to get the bis drafts done soon (I think the -03 versions should be ready for IETF Last Call and I have all the changes for them noted on paper copies, I just need to find the time to key those in). So I think the bis draft should be very stable in a few weeks and, I hope, submitted to the IESG for their approval in (say) two months.
Developer feedback is requested regarding your preferences. Peter **** Differences From RFC 3920* Corrected the ABNF syntax for JIDs to prevent zero-length node identifiers, domain identifiers, and resource identifiers. * Corrected the nameprep processing rules to require use of the UseSTD3ASCIIRules flag.
* Encouraged use of the 'from' and 'to' attributes stream headers.
* More clearly specified stream closing handshake.
* Specified recommended stream reconnection algorithm.
* Specified return of <restricted-xml/> stream error in response to
receipt of restricted XML.
* Specified that SASL mechanisms must be sent both before and after
negotiation of TLS and of SASL security layers.
* Specified that TLS plus SASL PLAIN is a mandatory-to-implement
technology for client-to-server connections, since implementation of
SASL EXTERNAL is uncommon in XMPP clients, in part because underlying
security features such as X.509 certificates are not yet widely deployed.
* Added the <malformed-request/> SASL error condition to handle an
error case discussed in RFC 4422.
* More clearly specified binding of multiple resources to the same
stream.
* Added the <not-modified/> stanza error condition to enable
potential ETags usage.
* Added the <unknown-sender/> stanza error condition to provide
appropriate handling of stanzas when multiple resources are bound to the
same stream.
* Added section on advertisement of server dialback support,
including server dialback stream feature.
* Recommended use of HMAC-SHA256 for generation of server dialback key.
Differences From RFC 3921
* The protocol for session establishment was determined to be
unnecessary and therefore the content previously defined in Section 3 of
RFC 3921 was removed. However, server implementations may still want to
advertise support for the feature in order to ensure
backwards-compatibility, even though it is a "no-op".
* The protocol for communications blocking specified in Section 10
of RFC 3921 has been moved to [XEP‑0016] and a simplified "front-end" to
that functionality has been defined in [XEP‑0191] to ease the task of
implementing communications blocking in servers and clients.
* In order to more seamlessly repair lack of synchronization in
subscription states between servers, error handling related to presence
probes and presence notifications was modified to return presence
stanzas of type "unbsubscribe" or "unsubscribed" rather than error stanzas.
***
smime.p7s
Description: S/MIME Cryptographic Signature
