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/
smime.p7s
Description: S/MIME Cryptographic Signature
