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