> > 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. It helps the client because it can now distinguish between temporary and permanent conneg failures. > 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. That would also work, but I don't think it is a useful simplification because it creates even more instances where the command succeeded but the client needed for it to fail. The server side of this is trivial either way. > 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. I don't think you have sufficiently demontrated the problematic nature of REQUIRED to claim this is a significant improvement. However, absent a convincing argument that such interop guarantees would actually be used, I personally don't have a problem with making this simplification. Ned