PMP Mail Archive: Re: PMP>URGENT: SYNTHESIS proposal on definition of OCTET STRING

PMP Mail Archive: Re: PMP>URGENT: SYNTHESIS proposal on definition of OCTET STRING

Re: PMP>URGENT: SYNTHESIS proposal on definition of OCTET STRING

Ron Bergman (
Wed, 23 Jul 1997 08:26:53 -0700 (PDT)

Lloyd has provided an excellent description of the "real" problem
and our choices on this subject. We either accept the Printer MIB
as is or delay its completion and develop a proper fix for the problem.

I have seen at least three complex proposals presented in the last
several days. I have also observed several well constructed objections
to the proposals. This is a clear sign that the solution is not
ready for incorporation into the MIB.

If it is agreed that this is a problem that must be corrected in this
version, we must take the time to develop a proper solution. We must
not rush to create a solution that may be regretted later.

My preference at this time is to incorporate a solution to the
localization problem in the next version of the document.

Ron Bergman
Dataproducts Corp.

On Wed, 23 Jul 1997 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
> 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: Lexington, KY 40550
> Phone: (606) 232-5150 Fax: (606) 232-6740