I have no problem with Marshall's proposed resolutions for the new year,
with one exception. This is in the area of character sets. Dropping
10646 and the 2022-jp stuff is fine by me -- the first is a placeholder
for now anyway and the second is easily defined in a separate document.
However, I do have a problem with dropping the 8859 character sets. I also
don't see what the problem with them is. These characters are completely
and unambiguously standardized. They are well-defined (something which
you cannot assume simply because something is a standard, I regret to say).
They are not going to change. There are no interoperability problems with
using them (at least none that I know of). So what is the problem with
them?
Dave has indicated one possible problem -- that of how to convert these
character sets to other characters as needed. I have a very simple answer
to this problem -- you cannot convert them! Given the fact that MIME is
not going to define any other character sets that contain the 8859-n
sets with any significant degree of overlap (10646 being only a placeholder)
there are no target character sets it would be reasonable to convert the
8859-n sets to. True, you can perform various conversions that amount to
hacks, such as converting those characters that correspond to accented
variants of regular ASCII characters to the character without the accent,
or converting to the character followed by the accent, or (best choice)
converting to the mnemonic representation of the character. But these
are all hacks (the last one isn't once mnemonic is defined and standardized,
but that isn't done yet) and should be recognized as such.
The ability to convert things is certainly not a requirement for the
definition of other body part types, and I guess I don't see why this
should be a requirement for text/plain with a particular choice of
character set parameter. Conversion in any case is a UA function, in my
opinion, and as such does lie outside the scope of MIME.
We can of course punt on this and force the definition of the 8859-n
parameter values into another RFC. It will be less than a page long, since
it won't do much more than cite the relevant international standards.
This is very different than what's being done with mnemonic or 2022-jp,
both of which require significant technical detail within the associated
RFCs. This is no fault of either proposal -- it is simply the way things
are.
We are certainly making a decision of sorts if we choose the 8859 character
sets (as opposed to, say, the national character set variations of ISO646,
or 2022, or Unicode, all of which exist as standards at the present time).
However, I disagree with Dave in thinking that this working group does not
have the technical wherewithall to make this selection. I think it does and
I think the decision that's been reached is a reasonable one for now. This
will all have to be revisited once 10646 becomes a reality, but that's a
given we all accept, I think. It is also true that 10646 may be just around
the corner, but it may prove to be unworkable even if it shows up in the
short term. Or it may not show up in the short term -- who knows?
This is not a show stopper for me by any means. There are already about
five follow-on RFCs I plan to get into the process once MIME is stable.
Adding another won't cause that much pain, but on the other hand it
would simply things if we do a little more work in the base document.
Ned