In my mind, clearly the issue on this subject is the current status
of the Printer MIB. This project has been in existence since 1993
(perhaps not formally but in reality.) We have taken the advise
of our first advisor and our current advisor and used the most
common methods employed in all the MIBs I have seen and
that is an enumerated list. At this point in time we have a number
of products that ship today with RFC1759 support including
both printers and printer management application. Obviously,
both support this enumerated list of interpreters. As far as the
question of whether or not applications use this interpreter list
to make the determination of which datastream to send, I believe
it is too early to answer. Remember, the MIB is currently is in
the proposed state. In many case in the management area,
implementations of proposed RFC's are never shipped as
products, they are simply prototyped. This is a different
philosophy from what has been done in the applications
area.
In the process of progressing the Printer MIB from proposed to
draft we have very carefully and meticulously identified the
things we have learned in the implementation of the above
mentioned products and in the interoperability testing that
was performed. At no time and in no way is there implementation
experience or testing that justifies a major change in the printer
MIB to move from an enumerated list of printer interpreters to
MIME. In many cases, the interpreters are listed in ways that
are specific to printer utilization. In several cases and for very
specific and understood reasons, control methods such as
PJL and IEEE 1284.1 have been included as interpreters.
Additionally we have included things like "Automatic" which
implies an intelligence in the printer to determine the printer
datastream. (I really thing a MIME type of application/automatic
might be a little hard to justify and define.)
I think at this point in time, to throw away what we learned because
the current hot button for HTTP and e-mail systems is the
use of MIME and try to graft it onto a MIB that we have already
proven to work and that is progressing based upon the needs
of the printer and printing management community is wrong.
Perhaps de-coupling IPP from the MIB in this area could be
justified but changing the MIB is simply not appropriate and is
not justified.
Don
**********************************************
* Don Wright don at lexmark.com *
* Manager, Strategic Alliances and Standards *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************