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 (hastings@cp10.es.xerox.com)
Wed, 23 Jul 1997 23:36:36 PDT

Lloyd,

One more point to show that solving the char set identification issue
is much easier than localiation, is that the proposed SYNTHESIS solution
doesn't allow just any code set. Code positions 32-126 have to be US-ASCII.
So that data that only uses code positions 32-126 is invariant to what
is in prtGeneralStaticCodeSet.

Tom

At 13:02 07/23/97 PDT, lpyoung@lexmark.com 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.
>------------------------------------------------
>Tom,
>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.
>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.
> 4. Octet strings that are read-only strings that are strictly determined
> by the printer, octet strings such as prtCoverDescription.
> 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.
>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
>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.
>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.
>Regards,
>Lloyd Young
>
>------------------------------------------------------------
>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
>
>
>
>