"Robert A. Rosenberg" <[EMAIL PROTECTED]> writes: > Russ Allbery wrote about Re: current usage of AAAA implicit MX?:
>> It's not that it's technically difficult so much as that it's dubious >> from a layering perspective, at least from where I sit. It requires I >> introduce IPv6-specific code (and hence ifdefs for systems without IPv6 >> constants and so forth) into an application that otherwise would not >> need any and would be entirely stack-agnostic. > OOPS. I was not considering the case where the code was being tailored > at assembly time. Looking at my flow I see only 1 (2 if you want to > ALWAYS set the flag in step 2) place where conditional code needs to be > inserted. This is in step 3 where the Test Flag and IPN code would only > get inserted IF IPv6 support is being generated. I think you're missing the point. In order to implement your proposal, I have to insert IPv6 knowledge into code that otherwise does not need any to work on both IPv4 and IPv6 systems. If I don't have to care about IPv6 when it comes to processing the presence or absence of MX records, SMTP clients honoring MX records can be written to be agnostic about the networking stack that they're using. Indeed, they can be written and tested by people with only IPv4 access and work on IPv6 without modification, since all the portabliity work is done by the system library. This is exactly the sort of abstraction and generalization accomplished via a good layering design, and layering violations are bad precisely because they don't allow this sort of clean separation of duties. A lot of work went into designing IPv6-friendly APIs so that clients using the modern networking API and some additional bits of glue such as sockaddr_storage can use the same code with both IPv4 and IPv6 without ugly #ifdef hacks or following different code paths based on the protocol. Let's not undo that. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
