> >> OTOH, I think standardizing this convention makes all > sorts of sense, > >> but not, of course, in 2821bis. > > > > Why not in 2821bis? Is 2821bis really that time critical? > > It is on its way to Draft Standard. This would be a > sufficiently new feature to force recycle at Proposed, which, > to put it mildly, would not be welcomed by the editor or, > more important, those who convinced me to do the work. Let me throw another idea into the mix. What if we were to recommend a transition architecture in which an MTA host ran two instances of the MTA software, one binding only to IPv4 addresses, and the other binding to only IPv6 addresses. Assume that there will be some means for the two MTA software instances to exchange messages when their DNS queries return the wrong kind of addresses (A or AAAA). The IPv4 MTA can continue to use the rules regarding MX records with A record fallback. The IPv6 MTA could require SRV records to identify destinations and have no AAAA fallback. It immediately seems obvious that some issues surrounding an architecture of email systems during the IPv4-IPv6 transition, are well out of scope of RFC28821bis. Therefore, I suggest that 2821bis move forward and that people interested in documenting email transition strategies discuss this with the Application area AD's. Such work should not be done without some form of outreach to operational groups such as MAAWG since email operators are quite likely to do whatever makes operational sense without regard to IETF documents. Unless, of course, email operators are highly involved in writing such documents. --Michael Dillon _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf