I think that my SYNTHESIS proposal (sent last night)
fixes the real problem that you discuss here. Rather than putting my
proposal asside, I suggest that we implement the SYNTHESIS proposal for
objects of syntax OCTET STRING so that it is clear what the code set is
that is in use. Then we won't be going against our Area Director admonition
and will be following his bottom line:
But DO define the charset!
>From Harald.T.Alvestrand@uninett.no Wed Jul 2 05:21:32 1997
>Date: Mon, 30 Jun 1997 23:04:32 +0200
>From: Harald.T.Alvestrand@uninett.no
>To: Chris Wellens <chrisw@iwl.com>
>Cc: Keith Moore <moore@cs.utk.edu>, Lloyd Young <lpyoung@lexmark.com>
>Subject: Re: Need advice on last issue
>
>It's a deep hole indeed, and you might have no choice but
>to throw yourselves headfirst into it :-)
>
>Today: Strings are US-ASCII only, mostly English.
>More desirable: Strings are UTF-8, mostly readable locally.
>Most desirable: Strings are UTF-8, inquirer can choose which
> language he prefers, and be given a reasonable answer.
>
>(If you revise the MIB in such a way as to allow any character
>set without defining how to find out which, you lose - DON'T)
>
>MLSF or something like it is necessary if you want to avoid
>rabid revisions of SNMP like carrying language preferences
>in the community string; I'm sure there are SNMPv3 people
>willing to draw a knife on you if you suggest that :-)
>
>Upshot: I think you can do OK with the middle road this round,
>but probably nothing more. But DO define the charset!
>
> Harald A
>
Tom
P.S.
My mailer did not contain a subject in your mail message, so I made up one.
At 07:52 07/23/97 PDT, lpyoung@lexmark.com wrote:
>
>I want to put Tom Hasting's latest proposal aside for a
>moment and describe a problem that I realized yesterday was
>in the current definition of the Printer MIB. In HP's
>implementation of the Printer MIB according to Bob, they
>use 8 bit symbol sets in some of their read only objects
>depending on localization. In Lexmark's implementation
>of the Printer MIB, we use the PC 850 symbol set (which is
>an 8 bit symbol set) for all read only objects. HP may use
>PC 850 for their read only objects as well, I do not know
>but I think that is exactly the problem, there is no way to
>know which symbol set is being used for the read only objects
>not already covered by a localization object. This has never
>been seen as a customer problem up to now because I can imagine
>that all printers so far have used only US ASCII (lower code
>points) for most if not all read only objects. Most symbol sets
>do not vary in the lower code points but vary considerably in
>the upper code points. This means that everything works correctly
>until some printer implementation decides to use a code point
>in the upper portion of a symbol set for a read only object
>then all bets are off.
>
>Once I got over the shock when I saw Tom's latest proposal
>(Initially I said OH NO NOT ANOTHER LOCALIZATION PROPOSAL!!!!),
>I realized that it might be useful in solving the problem
>I described above. As a working group, we can say that there
>are known problems in the localization area and move forward
>without fixing these problems (which to me is an acceptable
>way to go. There are always going to be known problems. I
>would like to meet the person who says they shipped a perfect
>product with no known problems.) or we can stop and try
>the fix the problems that we see.
>
>------------------------------------------------------------
>Lloyd Young Lexmark International, Inc.
>Senior Program Manager Dept. C14L/Bldg. 035-3
>Strategic Alliances 740 New Circle Road NW
>internet: lpyoung@lexmark.com Lexington, KY 40550
>Phone: (606) 232-5150 Fax: (606) 232-6740
>
>
>
>