> > > If the sender is concerned about optimizing for each recipient, they can > > > get that effect by reducing to a single RCPT-TO per DATA. > > > >if several recipients have similar capabliities, sending a separate > >copy of each message hardly seems like an optimization. > > Keith, the one thing that is certain is that no specification can satisfy > requirements that are constantly being changed. > > You expressed concern about content being tailored to each recipient's > capabilities. This proposal supports that. it doesn't support that explicitly, and the only ways that you can do it with your proposal are more complex and/or expensive than the alternative I've suggested. > You would prefer to achieve > that in a different way, with is certainly your right, but the current > specification satisfies it. the current specification allows it, though it doesn't explain how it allows it, and it's incomplete. > Now you are expressing concern about content that is tailored to "several > recipients" that have "similar" capabilities. That is quite different from > anything you have raised before. there are different cases that need to be considered, and I don't claim to have enumerated them all yet. nor do I believe there's a requirement to enumerate all of my concerns with your proposal in a single round-trip. indeed, I'm still trying to articulate some of them. > I am sure that you can discover all sorts of boundary conditions that are > unlikely and for which the current specification is not optimized. and among them, some boundary conditions which are likely and some failure modes which aren't considered. but of course you'll assume that everybody will use the protocol exactly as you intended, even though you didn't bother to even explain how you assumed the protocol would be used. that's no way to write a standard. > And, of course, you continue to ignore minor matters of efficiency for what > is expected to be the typical cases, namely sending a common set for all of > the recipients and sending a single content for a single recipient. I didn't ignore it. but you failed to mention these in the document. and somehow you seem to think it's okay to insist on a minor optimization of saving a round-trip by overloading RCPT when you have the major lossage of having to send separate copies to each recipient when there's no common set available. nor is it clear to me why downgrading to a single common format, just because the sender happened to specify multiple recipients on the TO, cc or bcc field, is acceptable from the sender or recipient's point of view. (last time I sent you a fax you got high quality color, but this time you got low-res black/white ... what gives?) even if it's okay with the fax people I'd take serious issue with this kind of haphazard conversion being applied to ordinary email. > > > So it is not as pretty as the separate command, but it permits roughly the > > > same mode of operation. > > > >overloading RCPT is simply unacceptable. > > Keith, your term "overloading" suggests that RCPT-TO parameters are being > invented here. no, it suggests that overloading the RCPT reply code to indicate a condition other than "this message cannot be sent to this recipient" is a bad idea. > In any event technical discussions are facilitated by have a discussion > about technical merits. They usually are not facilitated by having > participants pretend that they have a veto. nor are they facilitated by having the proposer pretend that His is the unimpeachable Word of God and trying to deflect technical criticisms with personal attacks. Keith