[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ietf-charsets] Recent charset additions and issues



At 6:15 PM -0500 1/29/04, Bruce Lilly wrote:
>One issue is that the MIBenum values assigned to these charsets does not
>seem to be consistent with the description above and with the reference
>information at the indicated URIs.

IANA asked me where we wanted the registrations. After talking with a 
few folks, I told them:

=====
Registration of new charset KOI7-switched, March 30
	Vendor

Registration of ISO-8859-11, April 27
	Set By Standards Organizations

Register EBCDIC Character Set "OSD_EBCDIC_DF04_1", November 3
Register EBCDIC Character Set "OSD_EBCDIC_DF04_15", November 3
Register EBCDIC Character Set "OSD_EBCDIC_DF03_IRV", November 3
	Vendor

Registration of new charset [Amiga-1251], November 7
	Vendor
=====

They appear to have ignored my request on the EBCDIC registrations.

>Conversely, it is not clear why KOI7-switched has been
>assigned a Vendor MIBenum value, nor which vendor might be responsible.

"Vendor" doesn't really mean "a specific vendor", it pretty much 
means "not 'Reserved', 'Set By Standards Organizations', or 'Unicode 
/ 10646'".

>Another issue is that the three OSD_EBCDIC_DF* charsets give no indication
>in the source documents as to whether or not the charsets are suitable for
>use with MIME text.  Such an indication is supposed to be part of the
>registration (RFC 2978 section 5).

Whoops, good catch. I missed that.

>   A related issue is the fact that the
>registry itself provides no such indication for any charsets, which
>is at best highly inconvenient for implementors.

I will take this up with IANA and will try to get a future version of 
the database to contain it.

>None of the charsets above have been provided with an alias beginning with
>"cs" for use with the printer MIB as discussed in section 2.3 of RFC 2978.
>If that were consistently done, there would be no charset with a confusing
>Alias: None
>line in the registry.

Good catch; these should be added. I'll work on that.

>How can we minimize these issues in the future?  I believe that use 
>of RFC 2978
>(or a successor) as a checklist during the review process would 
>help.  I believe
>that the addition to the registration template of a brief history of the
>charset origin (originator and affiliation) would help in determining
>whether a particular charset is a Vendor charset or Set By [a] Standards
>Organization[s].  Finally, inclusion of a "MIME-text" field in the registry
>with a yes/no value would not only be a boon to implementors of applications
>which use charsets in a MIME context, but would prompt IANA to obtain a
>statement of MIME text compatibility if it is lacking in the registration
>application.

All of those sound like excellent suggestions.

--Paul Hoffman, Director
--Internet Mail Consortium