You're right; there's only one new object being proposed. I appreciate =
the efforts to clean things up, but my concern at this point is inducing =
turmoil this close to the end. I feel like this is similar to the =
completion of a software project and the last thing one does at the end =
of a project is throw in a bunch of changes, even when they seem to be =
innocuous.=20
After thinking about this change some more, it looks like the nature of =
this change is quite different from any of the others that we've made =
before. Aside from the numerous clarifications that we've done, I found =
the following list from one of Lloyd's messages:
1. Several Textual Conventions were added in the new
Printer MIB that were not present in RFC1759:
z Tom Hastings write up why new TC's were added
General Printer Group changes:
1. Six new objects were added to the General Printer Group:
prtGeneralStartupPage PresentOnOff - Tom Hastings
prtGeneralBannerPage PresentOnOff - Tom Hastings
prtGeneralAdminName Octet string - Jay Martin
prtGeneralSerialNumber Octet string - Harry Lewis
prtAlertCriticalEvents Counter32 - Bob Pentecost
prtAlertAllEvents Counter32 - Bob Pentecost
Input Group Changes
1. A group was added: The Input Switching Group
prtInputMediaLoadTimeout Integer32 - Angelo Caruso
prtInputNextIndex Integer32 - Angelo Caruso
Print Job Delivery Channel Group changes
1. One new object was added:
prtChannelInformation DisplayString - David Kellerman
These are all new objects that don't change the functionality of the =
existing objects. The change being proposed pulls out some of the =
current functionality of prtGeneralCurrentLocalization and puts it in =
prtGeneralStaticLocalization. The problem that I see this causing is =
what happens when a customer connects their new printer and tries to =
manage it with their existing management software (we know that =
customers tend to update their software much less frequently than they =
add printers). If they try to set the new printer's localization, they =
will find that it is only partially localized.=20
This change breaks existing software; therefore, it needs more thought =
before it goes into the Printer MIB.
Bob Pentecost
HP
----------
From: Ira Mcdonald x10962[SMTP:imcdonal@eso.mc.xerox.com]
Sent: Wednesday, June 11, 1997 8:18 AM
To: pmp@pwg.org
Subject: RE: PMP> Localization changes to Printer MIB
Hi folks,
Seeing the responses and then reading what I sent out two
months ago, I realize that in the interests of terseness
I was very unclear about the impact of my proposal. So
a few corrections.
While the SYNTAX clause of the OBJECT-TYPE macro for
most strings would change to use one of the three
new string-type textual conventions, the actual syntax
of the objects would remain the same (they are now
OCTET STRING and they would remain OCTET STRING with
the same SIZE clauses).
Only ONE new object was proposed:
prtGeneralStaticLocalization=20
And the DESCRIPTION of this object should probably
state that it is "updated (infrequently) by system
administrators when they install, upgrade, or move
to another network location the managed device."
(This is in response to David Perkins criticisms
that Chris posted.)
At the 22 April PMP telecon, Randy mentioned that some
strings are not suitable for re-localization. He is of
course right - the mnemonics line 'US', 'EN', from ISO
or IANA stds, the 'prtInputMediaName' (which needs to
be a well-known set of strings, to be useful), the
new 'prtChannelInformation' object (although NOT
localizing it still gives a problem for a server name
in a non-English environment or worse a non-8-bit
environment).
So, how about FOUR textual conventions:
PrtCurrentLocaleString
PrtConsoleLocaleString
PrtStaticLocaleString
PrtEnglishASCIILocaleString
Cheers,
- Ira McDonald (outside consultant at Xerox
High North Inc
PO Box 221
Grand Marais, MI 49839
906-494-2434