> 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. The obvious case would be one where interoperability between sender and recipient has to be guaranteed. Whether this is a case we should care about is another matter. I note in passing that the original proposal required treating the lack of a conneg string as a fatal error. I saw far more utility in allowing the case of no conneg string to be allowed without an error. > > 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. I'm less sanguine about making this assessment a FAX-vs-other-uses thing, but the bottom line is that I think we're pretty much in agreement here. > 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. Well, it is certainly possible to arrange the additional conneg data so it is identifiable as such. As for not affecting the response, I'm not sure I see the problem: If the client wants an interop guarantee, it requires a conneg response, and handles 4yz and 5yz codes as temporary or permanent failures without regard to what's causing the error. If, on the other hand, it wants conneg info as long as its available, it makes a conneg response optional, in which case the status codes no longer have anyhing to do with conneg information. > > > 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? Such thresholds are driven by the client's own capabilities, not on the capabilities of the recipient. Ned