[Standards] compliance: RFCs or bis drafts?
hildjj at gmail.com
Thu Jun 14 05:42:37 UTC 2007
As much as I expect that the bis drafts are better, they haven't had
I'd recommend 3920 and 3921, with a reference to the bis drafts for
On Jun 13, 2007, at 7:44 PM, Peter Saint-Andre wrote:
> In today's meeting of the XMPP Council we discussed whether the
> specifications we will use for the 2008 certification program
> (i.e., XEPs 211 and 212) should refer to rfc3920bis and rfc3921bis
> (the in-progress revisions to RFCs 3920 and 3921, a.k.a. "the bis
> drafts"). Here is my take:
> 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.
> The 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).
> 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.
> 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.
More information about the Standards