[Standards] XMPP 1.1?

Peter Saint-Andre stpeter at jabber.org
Thu Aug 2 17:52:34 UTC 2007


If we define nodeprep2 in rfc3920bis then I think we need to finally
"bite the bullet" and say that rfc3920bis defines "XMPP 1.1". This
probably means that we need to cycle the XMPP specifications at the
Proposed Standard level in the IETF. I can't say that this makes me
really happy, but there is some uncertainty within the IETF about IDNA
(i.e., internationalized domain names) so it is quite possible that our
dependency on IDNA would mean we can't move XMPP forward to Draft yet
anyway. And in any case I think it is the most honest way to proceed.

About versions of XMPP, RFC 3920 says:

   The minor version number indicates new capabilities,
   and MUST be ignored by an entity with a smaller minor version number,
   but used for informational purposes by the entity with the larger
   minor version number.  For example, a minor version number might
   indicate the ability to process a newly defined value of the 'type'
   attribute for message, presence, or IQ stanzas; the entity with the
   larger minor version number would simply note that its correspondent
   would not be able to understand that value of the 'type' attribute
   and therefore would not send it.

I think nodeprep2 falls into the category of "new capabilities". So do
some of the other substantive changes between RFC 3920 and rfc3920bis,
which according to Appendix F of rfc3920bis are:

    * 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 on stream headers.

    * More fully specified stream closing handshake.

    * Specified recommended stream reconnection algorithm.

    * Specified return of <restricted-xml/> stream error in response to
receipt of prohibited XML features.

    * Specified that SASL mechanisms must be sent both before and after
negotiation 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 fully specified binding of multiple resources to the same stream.

    * Added the <unknown-sender/> stanza error condition to provide
appropriate handling of stanzas when multiple resources are bound to the
same stream.

    * Added the <not-modified/> stanza error condition to enable
potential ETags usage.

    * Removed historical documentation for the server dialback protocol
from this specification to a separate specification

To this list we could perhaps also add removal of the DIGEST-MD5 SASL
mechanism from the list of mandatory-to-implement technologies (if we
decide to do that -- I need to contact some folks at the IETF about the
issues with DIGEST-MD5).

Thoughts?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070802/6ff3037b/attachment.bin>


More information about the Standards mailing list