______________________________ 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
>
> 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
> 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?
Thanks.
>
>
> Bill Wagner, Osicom/DPI
>