While you can certainly back out the textual conventions I
suggested (for clarity ONLY) from the new Printer MIB draft,
you CAN'T back out localization (selectable dynamically by
remote management stations) from the Printer MIB without
BREAKING every existing implementation.
The 'prtGeneral[Current|Console]Localization' objects have
been there all along. To my certain knowledge they are
correctly implemented in printers from half-a-dozen different
vendors. They are NOT 'read-only'. They are (by design)
'read-write' (of course, contention by several remote
management stations makes it very undesirable to treat
them as 'anybody changes whenever they want').
All my first two textual conventions of
'Prt[Current|Console]LocaleDisplayStringTC' accomplished
was to remove the dependency on COMMENTS in the DESCRIPTION
clause of string objects making them subordinate to
the two General group pointer objects.
I've read RFC 2130 closely. I believe that the work of
the original Printer MIB (RFC 1759) was entirely consistent
with the firm recommendation of RFC 2130 that EACH new
Internet protocol (and MIBs were NOT excepted) should
specify and label explicitly the CCS (coded character
set), CES (character encryption scheme), and TES
(transfer encoding scheme), and the language and
country (ie, cultural environment) of all textual
information sent 'over-the-wire'.
RFC 1759 was published over two years ago. A lot of
shipping product would be invalidated by actually
REMOVING localization from the Printer MIB v2.
The ONLY new ground I suggested we break was to stop
forcing every printer made to use US-ASCII for all
of the other (several dozen) string objects defined
(eg, tray names, serial numbers, models, etc) in
every marketplace.
If we return to the 'bad old days' of all the other
strings in US-ASCII (not even ISO 8859-1 like HTTP),
without any clue as to the language or country, I
am reasonably confident that FujiXerox will abandon
implementation of the Printer MIB in their new network
products - a proprietary solution coordinated with
US Xerox and Rank Xerox (in Europe) is much easier
to justify.
A great deal of misinformation has trickled out in notes
from PWG members in the last few weeks. No one has
ever addressed my issue of a single code base for
a common client for FujiXerox across the entire
Asia/Pacific marketplace.
It's WAY too late to completely remove the localization
in the original Printer MIB. And it was done RIGHT.
The language tags based on ISO 639 and the country
tags based on ISO 3166, EXACTLY like RFC 1766 (by
Harald) and RFC 2130 (by the IAB Character Set
Workshop) recommend.
Why not take the good example in the original Printer
MIB and roll it into a future update of the Host
Resources MIB (RFC 1514) which bravely bucked the
then ubiquitous trend of 'NVT ASCII' with (implicitly)
English content and defined the textual convention
'InternationalDisplayString' (without specifying
the locale discovery mechanism).
I'm disappointed in this decision, but not surprised,
given all the recent 'hot air' on the topic.
- Ira McDonald (outside consultant at US Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
906-494-2434
---------------------- Chris's note ------------------------
Return-Path: <pmp-owner@pwg.org>
Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1)
id AA08979; Thu, 3 Jul 97 17:37:26 EDT
Received: from alpha.xerox.com by zombi (4.1/SMI-4.1)
id AA02065; Thu, 3 Jul 97 17:34:28 EDT
Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <15822(3)>; Thu, 3 Jul 1997 14:34:26 PDT
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA14887 for <imcdonal@eso.mc.xerox.com>; Thu, 3 Jul 1997 17:30:06 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Thu, 3 Jul 1997 17:29:14 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA14766 for pmp-outgoing; Thu, 3 Jul 1997 17:28:31 -0400 (EDT)
Date: Thu, 3 Jul 1997 14:26:16 PDT
From: Chris Wellens <chrisw@iwl.com>
Reply-To: Chris Wellens <chrisw@iwl.com>
To: pmp@pwg.org
Subject: PMP> Localization
Message-Id: <Pine.SUN.3.93.970703135608.14212A-100000@iwl.iwl.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: pmp-owner@pwg.org
Status: R
Lloyd and I have reached a decision on incorporating the
Localization Proposal into the Printer MIB. While we feel that
there is sound justification that localization could be
improved in the Printer MIB, there are also sound reasons
as to why localization is bigger than just the Printer
MIB. With all factors weighted, we have decided that the
best course of action is to "back out" these changes.
In the process of researching this issue, we discovered that
both of our Area Directors, Keith and Harald, have considerable
technical experience in this issue (owing to their work on MIME
and various email protocols). We also received comments from
our IETF SNMP experts.
An excellent discussion of how to approach localization in IETF
protocols is contained in both RFC 2130 and RFC 2004. While
these documents discuss specific protocols and how localization
should be applied to them, there is no discussion for the SNMP
protocol.
In addition to the agent needing a mechanism to define the
local language in use, some of the IETF SNMP experts have raised
other issues. For example, the solution should really
incorporate a mechanism where the management station can choose
the preferred language and be given a reasonable answer.
Rather than use a special implementation in the Printer MIB,
they feel a generalized solution is best, so that all the
SNMP MIBs could use it in a consistent way. (In the same way
that all MIBs now use MIB-II.) They point out the difficulties
for the network manager who is managing multiple SNMP devices,
with multiple MIBs in a multi-national network, who would have
to deal with different implementations of localization.
There is new work going on with this using UTF-8. This has been
incorporated in a relatively new Internet-Draft, the Systems
Application MIB. This can be found at:
http://ds.internic.net/internet-drafts/draft-ietf-applmib-sysapplmib-08.txt.
We (the Printer MIB Working Group) should look forward to seeing
the results of these implementation experiences, and the ensuing
definition of how to best implement localization in SNMP MIBs.
So, on reflecting on these newly raised operational and
technical concerns, we will not incorporate localization.
However, all implementors should be warned that a localization
solution for SNMP MIBs is coming in the near future.
-----------------------------------------------------------------------------
--==--==--==- Chris Wellens
==--==--==--= Email: chrisw@iwl.com Web: http://www.iwl.com/
--==--==--==- InterWorking Labs, Inc. 244 Santa Cruz Ave, Aptos, CA 95003
==--==--==--= Tel: +1 408 685 3190 Fax: +1 408 662 9065
-----------------------------------------------------------------------------