PMP Mail Archive: Re[2]: PMP> Revised proposal on definition of OCTET STRING t

Re[2]: PMP> Revised proposal on definition of OCTET STRING t

Bill Wagner (bwagner@digprod.com)
Tue, 22 Jul 1997 13:29:28 -0400

Jay,

prtGeneralPrinterName, previous called something like printer
administrative name, is described as a name defined by the
administrator. I seem to recall that this object was added because of
the belief that the MIB-II sysName was unreliable and conflicted with
normal network administrator practice for assigning sysName, not just
because of the of multiple printers being serviced by one agent
problem.

It certainly is unclear from the description of the object that this
is not, indeed, intended as a "user-friendly moniker". It is not
identified as an administrator name intended to distinguish between
different HR printer devices; that is, a name associated with the
hrDeviceIndex which pervades the MIB.

Under these circumstances, I think Tom's observation has considerable
merit. There is no reason to restrict this name to USASCII.

What is the chance of IETF redefining the display string type? It
seems a poorly considered convention.

Bill Wagner, Osicom/DPI


______________________________ Reply Separator
_________________________________
Subject: Re: PMP> Revised proposal on definition of OCTET STRING to a
Author: JK Martin <jkm@underscore.com> at Internet
Date: 7/22/97 11:52 AM

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