> > > Ah. Using the first round of RCPT TOs as capabilities checks only and sending > > > the RSET unconditionally is really quite cute. > > > "cute" is rather opposite of the four-letter word I would have chosen. > > > > It still has the added > > > complexity of having multiple commands per recipient, but now it is the same > > > command repeated, which eliminates a bunch of the edge conditions and makes the > > > silly states very silly indeed. > > > well, I'll admit I'm curious - how does using the same command in two different > > ways eliminate a bunch of edge conditions? (if we had only one command in SMTP > > and used it over and over would that eliminate even more edge conditions?) > > The edge conditions arise when the responses from the different commands > disagree in some way. And this is likely to happen when there are two commands > and two different code paths. The usual outcome then is that things which > shouldn't make a difference do make a difference, and that then leads to the > time honored whine of "but it works when I do it over there so this stuff here > must be broken". ah. well it was sort of obvious to me that RCAP responses should be defined to provide no indication whatsoever as to whether the recipient is valid, so you couldn't get a conflict between a RCPT indication and an RCAP indication. on the other hand either command could return a value that would prevent delivery of the message - RCPT could return 5xx and RCAP could return "this recipient supports no content types you've ever heard of", and either one could cause a temporary failure of message delivery. I don't consider that a silly state - it's a natural consequence of being able to specify what content types you're willing to accept. however I really don't have a problem with an option to RCPT to return UA capabilities as long as it is an extensible mechanism (other options could return other information and could be asserted at the same time as CONNEG) and as long as it doesn't affect the response and status codes. Keith