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

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

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

Tom Hastings (
Wed, 23 Jul 1997 15:56:33 PDT

At 13:02 07/23/97 PDT, wrote:
>I should have used octet string instead of object in my previous
>e-mail. I am not going to distinguish between display string and octet
>string in this e-mail because I do not think it does not make any
>difference. By using object previously, I may have confused some people.
>Here is the same e-mail but with object changed to octet string.
>To further expound on my previous e-mail, unless I am missing something
>just defining one new object will not fix the localization problems
>in the Printer MIB. I will attempt to summarize my current position.

Please distinguish between "localilzation" which includes char set,
language, and country, from the simpler "code set" problem. My solution
is ONLY trying to solve the code set problem, not the localization problem.

I agree localization is harder. But I'm not trying to solve it.
Please don't keep confusing the two. It gets us all confused.
I'm going after the more important part that covers current practice
and follows the IAB and our Area Director recommendations.

>There are 5 types of octet strings in the Printer MIB where
>localization may apply.

> 1. Octet strings covered by prtConsoleLocalization

> 2. Octet strings covered by prtGeneralCurrentLocalization

> 3. Octet strings that are written to and read back by an SNMP
> management application, objects such as prtGeneralCurrentOperator.
and are not accessed by the Printer?
These are POSTITs. The Printer doesn't do anything with them.

> 4. Octet strings that are read-only strings that are strictly determined
> by the printer, octet strings such as prtCoverDescription.
But prtCoverDescription is under control of prtGeneralCurrentLocalization,
so at least you example is category 2 above. What other objects
are in this category?

> 5. Octet strings that are Printer MIB read-only strings but are copied by
> the printer from variables set by a non-SNMP host, objects such as
> NDSP Server name from prtChannelInformation.
We've agreed that prtChannelInformation code char set is specified by
the enum, not by any object. Are there any other objects in this category?

>I think we have adequately covered type 1 and 2 octet strings from a
>localization perspective. I think we decided some time back that we were
>going to ignore the localization problems in type 3 octet strings. If I
>understand your proposal correctly, you are attempting to define the
>localization of octet strings that fall in type 4 and 5 categories by
no, just char set.

>using just one variable. I do not think this is possible to do because
>they can be localized by two different sources. Octet strings in category
>4 are determined by the printer and octet strings in category 5 are
>determined by a non-SNMP host.

But we need to have other examples of your category 4 and 5, since neither
of the examples are correct.

If there are different soucces, my proposal is that they have to agree on
one and use the one that is in prtGeneralStaticCodeSet.

>I think the time has come (it may already be past due) for Chris and myself
>to edict what is the consensus of the working group. I am not sure that we
>are ever going to reach a true consensus on this issue from the working
>group. I'll give the group some time (maybe only a few hours) to respond
>to Tom's latest proposal and this e-mail before talking to Chris and
>deciding what we need to do.
>Lloyd Young
>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