[Standards] compliance: RFCs or bis drafts?

[Peter Saint-Andre]

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.


***

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070613/ec562497/smime-0001.bin