Re: Proposal for additional Aliases to IANA registry of character sets

[ned.freed@mrochek.com]

> Chris:

> As far as I know, the IANA registered names are also used for INTRANET
> using IETF protocols.

That's perhaps true but beside the point. We're dealing with a parameter
namespace for _Internet_ protocols here.

> The IBM corporate registration (started long before the IETF age) has been
> including in its numbering scheme coded character sets from many different
> sources -- including several of the ISO 7-bit, 8-bit standards, the many
> ISO-2022 scheme based national standards, several non-IBM-vendor defined
> etc.etc.   These numbers become aliases in the form IBM-nnnnn etc.

> If we state that the "the primary names assigned in the IANA registry is
> the name that is 'Strongly Encouraged to be used" for OPEN interchange
> (when the charset is not constrained in any manner)" then use of strings of
> ISO-8859-1 etc. can be promoted widely.  In these cases, the ALIASEs are
> meant to be used for "limited use contexts".   With the printer MIB
> numbers, even in the IETF open context there will be multiple 'names'.

The problem is that the present registry doesn't support making such
distinctions. The current intent is that the primary name should be used but
all aliases should be recognized by all implementations.

As such, adding new aliases to an existing and widely used charset  means
updating a very large installed base. Products that support on-the-fly updating
of charset tables are the exception, not the rule.

This makes such changes potentially VERY disruptive.

Nor would making the distinction you propose go far enough IMO. To be truly
effective there would need to be a way of listing a set of aliases for a given
charset that cannot conflict with other names and aliases yet MUST NOT be used
on the Internet.

> Unfortunately any ALIAS has a tendency to leak and they have to be
> equivalenced by implementations expecting to respect the aliases.  Short of
> BANNING aliases this cannot be avoided.

By acting to add such aliases to the general list we are basically saying
that implementations done in good faith in accordance with the standards
are a fault, whereas implementations that violated the standards are not.

I strongly object. This is no way to run a railroad.

Now, I wouldn't be happy but 'd perhaps reach a different conclusion given
evidence of widespread use of an unregistered alias for a charset on the
Internet. But you yourself have stated that the issue here is use in limited
contexts.

> Also as Markus has stated singling out the 8859-1 related IBMxxxx is not
> justified, neither deleting the existing aliases for many of the ISO
> standards, without impacting many existing implementations.

You have it exactly backwards. Adding additional aliases to commonly used
charsets is an act that singles out compliant implementations. Refusing
to add them singles out incompliant implementations only. And absent
any indication such implementations are commonplace, I have absolutely
no problem with that.

				Ned