PMP Mail Archive: Re: PMP> another look at alternatives 1-2, [ISSUE 2: Add

PMP Mail Archive: Re: PMP> another look at alternatives 1-2, [ISSUE 2: Add

Re: PMP> another look at alternatives 1-2, [ISSUE 2: Add

Tom Hastings (hastings@cp10.es.xerox.com)
Mon, 28 Jul 1997 03:38:31 PDT

Please respond to this issue Monday, 7/28, so we can wrap up this MIB.

At 19:17 07/25/97 PDT, David_Kellerman@nls.com wrote:
snip...

>> ISSUE 2: Add an object to hold the written code set or not?
>>
>> The current localized strings are all read-only (except for the
>> prtConsoleDisplayBufferText object).
>> ALL of the new ones are read-write, so some implementations
>> may let a management app write them.
>>
>> In Nashua, Ang Caruso and Ira updated their proposal to having
>> a separate object that specified the coded character set for
>> objects that were writeable. Should we do that here too?
>> Or do we want to require that the management app write in
>> the same character set as the current localiztion specified
>> in the MIB so that we would NOT need another object for the
>> application to write the CodeSet enum into.
>
>I'm trying to keep from changing things! And I did notice that previous
>localized objects were (with the one exception) read-only. I don't see
>any reason to introduce a new localization category. Instead, adopt the
>same approach as is already used for prtConsoleDisplayBufferText -- the
>management application had better write a value consistent with the
>setting of prtGeneralCurrentLocalization.
>
>What do current implementations do with prtConsoleDisplayBufferText when
>the management application changes prtConsoleLocalization? Leave it to
>the application to correct any inconsistency, revert to a default value,
>or what?

Is there any support to add a read-write object the contains the code set enum
for the new writeable objects (that the management app would write into to
indicate the char set that it used), or should we require that a management
app write any of these writeable objects in the current locale
specified by prtGeneralCurrentLocalization (as is currently done for
the read-write prtConsoleBufferText object with respect to the
prtConsoleLocaliation object)?

If we can require that that management app write in the locale specified
by the prtGeneralCurrentLocalization, we don't need a new object, which would
be good.

The new localized read-write objects that might be writeable in an agent
implementation are:

> RW new loc. prtGeneralCurrentOperator PrtApplicationLocalizedStringTC
> RW new loc. prtGeneralServicePerson PrtApplicationLocalizedStringTC
> RW new loc. prtInputMediaName PrtApplicationLocalizedStringTC
> RW new loc. prtInputName PrtApplicationLocalizedStringTC
> RW new loc. prtOutputName PrtApplicationLocalizedStringTC
> RW new loc. prtGeneralPrinterName PrtApplicationLocalizedStringTC

Tom