At 19:17 07/25/97 PDT, David_Kellerman@nls.com wrote:
snip...
>> I suggest that we use TCs to distinguish between localized and
>> non-localized objects.
>>
>> So how about TC's like:
>>
>> PrtEnglishASCIIStringTC - for objects that are US-ASCII always
>> (like OIDs). The application does
>> any localization if it wants to.
>
>How about just ASCIIString for the name?
We should follow the current conventions in the MIB in which
all of the new TCs start out with 'Prt' and end in 'TC'.
So it should be at least: PrtASCIIStringTC.
So the remaining issue is whether to include 'English' in the name or not.
I think that Ira's and Ang's editing that Chris and Lloyd had already
done had the name 'PrtEnglishAsciiStringTC' didn't it?
The three objects that do have standard text values specified:
> R/W prtInputMediaType "stationery", "transparency", ...
> R/W prtInputMediaColor "other", "unknown", "white", "pink"
> R prtMarkerColorantValue "other", "unknown", "white", "red", ...
are specified in English.
Comments?
>
>> PrtAgentLocalizedStringTC - the current localized objects
>> according to prtGeneralCurrentLocalization
>> and prtConsoleCurrentLocalization
>>
>> PrtApplicationLocalizedStringTC - the new potentially read-write
>> objects.
>>
>> ISSUE 3: Should we have a separate TC for console localization?
>
>If you're going to switch to TCs for the localized objects, I liked
>Ira's proposal more:
> o PrtCurrentLocaleDisplayString for objects controlled by
> prtGeneralCurrentLocalization,
> o PrtConsoleLocaleDisplayString for objects controlled by
> prtConsoleLocalization.
David suggests yes. I agree. Lets go with the above TCs for these two.
>I don't see why you need to distinguish between the read-only and the
>read-write strings with different TCs.
We don't, if the answer to issue 2 is that we don't add a writeable
object that specifies the code set that the management app used in
writing the new writeable localized strings (not counting the
prtConsoleDisplayBufferText object).
If we do add an object, then we should have a separate TC.
>
>Also, if you do incorporate the TCs into the MIB (which Lloyd and Chris
>have done once already), go ahead and remove the descriptive text that
>serves the same purpose -- one way or the other, not both.
So maybe some of that editing can be salvaged? Great!
So if we don't add an object to hold the code set used for written
objects, we would have the following TC usage:
I've extracted all objects of type OCTET STRING from the MIB draft 02.
I've put 'localized' in front of the ones whose DESCRIPTIONs say are
localized according to prtGeneralCurrentLocalization and 'console loc.' in
front of the ones whose DESCRIPTIONs say are localized by
prtConsoleLocalization.
I've added "new loc." for the objects that are being proposed as
newly localizable.
NOTE: All of the "new loc." are read-write.
I've put RW for read-write objects and R for read-only objects.
NOTE that an implementation is NOT required to make any of the
RW objects writeable.
Using Ira's and Ang's TCs which Lloyd and Chris edited into a version
of the MIB (but the 'new loc.' would be changes to that):
PrtEnglishASCIIStringTC for objects not subject to localization,
some of which the application is responsible
for localizing if displayed to its user
PrtCurrentLocaleDisplayStringTC for objects controlled by
prtGeneralCurrentLocalization,
PrtConsoleLocaleDisplayStringTC for objects controlled by
prtConsoleLocalization.
RW new loc. prtGeneralCurrentOperator PrtCurrentLocaleDisplayStringTC
RW new loc. prtGeneralServicePerson PrtCurrentLocaleDisplayStringTC
RW prtGeneralSerialNumber PrtEnglishASCIIStringTC
R localized prtCoverDescription PrtCurrentLocaleDisplayStringTC
The following two objects are proposed to be changed to DisplayString
since the ISO 639 and 3166standards specify what the values shall be using
Latin letters only:
R prtLocalizationLanguage PrtEnglishASCIIStringTC
R prtLocalizationCountry PrtEnglishASCIIStringTC
RW new loc. prtInputMediaName PrtCurrentLocaleDisplayStringTC
RW new loc. prtInputName PrtCurrentLocaleDisplayStringTC
R prtInputVendorName PrtEnglishASCIIStringTC
R prtInputModel PrtEnglishASCIIStringTC
R prtInputVersion PrtEnglishASCIIStringTC
R prtInputSerialNumber PrtEnglishASCIIStringTC
R localized prtInputDescription PrtCurrentLocaleDisplayStringTC
RW prtInputMediaType PrtEnglishASCIIStringTC
RW prtInputMediaColor PrtEnglishASCIIStringTC
RW new loc. prtOutputName PrtCurrentLocaleDisplayStringTC
R prtOutputVendorName PrtEnglishASCIIStringTC
R prtOutputModel PrtEnglishASCIIStringTC
R prtOutputVersion PrtEnglishASCIIStringTC
R prtOutputSerialNumber PrtEnglishASCIIStringTC
R localized prtOutputDescription PrtCurrentLocaleDisplayStringTC
R localized prtMarkerSuppliesDescription PrtCurrentLocaleDisplayStringTC
R prtMarkerColorantValue PrtEnglishASCIIStringTC
R localized prtMediaPathDescription PrtCurrentLocaleDisplayStringTC
R prtChannelProtocolVersion PrtEnglishASCIIStringTC
R prtInterpreterLangLevel PrtEnglishASCIIStringTC
R prtInterpreterLangVersion PrtEnglishASCIIStringTC
R localized prtInterpreterDescription PrtCurrentLocaleDisplayStringTC
R prtInterpreterVersion PrtEnglishASCIIStringTC
RW console loc. prtConsoleDisplayBufferText PrtConsoleLocaleDisplayStringTC
R console loc. prtConsoleDescription PrtConsoleLocaleDisplayStringTC
R localized prtAlertDescription PrtCurrentLocaleDisplayStringTC
This proposal would add to the above list:
RW new loc. prtGeneralPrinterName PrtCurrentLocaleDisplayStringTC
David Kellerman's revised prtChannelInformation also adds
but we should keep it as OCTET STRING, since its code
set varies depending on the enum value:
R prtChannelInformation OCTET STRING