> > > > 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
