[Standards] compliance: RFCs or bis drafts?

[Joe Hildebrand]

As much as I expect that the bis drafts are better, they haven't had  
cross-area review.

I'd recommend 3920 and 3921, with a reference to the bis drafts for  
clarification.

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:
>
> 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.
>
> CON
>
> 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).
>
> 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.
>
>
> ***
>