I just wanted to stick my hand up on this one, mostly to express strong
agreement with Randall's note from yesterday morning. The character sets
that are already locked into firm Standards and often hardware and in
significant production use are, unlike most of the rest of RFC-XXXX, not
experimental at all-- they are proven, production-quality tools--and
should stay in RFC-XXXX.
There is also an issue of fairness here. A non-trivial number of us have
said, virtually from the inception of the 822 extensions effort, that our
interest was much less (or zero) in multimedia or structured mail but in
getting the international character set machinery established. We have,
collectively, put in a reasonable amount of time on RFC-XXXX, including
trying to get specific text and terminology just right, because of the
apparent general agreement that the character sets were part of the story.
Had that not been the case, we would have been off writing character set
documents, at least since before the St. Louis IETF and probably earlier.
Since the character set part of this work has the interesting property
that what is known is *very* known (as someone suggested recently, "full
International Standard in production use" is more solid than anything IETF
has ever done) and what is not known can safely be deferred, such a
document might imaginably be ahead of RFC-XXXX in the processing track by
now.
While we can quibble about details, perhaps forever, everyone with even
a marginal claim to character set, and character set standard, expertise
in this effort has said, in one form or another:
(i) Most of the ISO 8859-n International Standard character sets are in
use, well supported, well-understood, very stable, and should be
incorporated in RFC-XXXX.
(ii) What we have referred to as 2022-jp is in use, well supported,
well-understood, very stable, and should be incorporated in RFC-XXXX.
(iii) 10646 should not be incorporated except, possibly, as a
placeholder.
(iv) Other character sets should probably wait, or be handled in
parallel documents, at least unless things stabilize very quickly.
Outstanding quibbles:
8859-n: Randall wants, and has consistently wanted, support for all
values of "n" defined by ISO. My instinct would be to provide formal
support for "-1" and anything else for which a clear requirement exists.
I would then provide a framework for quickly registering the others, but
wait for actual demand before doing so. There are is really only one
reason for this difference, which I believe that, all things being equal,
we are probably better off with fewer character sets than more. While
there are reasons for each of the 8859 variations, some of them come very
close to "nationalism requires us to create and standardize our own
variant". If those variations give way in practice to 10646 (as some of
them may) before there are really pressures to use them on the extended
mail-Internet, then we would be better off not trying to clutter documents
or implementations with discussions of them.
Text which waltzes around this problem can be extracted from the
pre-Santa Fe IETF version of RFC-ZZZZ if wanted. Including label values
for all of them, as Randall suggests, is not a show-stopper for me and I
suspect, based on separate conversations, that what I propose would not be
a show-stopper for him (although neither of us is likely to change
preferences).
2022-jp: The only problem with it is finding an appropriately
authoritative and accessible document to reference. The JUNET "standard",
suits me fine. If we could get JUNET to sign off on the accuracy of an
English translation or summary (e.g., the appendix), that would suit me
even better. If they do the latter, I would prefer to see that appendix
published as a separate informational RFC with pro forma JUNET authorship.
But how this is handled procedurally is not a show-stopper for me, nor, I
think, for anyone else among the character-set-concerned community. If
figuring out the right procedure has the potential to hold up RFC-XXXX,
then there is a problem with IETF/IESG decision-making, not with 2022-jp.
10646:
My personal preference is to keep the placeholder as minimal as
possible, until we see what finally emerges from ISO and whether anyone
pays any attention to it. As I, and others, have pointed out, there may
be problems with some forms so severe as to cast us back onto more 2022
profiles. However, as long as speculation in RFC-XXXX about the form,
schedule, etc., of the final standard is kept to a minimum and clearly
labelled as such, a longer placeholder (such as Ran suggests) would not be
a show-stopper for me or, I believe, others in the "conservative" faction.
And I don't believe that mimimal mention would be a show-stopper for Ran
and others in the "optimistic" faction.
RFC-CHAR and "other" character sets:
RFC-CHAR stands out among the other character sets proposed for
inclusion. I like it and think it is a very impressive piece of work.
But I'd like to see the RFC and some practice move a bit further along,
and to see a procedure for incorporating new character sets that is not
dependent specifically on Keld outlined, before seeing it locked in the
RFC-XXXX. Everything else is speculative and should be deferred.
Is there any real reason why that does not present a sensible model for
RFC-XXXX?
--john