[Standards] compliance: RFCs or bis drafts?

[Mridul Muralidharan]

This makes a lot of sense.
This is how we tend to use the bis specs right now.

Regards,
Mridul

Joe Hildebrand wrote:
> 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.
>>
>>
>> ***
>>
>