At 09:51 AM 7/13/2002 -0400, Keith Moore wrote:
> Moore-san prefers to have the capabilities query be in a separate
> command. For convenience, he has given this command a name, RCAP. So,
the
> name refers to an idea that Moore-san has. There is no written
> specification for that command. In my opinion, the current specification
> is satisfactory.
...
if the message being transmitted is a fax and all recipients are capable
of fax,
then perhaps it is acceptable to downgrade the message to a lower quality fax
format which is acceptable to all.
Ever since multi-recipient addressing was introduced, we have had
downgrading, by virtue of users having to choose the least common
denominator approach to sending attachments.
So the fact that this new mechanism allows that downgrading to happen later
in the transmission sequence should not confuse anyone into thinking that
downgrading is a new or unusual requirement.
the use of the RCPT response to tell the client of the recipient's
capabilities
is odd because it asserts that the client intends to deliver a message to
each of several recipients before the client actually knows whether it can
deliver the same version of the message to each recipient, or whether it can
deliver any version of that message to the recipient.
"or whether it can"??? There has been no posting that provides a practical
basis for such a conclusion.
Therefore, any implications of this unproved -- and frankly
counter-intuitive and highly unlikely -- assessment has nothing to do with
the current specification.
so as the proposal is written, any client which attempts to deliver a message
to multiple recipients in a single transaction must be prepared to abort the
current SMTP transaction (presumably by using RSET) after sending multiple
RCPTs,
It is NOT required to do that. Nor is the ability to send an RSET during a
session a big deal. In fact, that's what the command is there for.
it's been claimed that using RCPT in this way is faster that using a
separate
command,
Faster for single-recipient use, yes. Faster for multi-recipient use, with
common format, yes.
In both cases there are fewer commands and fewer round-trips than when
using a separate capabilities-query language. It does not take deep
analysis to know that the current proposal is faster.
Faster for the particular scenario you used, with an RCPT? No. That has
not been claimed. Using RSET is expensive. A design that calls for its use
makes sense only if that use is expected to be atypical.
As has been discussed previously use of the current specification is based
on the expectation that use of RSET will not be a typical.
another problem with RCPT is that it expects the server to return status codes
for error conditions that can only be distinguished on the client.
There is no such expectation:
"If the SMTP server supports ENHANCEDSTATUSCODES [RFC1893], the..."
Apparently you missed the "If".
In any event, i have no idea why the codes are somehow uninterpretable by
any system other than the client.
At 10:16 AM 7/13/2002 -0400, Keith Moore wrote:
> The UA-based CONNEG mechanism does query/response between two UAs that are
> connected only by the store-and-forward email service. ...
perhaps not, but once a message is relayed, the conversion (and the decision
of whether to deliver the message) is no longer under control of the sender -
I have no idea what you mean by "under control of the sender" nor do I have
any idea how the current proposal has any practical difference in control,
from any other proposal or idea for content negotiation.
actually the most likely scenario when using the conneg proposal with the
current infrastructure is that the message will be delivered, without
conversion, regardless of recipient capabilities.
And I have no idea where this assessment is based on, nor does it make any
obvious sense.
d/
----------
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
tel +1.408.246.8253; fax +1.408.850.1850