PMP Mail Archive: Re: Re[2]: PMP> URGENT: SYNTHESIS proposal on definition of

Re: Re[2]: PMP> URGENT: SYNTHESIS proposal on definition of

Tom Hastings (hastings@cp10.es.xerox.com)
Wed, 23 Jul 1997 23:36:41 PDT

At 13:01 07/23/97 PDT, Bill Wagner wrote:
>
>
>
>______________________________ Reply Separator
_________________________________
>Subject: Re: PMP> URGENT: SYNTHESIS proposal on definition of OCTET S
>Author: Tom Hastings <hastings@cp10.es.xerox.com> at Internet
>Date: 7/23/97 11:16 AM
>
>
>
>>
>> 1. I assume that there would be no checking of the operator entered
>> identification information. That is, the operator/administrator set in
>> whatever they want (or can), and get the same data bytes back. They
>> are not restricted to the identified character coding set.
>
>I would say that they would be restricted to the coded character set
>identified by the prtGeneralStaticCodeSet object. Otherwise, another
>application (that runs with a different default code set), might be
>confused when reading the text. Thus a good application that
>is writing Printer MIB objects should send such data in the identified
>code set specified by prtGeneralStaticCodeSet. If the user only enters
>ASCII characters (codes 32-126), then the application doesn't need to do
>anything special, since ALL values of prtGeneralStatisCodeSet specify.
>
>WW: This seems at odds with Lloyd's observation to the effect that
>we decided some time back that we were going to ignore the localization
problems
>in objects that are written to and read back by an SNMP management
application,
>objects such as prtGeneralCurrentOperator. And, as I observed, from a purely
>practical viewpoint, a certain printer company objected to imposing
>displaystring constraints on MIB-2 user entered ID objects

I certainly agree that keeping track of the language and country for
such POSIT objects isn't very useful. But isn't the character set useful?

But does not including these POSTIT objects under prtGeneralStaticCodeSet
make this solution more acceptable?
>
>
>>
>> 3. Is there an identified need for the printer to use a character set
>> other than UTF8 for the remaining, largely read only objects?
>
>I suggest yes, in order to handle existing practice of the 5si using
>HP Roman 8 and Lexmark using their 8-bit set. However, we want to steer
>future implementations towards UTF8 only as recommended by the IAB in
>RFC 2130. Thus the DEFVAL 106. Even RFC 2130 doesn't preclude other
>char sets.
>
>WW: I guess I was hoping that HP and Lexmark did not need their specific
>character sets for the non-user entered objects I had listed.

I think that the reaons Bob supported yesterday's proposal was that it
reflected the 5si practice.

>
>
>> 4. LocalizationLanguage (ISO639) and LocalizationCountry (ISO3166) are
>> two character codes (with a size constraint to 2 octets); would these
>> be recognizable/enterable in any likely character set to be specified?
>
>No. They are always in English as specified in ISO 3166 and ISO 639.
>Since any set that could be specified by prtGeneralCodeSet MUST preserve
>code positions 32-126 as US-ASCII, the values of language and country are
>unaffected by prtGeneralStaticCodeSet by definition.
>
>WW: OK, I guess I need some facts. You are saying that JIS X0208-1990 and GB
>2312-1980, for example, will revert to one byte per character US ASCII if the
>first byte is a US ASCII code?

Yes, according to ISO 2022 and actual practice in Japan and China, the
two byte Kanji set consists of bytes with the 8th bit set, i.e., both bytes
are in the code range 128 to 255. Bytes in the range 32 to 126 are US-ASCII
and are single byte characters. Thus they are dealing with one and two bytes
characters at the same time. But UTF-8 is a variable byte set as well,
with characters taking one, two, or three bytes.

I was chairman of the US X3 Codes and Character Sets committee for a number
of years, called X3L2. X3L2 was responsible for US-ASCII and the US positions
on ISO 2022, ISO 8859, and ISO 10646. So I'm real familiar with the code
set stuff.

Tom

>
>Thanks.
>
>>
>>
>> Bill Wagner, Osicom/DPI
>>
>
>
>
>