> Yes, but as Noel said well last week, testing real-world client > compliance and RFC compliance are somewhat separate things.
+1 I agree totally with Noels mail, there are RFC issues which affect almost no-one, +which have to be explicity tested, my example is quoted local part of mail addresses, +and non-compliant observed behaviour that affects almost everyone, the example being +case-insensitive local part. I agree that we have to aim our testing regime, not soley for IMAP, at testing for compliance based upon the published RFC's, and add higer level tests for observed behaviour. Wherever there is a conflict between standard and expected behaviour James *must* support the standard but *may* provide a switch to replace this with the non-standard behaviour. AFAIK this has only occured once, in the case sensitivity of address local-parts, and was handled successfully in the way I just described. > I've begun > to write up some rough plans for the testing architecture that he was > talking about, and I think that a careful reading of the RFCs to produce > functional tests will give us excellent coverage for the full range of > RFC functionality. As a separate step, we will need to record scripts > of client server behavior between existing clients and existing IMAP > servers, and find a way to incorporate the peculiarities we find into > our testing infrastructure. > > Noel, am I reading you right? Corrections welcome :) > > -Nathan > > > > Harmeet > > > > > > -- > > To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
