granted it's necessary for the client to be able to do that, but my
point
is that having the server report conneg faliures in the RCPT status code
doesn't relieve the client of the necessity to detect other conditions
resulting from valid conneg strings that can cause delivery failure.
it's not as if the client can rely only on the response code to
determine
how to handle the message.
Sure, but it is only useful to treat such failures as permanent.
how so?
Because you said: "other conditions resulting from valid conneg strings that
can cause delivery failure." If the conneg result is something you do not like
I don't think treating this as a temporary failure in hopes the conneg string
will change in the future is either reasonable or appropriate.
When you said "such failures" I wasn't sure which failures you were talking
about -
the ones that are caused by server inability to supply a conneg string or those
caused by conneg strings that indicate that no conversion is possible. (since
the quoted paragraph mentioned both kinds of failure)
if there is a temporary failure to get conneg information, the
client might quite reasonably decide to retry later. or if the client
can't translate part of the message, it might reasonably decide that
delivering the remainder of the message is preferable to bouncing it.
That wasn't the case you were talking about.
That response was based on a guess as to what you were talking about.
I guessed wrong.
I remain unconvinced that this is a useful distinction. What REQUIRED
says is
"I absolutely require CONNEG info and as such a failure to have it is the
same
to me as any other sort of failure and should be responded to
accordingly".
it's still poor separation of function, and it's still asking the server
to report a failure condition which the client understands better than the
server does. E.g. the server is told to report errors as 4.3.3 or 5.3.3
when codes x.6.1 or x.6.2 or x.6.3 might be more appropriate. The server
can't tell the difference between those conditions; the client can.
Ah, I see. We've moved from assertions that there were sure to be problems to
the nonspecific "poor separation of function".
Admittedly "poor separation of function" is a nonspecific description of the
problem,
but a more specific description followed which described what I meant.
Asking the server to report reply codes and (more importantly) enhanced status
codes that don't accurately describe the condition that caused the failure,
(and cannot, because the server lacks the information necessary to distinguish
those conditions) doesn't seem like good protocol design to me. The words
"poor separation of function" seem like an accurate description of this kind of
design flaw, though I wouldn't expect someone to understand my criticism of the
design (or accept the argument for changing it) from those four words alone.
But the entire point of REQUIRED
is to say "I don't want these functions separated; conneg failures are just
like any other failure to me".
Admitted that this is the entire point of REQUIRED; the question is whether
this is good design or an appropriate feature to include. Using REQUIRED
doesn't simplify the design of the client by any significant amount (if
at all), and by using REQUIRED a client somewhat impairs its ability
to produce meaningful error reports.
In short: REQUIRED is not necessary because clients can detect a missing
CONNEG string by other means, it doesn't seem to be useful because it
doesn't simplify either the client or the server nor make them more
efficient, it encourages client implementors to produce less meaningful
error reports, and even though the implementation overhead is low, it
does add additional baggage to the protocol.
The real question is, why do we want this?
Why? If the client doesn't want CONNEG to alter the status all it has to
do is
use OPTIONAL rather than REQUIRED. Again, REQUIRED implies that the
client is
willing to treat different sorts of failures in the same way.
well, if we had such other features then the client wanting to assert such
other features would not be able to assert CONNEG=REQUIRED, it would just
have to implement the error detection by itself.
Doesn't follow. If some other functionality is implemented that results in
RCPT
TO failing in some new way it can return errors in the same way. Of course the
error report is limited to a single error condition, but the potential for
multiple failures having to be collapsed into a single return value already
exists in abundance; the existance of this extension or an arbitrary number of
future extensions changes nothing in this regard.
I agree that we already have the potential for RCPT to report several kinds of
errors, though I do think adding new conditions is likely to contribute to less
precise error reporting. And prior to this proposal all of the errors reported
by the server have been for conditions which were better detected by the server
-
this proposal is new in that it asks the server to report an error for a
condition
which is better detected by the client.
Again, I think a means of distinguishing conneg material in the response
is a
good idea and I'm not opposed to eliminating REQUIRED. But really don't
believe
REQUIRED causes the problems you think it does.
The overall effect of REQUIRED is probably to increase the number of
implementation errors and the number of mis-reported delivery failures.
Well, I've worked out what code is necessary to do this, and IMO this just
doesn't rise to the level of complexity for this to be the case.
The code to implement REQUIRED on either the client or server end is trivial.
On the other hand, the effort required for a new implementor to understand SMTP
and how this extension interacts with all of the other ones is nontrivial.
On numerous occasions we've both seen that even somewhat mature implementations
frequently misunderstand far less subtle aspects of email protocols than
those being discussed here. This proposal introduces new opportunities
for misunderstanding. Some of them are due to the way that the protocol
extension works, others are due to the description (or lack thereof) of
how the extension is to be used.
I believe that every new bit of complexity that we add to SMTP requires
significant justification, whether that complexity is measured in lines of
code, in lines of text that implementors have to understand, or (especially!)
in undocumented assumptions on the part of the designer that implementors
have to figure out. And every bit of unnecessary complexity we can remove
from a proposed extension is worthwhile.
We might disagree on the relative merits of a particular feature, and
some of that is to be expected. But when we get into extended
arguments about a single aspect of the design we should not lose
sight of the overall picture: We need for email to work reliably.
In various ways this proposal adds unnecessary complexity, and lacks
the degree of background explanation that is necessary to allow
implementors to understand how to use it, especially for non-fax cases.
If it seems like I'm attacking the proposal harshly, it's only because
I'm painfully aware of how often SMTP is misimplemented, and because
I think that these discussions should have been had in the broader
SMTP implementor community long before IETF-wide Last Call.
Keith