> > I don't understand which argument you're making - is it that the naive > > implementation is slow, or that it's too hard to do an efficient > > pipelining implementation? > > Both: The naive implementation has latency problems while the efficient > pipelining implementation is more complex than it needs to be. okay, I'll certainly grant that the naive implementation has worse latency if you use extra commands. though it seems like if you're going to have the complexity of parsing conneg strings and doing format translation, the additional complexity of pipelining doesn't make it much worse. as for the pipelining, to me the complexity seems about the same either way, but with overloading of RCPT response codes then you're asking the server to declare failure modes that really need to be detected by the client, and having the server report the error doesn't seem to simplify the client logic at all. nor have I managed to find a use case for treating no conneg string as a fatal error, though I don't claim to have exhaustively analyzed all possibilities yet. > > as long as RCAP doesn't force any new decision points for the client, > > I don't see why the efficient pipelining implementation is any more > > difficult for the RCAP case than the RCPT/RSET case. > > Then I suggest you haven't actually looked closely at how you'd actually code > this. Two responses for each recipient lead to a bunch of corner cases that > have to be dealt with. no, I haven't tried to code it in detail yet. but it doesn't seem like rocket science to map a cross product of the 3 or 4 existing RCPT responses that clients need to distinguish, and the 3 or so conditions for RCAP (here is the string, there is no string, tempfail) onto a small number of cases. and the client pretty much has to do that anyway, because there can be failures due to inability to convert even if all RCAPs return a conneg string. > > if RCPT is overloaded then the client sends multiple RCPTs, waits for > > all of the responses, then decides whether to just send one copy or > > do RSET/MAIL/etc and send multiple copies. > > > if there's a separate command then the client sends multiple RCAPs, > > and one RCPT, waits for all of the responses, and then decides > > whether the version that's right for the first recipient is also > > appropriate for other recipients. > > > seems like the implementation complexity is about the same in either case. > > Sigh. This is pretty much a strawman argument, but rather than get into that > let me simply repeat my earlier conclusion: I believe that if support for > sending more than one variant of the same message is likely then a separate > command makes sense. If, on the other hand, this is the very uncommon case, > then RCPT TO piggybacking is much simpler and a separate command doesn't make > sense. > > Do you really wish to claim otherwise? Hmm. If I'm trying to compare protocol and implementation complexity then I care about the amount of code that's required to accomodate all cases even if many of those cases aren't used very often. If I'm thinking about protocol efficiency then I care more about the commonly occuring cases. as for what is a commonly occuring case, I get a different answer depending on whether I think of this as a fax-specific mechanism or a general purpose SMTP mechanism. if it's only fax specific then I suspect the common case is for most messages to have only one recipient, so if the rare multi-recipient message takes a slow path that might not be so bad. if the mechanism is more general purpose then I suspect multi-recipient messages (and widely-varying capabilities) will be much more common and it will be more desirable to avoid sending a separate copy of each message, and this in turn makes reasonable implementations (of either proposal) more complex. The other concern I have is something like "protocol architecture" - will this extension mess up the protocol in such a way that it creates silly states or makes it more difficult to add other kinds of extensions? what I'm discovering is that I'm much more concerned about overloading the RCPT reply/status code rsponses (using them to mean two different) things than I am about piggybacking a conneg string onto the RCPT response. if the conneg response didn't affect the reply and status codes, and if other extensions could also piggyback additional data onto the RCPT response, then I don't think that the fact that additional information is being requested along with RCPT would bother me. the thing that bothers me is that RCPT error codes are being used to signal a case that really has nothing to do with the recipient's ability to receive a message. >t > > but it's hard to see how the client can avoid implementing some > > kind of logic to convert differently for different recipients, since > > there's clearly the potential for the recipients' conneg strings to > > have no format in common. perhaps if the client can only do one > > or two different kinds of conversion (otherwise it has to bounce) > > then the decision becomes a bit easier, but this again looks more > > like a fax-specific facility than a general one. > > On the contrary, I suspect that this issue can and will be avoided. John > phrased it well: Select the least common demoninator that's above a certain > threshhold. That sounds like the right implementation strategy to me. that assumes that there is a LCD, which is not true in general. (though it might be true for a fax-only extension.) and unless the set of permissable content-types is severely restricted, how can the client know what is a reasonable threshhold? Keith