PMP Mail Archive: Re: PMP> Revised proposal on definition of OCTET STRING to allow

PMP Mail Archive: Re: PMP> Revised proposal on definition of OCTET STRING to allow

Re: PMP> Revised proposal on definition of OCTET STRING to allow

JK Martin (jkm@underscore.com)
Tue, 22 Jul 1997 11:52:32 -0400 (EDT)

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