+1 for bis -03 version
On 6/13/07 9:44 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> 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. > > > *** >
