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