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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Well, it is certainly possible to arrange the additional conneg data so it is
> identifiable as such. As for not affecting the response, I'm not sure I see the
> problem: If the client wants an interop guarantee, it requires a conneg
> response, and handles 4yz and 5yz codes as temporary or permanent failures
> without regard to what's causing the error. 

I guess I don't see how this helps the client much, because you can get
interop failures even when there is a conneg string for each recipient.

So it seems that the proposal could be usefully simplified  by removing the
OPTIONAL vs REQUIRED flag from the CONNEG parameter, and having the server
report back the CONNEG status (yes, no, or tempfail) as part of the 
response rather than in the reply/status codes.

If the client wants an interop guarantee (how does the sender specify this?)
then it can reat the absence of the CONNEG string in the response, or the
absence of CONNEG in the EHLO response, as a failure.  This should really
be a client-generated error anyway since there's really no error on the server
side.

I think this would be a significant improvement - particularly if this extension
isn't generalized to support things other than fax and it then becomes necessary
to add another extension later for voice mail or whatever.

Keith


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]