ietf
[Top] [All Lists]

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

2002-07-03 16:06:22
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?  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.

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.

right now we have the situation where the server is essentially being asked
to report an error (and an error code) which is really happening on the 
client.
the server doesn't know the reason that the client doesn't want to deliver
the message to the recipient, and it shouldn't be expected to report the
error (or the enhanced status code) in the absence of such knowledge.

I guess this is a valid assessment, but somehow it doesn't offend me
the way it offends you.

My offense is for the document taken as a whole, especially the lack of
attention to non-fax applications.

that, and once we've established that it's okay to use RCPT to request
information about the recipient's UA capabliities and preferences,
it's hard to imagine that there won't be a demand to use RCPT to request
other information about the recipient's UA or preferences, such as
whether the recipient will honor MDN requests, what languages the
recipient can read, whether the recipient wants to opt-out of spam,
whether the recipient supports vendor-proprietary extension FOO, etc.
(I didn't say that I liked all of these ideas, just that these are
obvious uses of a facility that lets you query UA capabilities.
OTOH I do like some of them.)

Language preferences are, I believe, already defined as something you can get
out of feature algebra.

perhaps, these were just off the top of my head.  and I don't think the 
feature algebra yet contains everything that a recipient might like to specify. 
 

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.  

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.

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



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