I'm sorry if my earlier note was confusing -- I was addressing
the general I18N issue rather than attempting to anaylze the
situation specifically for Printer MIB.
As you said, Printer MIB is not a new protocol.
If you've got significant backward compatibility issues --
e.g. if existing SMTP management stations (clients) won't
satisfactorily interoperate with new printers whose MIBs use
UTF-8 or some other form of IS 10646 -- then you would appear
to have adequate reason for not mandating UTF-8 or 10646,
and instead allowing a variety of charsets and labelling them.
Keith
p.s. I do want to clear up a common misconception. Changes in
the Draft Standard MIB would not retroactively label a number of
implementations non-conformant. Those implementations should
be claiming conformance to RFC 1759 (if they conform), not
to the new MIB.
The purpose of multiple standards maturity levels is to provide an
opportunity to fix things that were broken at earlier stages.
If the only changes needed are clarifications, that's wonderful,
but it's quite common for a Draft Standard specification to require
changes which prevent some existing implementations from claiming
conformance to the Draft Standard version. This should not be a
barrier to making such changes to the specification if there's a
good reason to do so.
On the other hand, interoperability with the installed base
is very important!