Re: 10646, and all that

> >    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.   If one
uses the 10646-x-y model, one either has to parse the "-x-y" part in
some way, contradicting the model that "charset" values are just atomic
strings, or one needs to register a moderately large number of them in
order to handle the crossproduct of all rational language values of X
with all rational language values of Y.

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.   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.

Somehow, I find registrations that expand by geometric series to be
troublesome.

    --john