RE: Last Call: draft-klensin-rfc2821bis

> >> 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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf