It is not clear to me that we must choose "no solution" (or a
solution that either creates a very large number of registrations and/or
gets us into trouble when 10646.2 is published)
Assuming that 10646.2 will ever be pulished, can you explain what
trouble will occur then?
As others have already pointed out (and as RFC1341 itself points out), a
lot of separate character set registrations is not a good idea.
Isn't the following mail of this ML the reason of that?
Date: Wed, 1 Apr 92 08:25:34 +0200
From: Dan Oscarsson <Dan(_dot_)Oscarsson(_at_)malmo(_dot_)trab(_dot_)se>
Message-Id: <9204010625(_dot_)AA08152(_at_)malmo(_dot_)trab(_dot_)se>
Subject: Re: Working Group Last Call: Mnemonic to Proposed Standard
This is the reason that I would have liked MIME to only reference
ASCII and ISO 8859-1 as the basic requirements, with the intention to
use ISO 10646 when it becomes IS. Instead of allowing a lot of
character sets that are not compatible with ISO 10646 and only gives
me a lot of extra work to implement handling of them also.
ISO 10646 is all we need and we should not put a lot of work using
character sets that can be discarded when ISO 10646 becomes IS.
If so, it does not matter to have a lot of character sets all of which
are compatible with ISO 10646.
To fully implement ISO 10646, so that through which correct multi-lingual
communication could be performed, you must support several "graphic
symbol"s anyway.
So, why shouldn't we fully implement ISO 10646 with "charset" mechanism?
While I know that enough characters, character collections, and
character repertoire have been proposed to push things off the BMP and
hence into 10646.N, N > 1, I have no way to guess what is going to be in
it. But it is rational to suppose, in the absence of proof to the
contrary, that JTC1/SC2/WG2 will repeat the decisions of 10646.1 and
manage to make some assignments in 10646.2 that will map characters that
some people think are distinct onto the same code points. If they do
so, it will then be potentially necessary to have 10646-x-y-z, at least
doubling the number of registrations.
While I hate to worrying about ISO 10646.2 even before ISO 10646 is
published, your opinion is not so reasonable.
Then, one possible solution is to have something like 10646.2-x. That is:
charset=iso-10646.2-basic
charset=iso-10646.2-g
charset=iso-10646.2-t
charset=iso-10646.2-j
charset=iso-10646.2-k
charset=iso-10646.2-sanskrit
and so on. In this case, iso-10646.2-basic should be considered to be
the bottom set of all the variations of iso10646.[12].
Or, *IF* the unification is so likely to occur again, it would be
better to have things like
charset=iso-10646-basic
charset=iso-10646-g
charset=iso-10646-t
charset=iso-10646-j
charset=iso-10646-k
charset=iso-10646-sanskrit
from the beginning.
Anyway, detailed discussion on how to profile ISO 10646 is not a
problem of MIME and should be discussed in separate RFC.
Similarly, it is rational to
suppose that, even if 10646.2 does not contain any arrangements that
anyone would think of as overloaded code points, it will contain
variations on code assignments in the BMP that will require additional
profiling for intelligent use in electronic mail. Again, that would
take us toward a 10646-x-y-z structure or worse.
You perhaps mean that O-zone of 10646 BMP could be used as a swappable
zone. Then, it is not assured at all that:
Content-Language:
header can provide the necessary swapping information.
Thus, you need another header:
Content-10646-Swappingmode:
or, we should have things like 10646-x-y, where "x" is the name of language
and "y" is the mode of swapping.
Somehow, I find registrations that expand by geometric series to be
troublesome.
You don't have to continue to use geometric series.
Masataka Ohta