Hi, > Not very likely. One thing is that the test suite won't be > complete, for > various reasons. What should it do about changing email formats, for > example? When RFC X supersedes RFC Y, what is to be tested?
I would argue that the tool be updated so that there would be one for both RFC's. If an incompatibility were introduced due to a differing message format then that would fall outside the tool unless the message format behaviour was already covered in the protocol. The test tool would also be under version control so that should anything be missed it could be revised. > > What the formal grammar permits, a server should permit. > Surly this is not always the case. I'm sure I have seen examples on this list where the response has been "Although the formal syntax allows that its clearly silly". Unfortunately what is silly to me is probably not so to someone else :) > > AFAIK you can't. The best you can do is stay on this list and > on imapext. > > > Personally I don't think any RFC that specifies a protocol should be > > released without a protocol validation suite. > > Many internet standards have something different - they have > a reference > implementation (usually one from which others can steal code freely) > and mailing lists where the implementers hash out issues. Some had > multiple interoperable implementation by the time the RFC was written. > But many of these are open source. Thus commercial writes cannot make use of them and in many cases it would not be appropriate. Richard.
