Thanks for the detailed review, Aaron!
> The SaslSocketTransceiver.transceive(...) method declaration should have a space after the return type.
> In SaslSocketTransceiver, it seems like saslResponsePiggybacked can potentially be read before its initialized. Should probably explicitly set a default value.
Java fields, unlike variables, always have a default value. The default for a boolean is false.
> Spelling in the "Overview" section of the protocol spec: "suceeds" -> "succeeds".
> In the "Negotiation" section of the protocol spec: I don't believe the mechanism name can be UTF-8. I'm pretty sure mechanism names are required to be a subset of ASCII, as defined in http://www.faqs.org/rfcs/rfc4422.html. Further, the mechanism name can only be up to 20 characters, so no need for 4-bytes to specify the length of the mechanism name.
UTF-8 and ASCII encode the characters permitted in mechanism names identically. But specifying UTF-8 is confusing, so I've removed that from the document.
I slightly prefer to leave the mechansim length at 4-bytes, since it simplifies implementation. At each step in the negotiation one always reads the status byte followed by a 4-byte length-prefixed payload. (In the case of the START message, one must read an additional, similarly formatted payload.) So not only would I need to add new methods to read and write one-byte length-prefixed strings, but I'd also have to separately read the payload of each message. If we really wanted to minimize bytes, we might also change the length of a FAIL message to be two bytes. Should I worry more about these wasted bytes?
> In the "Negotiation" section of the protocol spec: Is it really the case that "Once EITHER [capitalization mine] the client or server send a COMPLETE message then negotiation has completed successfully" ? i.e. should it not be "both" ?
I believe that when one side sends COMPLETE the other side does not respond, that a single COMPLETE terminates negotiation. I think that's what I've implemented. Without this, implementing an anonymous mechanism without adding a round-trip would be trickier.
> In the "Session Data" section of the protocol spec: You make reference to "steps 5 and 6" but there is no previous numbering of steps in the protocol.
Fixed. I wonder where that strange text came from?