Except UFT8 is not backwards compatible with ASCII!
An application written to only understand ASCII will not print non-ASCII UTF-8 characters. That is what you are asking here. It can't be done with ASCII/UTF8. It can't be done with IPv4/IPv6.
An application written to only understand ASCII will not print non-ASCII UTF-8 characters. That is what you are asking here. It can't be done with ASCII/UTF8. It can't be done with IPv4/IPv6.
IPv6, on the other hand, is not at all backward compatible with IPv4 (was never a design goal - magic of OSI stack was supposed to do it's thing). One would argue that incompatibility is in large part responsible for the 6's slow start - even though afterthought bolt-ons eventually did see sunlight - ::ffff:x.x.x.x thing, cornucopia of tunnels and dual-stacks of various degree lite-ness, etc.
Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something?
Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something?
See the difference?
As long as they only speak ASCII, yes.
> Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something?
That's why you deploy IPv6 dual-stacked with IPv4. That way, if two parties only speak IPv4, it's completely backwards compatible.
> See the difference?
Sure do I see the difference. What I don't see is how to apply any of that to the v4 to v6 transition in a way that would have any advantage over how it is being done now.