Something more like UTF-8? Largely backwards compatible with old formats (ascii) while still being extensible.
Switching to UTF-8 requires two major steps. The first was making software and interchange systems preserve the 8th bit (it used to be commonly used as a parity bit). For email, this was true only about the mid-to-late 90s--surprisingly recent. The second step, which is still incomplete today, is letting control mechanisms that used to speak only ASCII understand UTF-8 (or something else non-ASCII) reliably. You could only put UTF-8 in C++ or C code as of C++11/C11, for example. Non-ASCII domain names are still problematic, to say nothing of non-ASCII email addresses. In other words, trying to speak UTF-8 to someone who only speaks ASCII is still as problematic as trying to speak IPv6 to someone who only speaks IPv4. We just don't notice it as much because we keep advising people to only speak ASCII in key places.
Actually, email still is not nominally 8-bit transparent (ESMTP 8BITMIME is optional and not supported by all MTAs), but it doesn't need to be, that's what quoted-printable and base64 are for.
Which is why I wrote that email still nominally isn't 8-bit clean :-)
Yes, in practice, you won't find an MTA that doesn't leave your 8 bit data unharmed, but you do find MTAs that don't advertise 8BITMIME, and so nominally noone should send them 8 bit data ... except everyone does anyway, of course ...
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.
Which would work how exactly in the case of IP? So far sounds mostly like "make it backwards compatible by making it backwards compatible".
> how exactly in the case of IP?
For example, introduce two special IP options that would act as "page selector" for source and destination addresses respectively. i.e.
SRC: 1.1.1.1, DST: 2.2.2.2, no options ->
from 1.1.1.1 to 2.2.2.2
(backwards-compatible packet, classic IPv4)
SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 1.1.1, opt.Y: 2.2.2 ->
from 1.1.1.1.1.1.1 to 2.2.2.2.2.2.2
(our faux-IPv6)
SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 0.0.0, opt.Y: 2.2.2 ->
from 1.1.1.1 to 2.2.2.2.2.2.2
("old" address communicating with "new" address)
Say, for ease of processing on router, require that X and Y would appear only together, in that order, preceding other options (which is a bit of an exception as far as IP options go, but again, a backward-compatible one).
Now, I'm not proposing this seriously of course, but you asked for example - here you go, a plausible, backwards-compatible "IPv4.1", if you like.
[1] All major desktop OS support IPv6 for last 10 years and major mobile OS for last 7. Let's face it - software upgrade turned out (surprisingly) not to be the biggest obstacle.
In order for two hosts to communicate over IPv6, both ends need to have: software that supports IPv6, and the entire network path between them needs to be able to route IPv6 packets. Your proposal is functionally no different: you call the extended address field an "option", but in fact every host is required to understand it.
1. What would be a scenario where hosts using this mechanism could communicate where neither IPv4 nor IPv6 would work?
2. How do new internet participants get addresses under your scheme, if it only expands the number of addresses in existing allocations?