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.
***
