ietf
[Top] [All Lists]

Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard

2002-07-03 20:52:23
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.

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.

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". 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". So this entire line of argument turns out to be
specious.

and if we go down that path we might really regret having allowed CONNEG
to alter the RCPT reply code.

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.

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.

It's by no means the worst thing I've ever seen in a protocol, nor is
it the worst thing in this proposal.  Getting rid of REQUIRED just
makes the protocol slightly cleaner.  It doesn't get rid of the RSET
ugliness, it doesn't address the applicability of this extension to
non-fax scenarios, nor the lack of attention to other issues.
These other things need to be considered also.

But given the importance of SMTP and the fragility of the mail system
I think that the fewer warts we add to SMTP the better off we'll be.

Keith, I was willing to give you the benefit of the doubt before. But
now that your concerns about this have become clear I'm finding I flat
out disagree with your assessment of the risks and concerns involved.

                                Ned



<Prev in Thread] Current Thread [Next in Thread>