The significant change made was that in the drafts from wd05 until wd13, it was allowed for the server to completely ignore the client request to use enhanced authentication. Thus the implementation of enhanced authentication requires that both client and server have support for enhanced authentication. The changes in wd14 require that the server implement enough of enhanced authentication to respond to the client that it does not support it.
I prefer the former, but this is not a lot of work for server which do not support enhanced authentication.
There is also a change that the CONNACK packet MUST include an Authentication Method if there was one on the CONNECT. This brings up problems that we are defining the order of error handling. For instance if I find a problem with the CONNECT packet without first parsing the Authentication Method property, I would return the CONNACK without the Authentication Method and thus violate this MUST. Consider the simple example that the Authentication Method is not a valid UTF-8 string. My only alternative at that point to not violate the spec is to close the connection without sending a CONNACK.
I would return to saying that the server MUST set the Authentication Method property on the CONNACK only if the return code is 0.
The text saying that if the method is client-first the data should be sent on the CONNECT was removed leaving just the generic statement that the method defines what is in the authentication data. The corresponding statement about the final server data being on the CONNACK is retained. The problem is that in general the SASL mechanisms define the data flow, but not how this is mapped to a particular protocol. It might be best to state both of these as non-normative comments as to the expected mapping of SASL mechanism data exchange into MQTT packets.
Major
The significant change made was that in the drafts from wd05 until wd13, it was allowed for the server to completely ignore the client request to use enhanced authentication. Thus the implementation of enhanced authentication requires that both client and server have support for enhanced authentication. The changes in wd14 require that the server implement enough of enhanced authentication to respond to the client that it does not support it.
I prefer the former, but this is not a lot of work for server which do not support enhanced authentication.
There is also a change that the CONNACK packet MUST include an Authentication Method if there was one on the CONNECT. This brings up problems that we are defining the order of error handling. For instance if I find a problem with the CONNECT packet without first parsing the Authentication Method property, I would return the CONNACK without the Authentication Method and thus violate this MUST. Consider the simple example that the Authentication Method is not a valid UTF-8 string. My only alternative at that point to not violate the spec is to close the connection without sending a CONNACK.
I would return to saying that the server MUST set the Authentication Method property on the CONNACK only if the return code is 0.
The text saying that if the method is client-first the data should be sent on the CONNECT was removed leaving just the generic statement that the method defines what is in the authentication data. The corresponding statement about the final server data being on the CONNACK is retained. The problem is that in general the SASL mechanisms define the data flow, but not how this is mapped to a particular protocol. It might be best to state both of these as non-normative comments as to the expected mapping of SASL mechanism data exchange into MQTT packets.