Does he need an excuse for wanting to correct misinformation ?
Does he need an excuse for wanting to correct misinformation ?
As the designer of something, you are too invested in it to handle someone going "this sucks!" well. My advice would be to sit back, recognize that the other person saying this is not invested to the same degree, is looking at the problem from the completely opposite perspective and is not familiar with the reasons behind every single compromise made, or why a certain feature seemed like a good idea at the time but turned out not to work in practice. Let someone else handle the defense.
It doesn't matter if there are valid criticisms to be made - inevitably, everyone describing the specification who weren't involved in writing it will misunderstand something, or leave something out, or quote something out of context or incompletely, or have completely different concerns in mind than the authors did - and as that author you are drawn to such things like a moth to the flame. But you have to resist the flame. After all, you wrote it, it does what you intended, you released it. If someone else wants something different, let them be unhappy and maybe if they are unhappy enough they will come up with their own thing.
Based upon this one instance where he shows up and correct misgivings ? Seriously ?
If anything you come across annoyed that your uninformed ranting was corrected.
Hey, all I did in my comment was to quote from the spec. My complaint (well, one of them) is that it's a "binary" protocol but it requires parsing just like an ascii protocol, it encodes data as ascii values and it even embeds a full ascii protocol in the auth sequence. (not to mention XML for reflection with an embedded type DSL in attributes, ...)