Thanks for the response. Unfortunately, the localization
clarifications (NOT changes) via explict textual conventions
(rather than mere ASN.1 comments) did NOT get review in mid-April
when I proposed them. You are the first person to comment on
them in a LONG while.
If we 'go back to the previous version' the rules about the
use of 'prtGeneralCurrentLocalization' (for 'xxxDescription'
objects) and 'prtGeneralConsoleLocalization' won't change.
The textual conventions I proposed merely made it SAFER to
deduce what the applicable 'locale' is for a given string
object (except for the IMPORTANT ability for a non-English
and non-ASCII product to use an appropriate language and
code set for the other string objects, which were formerly
FORCED to be ASCII only - useless to the majority of the
people alive in this world today).
The reasoning behind the b) and c) clauses is NOT that
a remote client needs to present to their human user the
string in the managed device's locale, but merely that
when translating it (for language and/or code set), it
interpret the data in the strings as being CURRENTLY
in the referenced managed device's locale.
It is specifically in order to let the three principal
languages of North America (English, French, and Spanish)
be used by different remote clients WITHOUT modifying
a managed device's locale that I suggested these
clarifications.
Lloyd and Chris asked for meaningful comments a month
ago - the silence was deafening.
I'm also trying to get out product - to whit, a common
client for the entire Asia/Pacific marketplace for
FujiXerox network printers and multi-function devices
being developed by the team I work with at a US Xerox
site - and 7-bit ASCII is NOT a helpful code set for
network administrators and end users in MOST of their
markets.
The localization is NOT holding up the new Printer MIB.
There are several dozen other (mostly much more substantive)
updates (which have been enumerated in Lloyd's note over
the last three months) which have often also not been
reviewed or discussed on the mailing list - and by IETF
rules for sanctioned working groups, face-to-face meetings
have NO STANDING - if it wasn't discussed and explicated
on the mailing list, it DID NOT HAPPEN!
Thanks for commenting,
- Ira McDonald (outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
906-494-2434
----------------------- Chuck's note -----------------------
Return-Path: <adamsc@pogo.WV.TEK.COM>
Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com (4.1/XeroxClient-1.1)
id AA08440; Wed, 2 Jul 97 13:46:34 EDT
Received: from alpha.xerox.com by zombi (4.1/SMI-4.1)
id AA24395; Wed, 2 Jul 97 13:43:35 EDT
Received: from fw1.tek.com ([192.65.17.16]) by alpha.xerox.com with SMTP id <14925(2)>; Wed, 2 Jul 1997 10:43:34 PDT
Received: from fw1.tek.com (root@localhost) by fw1.tek.com (8.7.5/8.7.3) with ESMTP id KAA05789 for <imcdonal@eso.mc.xerox.COM>; Wed, 2 Jul 1997 10:41:10 -0700 (PDT)
Received: from orca.wv.tek.com (orca8.wv.tek.com [134.62.8.23]) by fw1.tek.com (8.7.5/8.7.3) with SMTP id KAA05690 for <imcdonal@eso.mc.xerox.COM>; Wed, 2 Jul 1997 10:40:50 -0700 (PDT)
Received: from pogo.wv.tek.com by orca.wv.tek.com (4.1/8.2)
id AA10736; Wed, 2 Jul 97 10:49:07 PDT
Received: from flesh (flesh.wv.tek.com) by pogo.wv.tek.com (4.1/8.0)
id AA26672; Wed, 2 Jul 97 10:40:46 PDT
Sender: adamsc@pogo.WV.TEK.COM
Message-Id: <33BA929E.749B@pogo.wv.tek.com>
Date: Wed, 2 Jul 1997 10:40:46 PDT
From: Chuck Adams <adamsc@pogo.WV.TEK.COM>
Organization: Tektronix, Inc.
X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5.1 sun4m)
Mime-Version: 1.0
To: Ira Mcdonald x10962 <imcdonal@eso.mc.xerox.com>
Cc: pmp@pwg.org, bpenteco@boi.hp.COM, chrisw@iwl.COM, lpyoung@lexmark.COM
Subject: Re: PMP> Localization changes to the Printer MIB
References: <9706291649.AA06717@snorkel.eso.mc.xerox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: R
Ira,
> The rest of you lurkers, PLEASE send meaningful technical
> criticisms (and NOT unsupported 'opinions') on the updates
> to clarify localization (or any of the other dozen recent
> updates). After some version of new Printer MIB text
> is submitted to the IETF/IESG in early July, it will get
> a LOT harder for PWG members to influence changes (ie,
> strictly technical comments will be entertained by the IETF).
Sorry but some of us lurkers are also trying
to get products to market.
But here is comment about the proposal on localization.
The proposal as presented in the pmib_062597.txt
has at least one serious flaw.
prtCoverDescription is specified as:
SYNTAX PrtCurrentLocaleDisplayStringTC
MAX-ACCESS read-only
PrtCurrentLocaleDisplayStringTC says:
a) whose dynamic locale ... prtGeneralCurrentLocalization
b) whose value (when updated by an SNMP Set-Request)...
c) whose value (when returned by an SNMP Get-
Response) shall be interpreted in this locale by the
management station.
I assume under a) the user/administrator
can change the value of prtGeneralCurrentLocalization.
But the printer is going to have the
prtCoverDescription specified in the language
established by the printer vendor. Thus the
description language may not match the
current localization. Thus the management station
can not depend on a being true.
I assume b) does not apply to this description
because the description can not be set.
I assume c) does not apply because the management
station may be running a different language than
the description was encoded in by the vendor.
Have I missed something here?
How many more problems exist with changes as proposed
in pmib_062597.txt?
From my view point the entire localization proposal needs
be be throughly reviewed or dropped. Thus we have
two choices, either postpone the draft submission
and make all the needed changes or take out
PrtCurrentLocaleDisplayStringTC ... and thus revert
back to the localization as specified in:
draft-ietf-printmib-mib-info-02.txt
I vote for the later.
Chuck Adams