[Standards] compliance: RFCs or bis drafts?
stpeter at jabber.org
Wed Jun 13 20:44:50 CDT 2007
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:
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.
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).
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.
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
* 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
* 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
* 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...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070613/ec562497/smime-0001.bin
More information about the Standards