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