ALL of the Name objects in the IETF Host Resources MIB (RFC 1514)
are of type 'InternationalDisplayString'. It is standard practice
to use the character set appropriate to the current device locale
(ie, physical location in some country) in UNIX host implementations
of RFC 1514 for these names - it is NOT standard practice to
reduce these names to the ASCII character set (administrative names
of system devices and services have to be in the language and
code set of the end user to be useful).
If you want to make an argument, get your facts right
Cheers,
- Ira McDonald
---------------------------- Jay'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 AA14623; Tue, 22 Jul 97 12:06:06 EDT
Received: from alpha.xerox.com by zombi (4.1/SMI-4.1)
id AA26528; Tue, 22 Jul 97 12:02:47 EDT
Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with SMTP id <51880(2)>; Tue, 22 Jul 1997 09:02:53 PDT
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26512 for <imcdonal@eso.mc.xerox.com>; Tue, 22 Jul 1997 11:59:03 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Tue, 22 Jul 1997 11:57:25 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26368 for pmp-outgoing; Tue, 22 Jul 1997 11:55:49 -0400 (EDT)
Date: Tue, 22 Jul 1997 08:52:32 PDT
From: JK Martin <jkm@underscore.com>
Message-Id: <199707221552.LAA29356@uscore.underscore.com>
To: hastings@cp10.es.xerox.com
Subject: Re: PMP> Revised proposal on definition of OCTET STRING to allow
superset of ASCII
Cc: pmp@pwg.org
X-Sun-Charset: US-ASCII
Sender: pmp-owner@pwg.org
Status: R
Tom,
> 2. One of the new Printer MIB v2 objects, 'prtGeneralPrinterName' has
> been given a SYNTAX of 'DisplayString', instead of OCTET STRING
> which forces NVT ASCII only (code positions 128 to 255 SHALL not be used)
> instead of 'OCTET STRING' which would give the same capabilities for other
> sets with US-ASCII as a subset as in 1 above.
Let me briefly explain the rationale for the prtGeneralPrinterName
just one more time...
I proposed the addition of this new object in response to the need
to corroborate an instance of the Printer MIB with a printer known
by an administrative name within a printing system.
For a "normal" network printer, this value is not particularly useful,
since there is only one instance of the Printer MIB managed by the
embedded agent.
However, there are several cases where an agent supports multiple
instances of the Printer MIB. Examples include:
- Direct-attached (serial/parallel) printers to a host/server
- Printers attached to a multi-port LAN interface box ("brick")
- Printers attached to a special-purpose multiplexor (eg, EFI)
We need to have a way to distinguish between the various instances
of the Printer MIB managed by a single SNMP agent. In reviewing the
environmental situation, it was found that the binding requirements
centered around the "name" assigned to the printer within the target
printing system environment.
To our knowledge, 99% of such names are constrained to plain ASCII
strings. Hence, the constraint for DisplayString as the object syntax.
The prtGeneralPrinterName is *NOT* meant to be some sort of user-
friendly moniker to be readily displayed by some mgmt application.
Instead, it was designed as a programmatical binding mechanism to
tie the Printer MIB instance into a larger management domain comprising
multiple printers.
Does this object need to be localized/internationalized? I really
don't think so.
Can this object be localized/internationalized? Sure, I guess.
But does it really NEED to be?
A constraints can be a Good Thing. Unbounded (and unjustified)
flexibility can be a Bad Thing.
I wish people would take these views into account more often.
...jay