The draft Printer MIB defines textual conventions for all enums, whether
they are used by one or more objects in the Printer MIB.
This change does *not* change the representation of what goes over the
wire in any way. So agents that implement RFC 1759 will interwork with
management applications that use the draft Printer MIB and agents that
implement the draft Printer MIB will interoperate with management
applications that use RFC 1759 with respect to this "change". Thus
the change to use textual conventions for all enums is not really a
change in substance, only a change in form.
There are a number of reasons for using textual conventions for all enums:
1. Other standards track MIBs, such as the Job Monitoring MIB or a future
MIB to augment the Printer MIB, may need to IMPORT some of the enums that
are in the Printer MIB. Exactly which ones aren't known sufficiently well
to only convert a few enums to textual conventions.
2. Private MIBs that augment the Printer MIB may need to IMPORT some
of the enums as well.
3. Those enums in RFC 1759 which are classified as type 2 or type 3 enums
are designed to allow additional values to be reviewed and registered
by the PWG and IANA. A number of additional values (alerts, interpreter
language families, and job source channel types), have been approved for
use with RFC 1759 by the PWG and registered with IANA for
use with conforming implementations of RFC 1759. Making all type 2
and type 3 enums textual conventions makes it easier for IANA to publish
all the current registered values, including the ones in the draft Printer
MIB.
4. Also it is easier for an implementor to IMPORT the latest enum
definitions from IANA into his/her implementation.