[Standards] compliance: RFCs or bis drafts?
boyd.fletcher at je.jfcom.mil
Wed Jun 13 20:55:13 CDT 2007
+1 for bis -03 version
On 6/13/07 9:44 PM, "Peter Saint-Andre" <stpeter at jabber.org> 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
> * 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